I have tried simple:
mvn clean install -Dmaven.test.skip.exec=true
switching from Maven2 (2.2.1) to Maven3 (3.0.4 - 3.0.3).
But time used for build by Maven2 was lesss! For project that build by Maven2 near 16 minutes, on Mave3 - near 20 minutes.
But, also on stackoverflow I found than Maven3 has better performance. Should I create another local repository for Maven3 (I used old created by Maven2) or use additional options?
Thanks.
Maven 3 should be faster than Maven 2. Of course, there's always the possibility of a performance regression for some edge cases. I'm not sure where the problem is in your case but I'd start by seeing which phase takes longer and comparing that to the Maven 2 build, for instance:
is this a multi-module or a single-module build?
does the build contain non-standard build extensions, for instance the maven-bundle-plugin?
does the build use the latest versions of the plugins? The maven-compiler-plugin brings nice performance improvements for multi-module projects in version 2.4.0
does the build reference artifacts with version ranges? I recall there were some troubles in terms of performance with early Maven 3.0.x versions
are all plugin versions fixed in your POM? It is possible that Maven 3 brings in new plugin versions which have performance regressions
Once you narrow down the root cause you can either fix it yourself - if possible - or submit a bug report to the maven plugin or maven core.
You can try the -T option of Maven 3 which offers the possibility to execute parts of the lifecycle in parallel.
excerpt from the --help output:
-T,--threads <arg> Thread count, for instance 2.0C
where C is core multiplied
But it depends on which plugins versions you are using if they already up-to-date and correctly marked with #threadsafe. But sometimes it's worth a try.
Related
The versions of Maven plugins specified in default-bindings.xml is not latest.
For example, maven-resources-plugin is 2.6, but latest is 3.1.0,
maven-jar-plugin is 2.4, but latest is 3.1.0.
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
I think it's not necessary to update default-bindings.xml at every minor version update of plugins.
However, the above is major update.
I know I can change the versions myself if I want.
My Question is why default versions that affect most of the maven users are clearly old.
The thing is you should always pin all your plugin (and I mean all plugins) inside your build which means define the version of all plugins via <pluginManagement>..</pluginManagmenet> this is best practice and you should never rely on those in Maven Core.
Furthermore there is work done in the background to decouple the artifact handlers (plugin binding) from Maven Core and move it to the plugins1, 2 and 3 and so on (which is done in very small steps and will take a long time).
I get the below error while executing the default lifecycle 'clean install' from my maven project.
java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
My code uses the flexmojos-maven-plugin. As per the jira thread https://issues.apache.org/jira/browse/MNG-5958 this issue has been resolved, but nowhere could I find how.
As per the solution I would have to update Lifecycle.java. Updating Lifecycle.java would mean updating maven-core.jar.
Will I have to go the extent of updating a standard jar which could impact many other files which are using this jar.
I am using maven 3.3.9 and java 8.
The problem is that the Maven guys changed quite a lot internally again with Maven 3.3.9 so currently you will have to use an older Maven version. I also doubt that I will be able to spare the time to address this in the future as Flexmojos has become more and more a beast to maintain. Therefore I am currently working on a completely new maven plugin which I am developing as part of the Apache flex project. For now I would suggest to use Maven 3.3.3 ... should work nicely with that.
I have an application that uses maven 2.2.1 for building. I want to use a plugin that needs maven3 to run during deploy phase of build. Is this possible. Just want to know if someone solved this scenario in a unique way.
You'll either need to use different Maven installations for different phases or convert everything to Maven3.
Having just converted my build process to Maven3, there is one huge gotcha in Maven3: version ranges on snapshots are totally mucked up. There was an attempt to rectify version weirdness in Maven2 and instead broke Maven3. Version ranges with release artifacts work fine, just not snapshot, so something to beware of.
I am reasking this question for maven 3:
Profiling Maven
I want to know how much time is spent for each mojo / phase / project.
There is http://jira.codehaus.org/browse/MNG-3547 and http://jira.codehaus.org/browse/MNG-4639 but I dont know about their state.
I applied MNG-3547 to apache-maven-2.2.1 and it works fine. I gather the profiling data that is emitted, parse and analyse it (using scala).
Now we are migrating to maven 3.
Are there newer / better approaches to profile a maven3 build, or should I port the patch?
Thanks in advance, Bastl.
Now, I don't know if this is really a direct answer based on Maven alone, but I do know that Sonatype's Maven 3 work on the Hudson plugin did include profiling information for a build. If you use the Maven 3 integration for Hudson you will be able to see how long your Maven builds spend in each goal.
I have an artifact that should be built for several target platforms:
Linux x86
Windows x86
ARM11
Unfortunately due to the lack of crosscompilers, it is not possible to create all versions of the artifact in one go.
Using other words, the goal is to have in the repository something like this
artifact-1.0.0-linux.zip
artifact-1.0.0-windows.zip
artifact-1.0.0-arm11.zip
artifact-1.0.1-linux.zip
artifact-1.0.1-windows.zip
artifact-1.0.1-arm11.zip
...
Note that the versions are in sync. How to accomplish this?
The thing is that the release process upgrades version of the pom.xml after every build. So by building consecutively on various platforms I can achieve having
artifact-1.0.0-linux.zip
artifact-1.0.1-windows.zip
artifact-1.0.2-arm11.zip
artifact-1.0.3-linux.zip
artifact-1.0.4-windows.zip
artifact-1.0.5-arm11.zip
...
but this is not what I am looking for.
I could
run on Linux
mvn release:prepare release:perform -DpushChanges=false
(with pushChanges set to false release won't increase version number in SCM)
and then run on Windows
mvn release:prepare release:perform
(this will increase the version number)
But then the responsibility to trigger the release processes on various platforms in the proper order lies with me. Is there a way maven can help me with this?
Do you have any suggestions?
Thanks
PS. Note that this is not a question about how to organize into modules. It is about how to synchronize release processes of a single artifact on multiple platforms.
Have you found a solution for this yet?
It's good to know I'm not the only one fighting with Maven :-)
Anyway,
Are you allowed to deploy a released version to nexus?
I'm thinking, you could do this:
1 - Do a "mvn release:prepare release:perform" from a windows machine - that should get artifact-1.0.1-windows.zip into nexus.
2 - Checkout the artifact-1.0.1 tag from source control
3 - Do a "mvn deploy" from linux and arm11 (whatever that is :P) - that should get -linux.zip and -arm11.zip into nexus as well.
Though, I believe that depending on how nexus is configured it won't let you redeploy anything with the same GAV (even if the classifier is different)
As I see, you use classifiers (artifact's file name suffix) like linux, windows or arm11 to distinguish various artifact's releases, intended for specific platforms. So, if you create multi-module project managed by Maven, where modules would be artifacts with same groupId, same artifactId, same version (probably inherited from their common parent), but different classifier, you'll get exactly what you want. In such case, you always release your multi-module POM (usually it is common parent for its modules as well) to have all modules released at once. Assuming same-version-for-all-modules-policy (which seems to fit pretty well here), you can basically execute:
mvn release:prepare release:perform -DautoVersionSubmodules
and that's it. You will get artifact-1.0.0-linux.zip, artifact-1.0.0-windows.zip, artifact-1.0.0-arm11.zip artifacts released. Next development version will be set to 1.0.1-SNAPSHOT for all modules (via inheritance from parent).
You helped me out with your question...I didn't know about the pushChanges=false option.
Using Jenkins you can set up a job on each platform that performs the maven release in series using the "Trigger builds remotely (e.g., from scripts)" feature. If you desire, you can use a Parameterized Build to choose which version to build (If you use that, then you need the Parameterized Trigger Plugin to trigger the build on the other platforms).