Re: source-plugin vs, the initialize phase?
Hi, On 1/15/15 5:45 PM, org.apache.maven.u...@io7m.com wrote: 'Lo. On 2015-01-15T17:41:33 +0100 Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, you problem is simply you have bound the `jar` goal of the maven-source-plugin which forks the life cycle. On 2015-01-15T16:40:36 + Stuart McCulloch mccu...@gmail.com wrote: Use the jar-no-fork and test-jar-no-fork goals of the maven-source-plugin - these won’t fork the build (which is what is causing initialize to run multiple times) Thanks to you both, had no idea that even existed. Any idea why forking is the default behaviour? In earlier days the idea was to make sure some kind of generated code (source/resources) should also being packed into the source package but over the time it shows that it was not such a wise idea...cause usually you use the whole build life cycle which makes sure having the code generated already... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Enquiry about POM parent tag version
What does your parent tag say in POM3?
Isn't that how current version is going to get resolved?
Maven will use what you tell it to find places where variables get
resolved to values.
On 15/01/2015 2:02 AM, yeelong wrote:
Hi All,
Could you please help to advise the following?
I have the following in my parent POM 1:
profiles
profile
iddevelopment/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idsome-snapshots/id
nameSome snapshots/name
urlhttp://someip:someport/content/repositories/snapshots//url
/repository
/repositories
/profile
properties
currentVersionversion_A/currentVersion
/properties
/profiles
I have the following in my children POM 2:
parent
groupIdparent_group_id/groupId
artifactIdparent_artifact_id/artifactId
version${currentVersion}/version
/parent
I have the following in my children POM 3:
dependency
groupIdpom2_group_id/groupId
artifactIdpom2_artifact_id/artifactId
versionpom2_version/version
/dependency
POM1 and POM2 is both working fine and the ${currentVersion} is
recognized. But in POM 3, it complains that ${currentVersion} can not be
resolved.
Thanks and Regards,
Yee Long
--
View this message in context:
http://maven.40175.n5.nabble.com/Enquiry-about-POM-parent-tag-version-tp5823587.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: source-plugin vs, the initialize phase?
Use the jar-no-fork and test-jar-no-fork goals of the maven-source-plugin - these won’t fork the build (which is what is causing initialize to run multiple times) On Thursday, 15 January 2015 at 16:24, org.apache.maven.u...@io7m.com wrote: Hi. I have a custom plugin that inserts some extra files into the jars produced by the jar plugin. Because of the way the plugin works, it will fail if it tries to make the modifications to a jar file that has already had the modifications made. For reasons that aren't really relevant here, modifying the plugin to cope with jars that have been modified isn't feasible. The simplest way to resolve this issue seems to be to have the clean plugin delete any existing jar file unconditionally (so if the user doesn't specify clean on the command line, the module is cleaned anyway and the plugin doesn't have to receive an already-edited jar). Anyway, the following pom file unconditonally runs the clean plugin in the initialize phase: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.io7m.example/groupId artifactIdinit-test/artifactId version0.1.0/version packagingjar/packaging prerequisites maven3.0.3/maven /prerequisites properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties dependencies /dependencies build plugins !-- Clean all artifacts automatically at the start of the build. -- plugin artifactIdmaven-clean-plugin/artifactId version2.5/version executions execution idauto-clean/id phaseinitialize/phase goals goalclean/goal /goals /execution /executions /plugin !-- Create source jar -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.2.1/version executions execution phasepackage/phase goals goaljar/goal goaltest-jar/goal /goals /execution /executions /plugin /plugins /build /project This would be fine, except that if you attempt to run the above pom with mvn verify, the maven-source-plugin will cause the maven-clean-plugin to be executed twice: [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building init-test 0.1.0 [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ init-test --- [INFO] No tests to run. [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ init-test --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: /tmp/sandbox/init-test/target/init-test-0.1.0.jar [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] Deleting /tmp/sandbox/init-test/target [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:test-jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.925 s [INFO] Finished at: 2015-01-15T16:05:19+00:00 [INFO] Final Memory: 10M/228M [INFO]
Re: source-plugin vs, the initialize phase?
'Lo. On 2015-01-15T17:41:33 +0100 Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, you problem is simply you have bound the `jar` goal of the maven-source-plugin which forks the life cycle. On 2015-01-15T16:40:36 + Stuart McCulloch mccu...@gmail.com wrote: Use the jar-no-fork and test-jar-no-fork goals of the maven-source-plugin - these won’t fork the build (which is what is causing initialize to run multiple times) Thanks to you both, had no idea that even existed. Any idea why forking is the default behaviour? M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: source-plugin vs, the initialize phase?
Hi, you problem is simply you have bound the `jar` goal of the maven-source-plugin which forks the life cycle. To prevent that you should use the `jar-no-fork` goal instead [1]... Kind regards Karl Heinz Marbaise [1] http://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html On 1/15/15 5:24 PM, org.apache.maven.u...@io7m.com wrote: Hi. I have a custom plugin that inserts some extra files into the jars produced by the jar plugin. Because of the way the plugin works, it will fail if it tries to make the modifications to a jar file that has already had the modifications made. For reasons that aren't really relevant here, modifying the plugin to cope with jars that have been modified isn't feasible. The simplest way to resolve this issue seems to be to have the clean plugin delete any existing jar file unconditionally (so if the user doesn't specify clean on the command line, the module is cleaned anyway and the plugin doesn't have to receive an already-edited jar). Anyway, the following pom file unconditonally runs the clean plugin in the initialize phase: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.io7m.example/groupId artifactIdinit-test/artifactId version0.1.0/version packagingjar/packaging prerequisites maven3.0.3/maven /prerequisites properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties dependencies /dependencies build plugins !-- Clean all artifacts automatically at the start of the build. -- plugin artifactIdmaven-clean-plugin/artifactId version2.5/version executions execution idauto-clean/id phaseinitialize/phase goals goalclean/goal /goals /execution /executions /plugin !-- Create source jar -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.2.1/version executions execution phasepackage/phase goals goaljar/goal goaltest-jar/goal /goals /execution /executions /plugin /plugins /build /project This would be fine, except that if you attempt to run the above pom with mvn verify, the maven-source-plugin will cause the maven-clean-plugin to be executed twice: [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building init-test 0.1.0 [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ init-test --- [INFO] No tests to run. [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ init-test --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: /tmp/sandbox/init-test/target/init-test-0.1.0.jar [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] Deleting /tmp/sandbox/init-test/target [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:test-jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO]
source-plugin vs, the initialize phase?
Hi. I have a custom plugin that inserts some extra files into the jars produced by the jar plugin. Because of the way the plugin works, it will fail if it tries to make the modifications to a jar file that has already had the modifications made. For reasons that aren't really relevant here, modifying the plugin to cope with jars that have been modified isn't feasible. The simplest way to resolve this issue seems to be to have the clean plugin delete any existing jar file unconditionally (so if the user doesn't specify clean on the command line, the module is cleaned anyway and the plugin doesn't have to receive an already-edited jar). Anyway, the following pom file unconditonally runs the clean plugin in the initialize phase: ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.io7m.example/groupId artifactIdinit-test/artifactId version0.1.0/version packagingjar/packaging prerequisites maven3.0.3/maven /prerequisites properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties dependencies /dependencies build plugins !-- Clean all artifacts automatically at the start of the build. -- plugin artifactIdmaven-clean-plugin/artifactId version2.5/version executions execution idauto-clean/id phaseinitialize/phase goals goalclean/goal /goals /execution /executions /plugin !-- Create source jar -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.2.1/version executions execution phasepackage/phase goals goaljar/goal goaltest-jar/goal /goals /execution /executions /plugin /plugins /build /project This would be fine, except that if you attempt to run the above pom with mvn verify, the maven-source-plugin will cause the maven-clean-plugin to be executed twice: [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building init-test 0.1.0 [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ init-test --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /tmp/sandbox/init-test/src/test/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ init-test --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ init-test --- [INFO] No tests to run. [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ init-test --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: /tmp/sandbox/init-test/target/init-test-0.1.0.jar [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] Deleting /tmp/sandbox/init-test/target [INFO] [INFO] maven-source-plugin:2.2.1:jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-clean-plugin:2.5:clean (auto-clean) @ init-test --- [INFO] [INFO] maven-source-plugin:2.2.1:test-jar (default) generate-sources @ init-test [INFO] [INFO] --- maven-source-plugin:2.2.1:test-jar (default) @ init-test --- [INFO] No sources in project. Archive not created. [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 0.925 s [INFO] Finished at: 2015-01-15T16:05:19+00:00 [INFO] Final Memory: 10M/228M [INFO] Note how auto-clean
Re: Enquiry about POM parent tag version
In order to help you we need the full chain, in pom3 you do not show the
parent. In pom2 the current version must be defined, otherwise it cannot
get to the parent.
Did you check you actually get the pom versions you expect (just watch the
downloads or look at help:effective-pom)
Grettings
Bernd
Am 15.01.2015 08:04 schrieb yeelong ccyyll8...@yahoo.com:
Hi All,
Could you please help to advise the following?
I have the following in my parent POM 1:
profiles
profile
iddevelopment/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idsome-snapshots/id
nameSome snapshots/name
urlhttp://someip:someport/content/repositories/snapshots//url
/repository
/repositories
/profile
properties
currentVersionversion_A/currentVersion
/properties
/profiles
I have the following in my children POM 2:
parent
groupIdparent_group_id/groupId
artifactIdparent_artifact_id/artifactId
version${currentVersion}/version
/parent
I have the following in my children POM 3:
dependency
groupIdpom2_group_id/groupId
artifactIdpom2_artifact_id/artifactId
versionpom2_version/version
/dependency
POM1 and POM2 is both working fine and the ${currentVersion} is
recognized. But in POM 3, it complains that ${currentVersion} can not be
resolved.
Thanks and Regards,
Yee Long
--
View this message in context:
http://maven.40175.n5.nabble.com/Enquiry-about-POM-parent-tag-version-tp5823587.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Enquiry about POM parent tag version
Please read my answer here:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
I think you are trying to do something that does not work
On Thursday, 15 January 2015, Bernd e...@zusammenkunft.net wrote:
In order to help you we need the full chain, in pom3 you do not show the
parent. In pom2 the current version must be defined, otherwise it cannot
get to the parent.
Did you check you actually get the pom versions you expect (just watch the
downloads or look at help:effective-pom)
Grettings
Bernd
Am 15.01.2015 08:04 schrieb yeelong ccyyll8...@yahoo.com javascript:;
:
Hi All,
Could you please help to advise the following?
I have the following in my parent POM 1:
profiles
profile
iddevelopment/id
activation
activeByDefaulttrue/activeByDefault
/activation
repositories
repository
idsome-snapshots/id
nameSome snapshots/name
urlhttp://someip:someport/content/repositories/snapshots//url
/repository
/repositories
/profile
properties
currentVersionversion_A/currentVersion
/properties
/profiles
I have the following in my children POM 2:
parent
groupIdparent_group_id/groupId
artifactIdparent_artifact_id/artifactId
version${currentVersion}/version
/parent
I have the following in my children POM 3:
dependency
groupIdpom2_group_id/groupId
artifactIdpom2_artifact_id/artifactId
versionpom2_version/version
/dependency
POM1 and POM2 is both working fine and the ${currentVersion} is
recognized. But in POM 3, it complains that ${currentVersion} can not be
resolved.
Thanks and Regards,
Yee Long
--
View this message in context:
http://maven.40175.n5.nabble.com/Enquiry-about-POM-parent-tag-version-tp5823587.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
javascript:;
For additional commands, e-mail: users-h...@maven.apache.org
javascript:;
--
Sent from my phone
Re: Enquiry about POM parent tag version
Hi All,
Thanks for your advice.
POM3 is depending on POM2.
The following is POM3:
dependencies
dependency
groupIdpom2GroupId/groupId
artifactIdpom2ArtifactId/artifactId
versionpom2Version/version
/dependency
/dependencies
Now, POM3 is ok. But, POM2 is having some issue. Initially POM2 is ok,
but after built POM1 and POM2 and finally build POM3, POM2 complains that
${currentVersion} can not be resolved.
Thanks and Regards,
Yee Long
--
View this message in context:
http://maven.40175.n5.nabble.com/Enquiry-about-POM-parent-tag-version-tp5823587p5823703.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Enquiry about POM parent tag version
hi Bernd, Thanks for your advice. The following is parent of POM3: namePOM3 parent/name profiles profile idsomeId/id activation activeByDefaulttrue/activeByDefault /activation properties currentVersionsomeVersionName/currentVersion /properties /profile /profiles In POM2, it seems the currentVersion can be resolved because it is being retrieved from Parent POM1. Yes. In the local maven repository, the artifact is generated with corresponding version. Thanks and Regards, Yee Long -- View this message in context: http://maven.40175.n5.nabble.com/Enquiry-about-POM-parent-tag-version-tp5823587p5823702.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help with this question
Hi,
test-jar goal does'nt seems to have a classifier configuration property so
it's probably why it does'nt work.
You probably will have to use finalName.
On Wed, Jan 14, 2015 at 9:38 PM, Carlos Bribiescas cbribies...@gmail.com
wrote:
I'm setting up our system to do dual building for different versions of
java artifacts based on the jdk used. There are 4 jars to build: artifact,
artifact-tests, artifact-sources, and artifact-test-sources. Here is the
output of the build
[INFO] Installing
/Users/carlos/workspace/svn/Libraries/artifact-name/trunk/pom.xml to
/Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT.pom[INFO]
Installing
/Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-java6.jar
to
/Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-java6.jar[INFO]
Installing
/Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-sources.jar
to
/Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-sources.jar[INFO]
Installing
/Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-test-sources.jar
to
/Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-test-sources.jar[INFO]
Installing
/Users/carlos/workspace/svn/Libraries/path/artifact-name-1.0.8-SNAPSHOT-tests.jar
to
/Users/carlos/.m2/repository/package-path/artifact-name/1.0.8-SNAPSHOT/artifact-name-1.0.8-SNAPSHOT-tests.jar
You can see the main artifact is built with java6 and has the appropriate
classifier. However at a glance me its unclear if the tests are built with
java6 or java7. I'm assuming the tests classifier is overwriting the java6
classifier, but I'm unsure. Is there a way to get it to be named explicitly
for both tests and the jdk? Something like -1.0.8-SNAPSHOT-tests-java6.jar.
I'de like to refrain from doing manual changes to the final.name if
possible and just use stock functionality like I did for the main artifact.
Here are the relevant parts of the pom.
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version${maven.jar.version}/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version${maven.compiler.version}/version
configuration
source${jdk.version}/source
target${jdk.version}/target
forceJavacCompilerUsetrue/forceJavacCompilerUse
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-source-plugin/artifactId
version${maven.source.version}/version
/plugin
/plugins
/pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.9/version
executions
execution
idanalyze/id
goals
goalanalyze-only/goal
/goals
configuration
failOnWarningtrue/failOnWarning
ignoreNonCompiletrue/ignoreNonCompile
/configuration
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.4/version
!--configuration--
!--skiptrue/skip--
!--/configuration--
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source${jdk.version}/source
target${jdk.version}/target
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-source-plugin/artifactId
executions
execution
goals
goaljar/goal
goaltest-jar/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
configuration
classifier${jdk.version.display}/classifier
/configuration
executions
execution
goals
goaltest-jar/goal
Re: Maven Incremental Build: JDT Compiler Implementation
Is there an example project to kick the tires for incremental builds? How about early timings for performance? Seems like the feature requires its own package type, won't that cause lots of downstream headache for other tools? On Jan 13, 2015 2:18 PM, Jason van Zyl ja...@takari.io wrote: Hi, Incremental build (or build avoidance) is a heavily discussed topic these days and users always ask about it in the context of Maven. In the last Maven Developer Hangout[1] we talked about incremental build as implemented for Maven and Buck and Igor also presented what might be interesting to users who want to learn move about incremental build which is Takari's incremental compiler implementation that uses JDT. If you are interested you can take a look here[2]. [1]: https://plus.google.com/u/0/events/cm0nnn4342ttnk0i9k4pvml3670 [2]: http://takari.io/2015/01/13/incremental-build.html Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Maven Incremental Build: JDT Compiler Implementation
Good questions. Most of our projects use our lifecycle[1] and they serve as good examples. The compiler is generally very fast so from a raw performance perspective if you have a very large build you simply can't have an incremental compile with Javac. It's all or nothing because it just can't give you the information to do an incremental compile. But if you change one file JDT will compile the tree incrementally where Javac is going to have to build everything. Looking at timestamps will not give you correct results. It may happen to work but it's circumstance and luck if it does. So if you have this situation with a large tree it's certainly beneficial. But in order to have an incremental build the compiler needs to be incremental for correctness and there's no way around that. There is a good blog entry from Paris Apostolopoulos[2] about his experience trying out the Takari incremental lifecycle and the performance benefits. We certainly want to make things faster but we are also concerned with correctness. We believe a separate package type is necessary because it's a conscious decision to switch to using this lifecycle. We never even considered trying to magically make the whole lifecycle work with the existing packaging as that would likely be confusing and misleading. We do outline ways to try individual incremental Mojos as part of your build, but to get the benefits of incremental support in the lifecycle you need to use our packaging type which is a replacement for the default lifecycle. [1]: https://github.com/takari/ [2]: http://javapapo.blogspot.ca/2014/11/do-you-reall-want-to-speed-up-your.html?spref=tw On Jan 15, 2015, at 7:33 AM, jieryn jie...@gmail.com wrote: Is there an example project to kick the tires for incremental builds? How about early timings for performance? Seems like the feature requires its own package type, won't that cause lots of downstream headache for other tools? On Jan 13, 2015 2:18 PM, Jason van Zyl ja...@takari.io wrote: Hi, Incremental build (or build avoidance) is a heavily discussed topic these days and users always ask about it in the context of Maven. In the last Maven Developer Hangout[1] we talked about incremental build as implemented for Maven and Buck and Igor also presented what might be interesting to users who want to learn move about incremental build which is Takari's incremental compiler implementation that uses JDT. If you are interested you can take a look here[2]. [1]: https://plus.google.com/u/0/events/cm0nnn4342ttnk0i9k4pvml3670 [2]: http://takari.io/2015/01/13/incremental-build.html Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
