Re: parent pom relative path not working, with test case
added Jira https://issues.apache.org/jira/browse/MNG-6503 On 11/1/2018 12:22 PM, Karl Heinz Marbaise wrote: > Hi, > > can you please file an issue in JIRA and please add an example project to > reproduce the issue... > > Kind regards > Karl Heinz Marbaise > > On 01/11/18 14:49, Marshall Schor wrote: >> also tried with just released maven 3.6.0 - same behavior. >> >> On 11/1/2018 9:34 AM, Marshall Schor wrote: >>> Hi, >>> >>> I can get parent pom relative path to work from a top level pom referencing >>> a >>> subfolder at the 1st level. >>> >>> But it fails for me when the top level includes a sub project >>> contained >>> in another 1st level folder next to the parent pom's folder, where that >>> project's pom references the parent-pom using ../parent/pom.xml. >>> >>> I include here a trivial example, with the folder structure and the poms. >>> You >>> can see the failure by typing mvn help:effective-pom after cd'ing to the top >>> project's folder. >>> >>> Here's the folder structure: >>> mvntst <- top folder >>> parent <- subfolder having parent pom >>> subproj <- subfolder having a sub project >>> >>> Using maven version 3.5.4 (current), running on Windows 10, with Java 8 >>> >>> The three poms: >>> >>> in mvntst folder (the top level folder) >>> >>> >>> 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;> >>> 4.0.0 >>> mvntst >>> top >>> pom >>> >>> mvntst >>> parent >>> 1.0.0 >>> parent/pom.xml >>> >>> >>> subproj >>> >>> >>> >>> in parent subfolder: >>> >>> >>> 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;> >>> 4.0.0 >>> mvntst >>> parent >>> 1.0.0 >>> pom >>> >>> >>> in subproj subfolder: >>> >>> >>> 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;> >>> 4.0.0 >>> mvntst >>> subproj >>> >>> mvntst >>> parent >>> 1.0.0 >>> ../parent/pom.xml >>> >>> >>> >>> In doing various tests: if the top pom is missing its relative-path, you >>> get an >>> expected >>> Non-resolvable parent POM for mvntst:top:[unknown-version]: Failure to find >>> mvntst:parent:pom:1.0.0 >>> >>> putting in the relative-path into the top fixes this, and results in finding >>> the >>> parent for the top level. >>> If you don't have a section in the top level, the mvn >>> help:effective-pom works OK. >>> >>> Putting in the section gives the error: >>> Non-resolvable parent POM for mvntst:subproj:[unknown-version]: Failure to >>> find >>> mvntst:parent:pom:1.0.0 >>> >>> Adding the to the artifact IDs for the top and subproj doesn't >>> help, >>> except to change the error message to include the version instead of >>> [unknown-version] >>> >>> Any idea why relative-path works for the top level pom referencing a direct >>> subfolder, but the subproject's reference fails? Is this not supported by >>> maven? >>> >>> Thanks. -Marshall >>> >>> P.S., a great improvement for maven would be to have the error message for >>> this >>> which says: >>> 'parent.relativePath' points at wrong local POM >>> be augmented to say why. For example, >>> the relative path resolved to , and there was no file there, or >>> the relative path resolved to , and that file was not a "pom" >>> xml >>> file, or >>> the relative path resolved to , and the pom found there didn't >>> pass >>> this validation test (saying what exactly failed) >>> >>> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: parent pom relative path not working, with test case, worked in maven 3.3.9
This appears to be maven-release related, because this works in version 3.3.9, but not in 3.5.4 or 3.6.0. Anyone know a workaround? -Marshall On 11/1/2018 9:49 AM, Marshall Schor wrote: > also tried with just released maven 3.6.0 - same behavior. > > On 11/1/2018 9:34 AM, Marshall Schor wrote: >> Hi, >> >> I can get parent pom relative path to work from a top level pom referencing a >> subfolder at the 1st level. >> >> But it fails for me when the top level includes a sub project >> contained >> in another 1st level folder next to the parent pom's folder, where that >> project's pom references the parent-pom using ../parent/pom.xml. >> >> I include here a trivial example, with the folder structure and the poms. >> You >> can see the failure by typing mvn help:effective-pom after cd'ing to the top >> project's folder. >> >> Here's the folder structure: >> mvntst <- top folder >> parent <- subfolder having parent pom >> subproj <- subfolder having a sub project >> >> Using maven version 3.5.4 (current), running on Windows 10, with Java 8 >> >> The three poms: >> >> in mvntst folder (the top level folder) >> >> >> 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;> >> 4.0.0 >> mvntst >> top >> pom >> >> mvntst >> parent >> 1.0.0 >> parent/pom.xml >> >> >> subproj >> >> >> >> in parent subfolder: >> >> >> 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;> >> 4.0.0 >> mvntst >> parent >> 1.0.0 >> pom >> >> >> in subproj subfolder: >> >> >> 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;> >> 4.0.0 >> mvntst >> subproj >> >> mvntst >> parent >> 1.0.0 >> ../parent/pom.xml >> >> >> >> In doing various tests: if the top pom is missing its relative-path, you get >> an >> expected >> Non-resolvable parent POM for mvntst:top:[unknown-version]: Failure to find >> mvntst:parent:pom:1.0.0 >> >> putting in the relative-path into the top fixes this, and results in finding >> the >> parent for the top level. >> If you don't have a section in the top level, the mvn >> help:effective-pom works OK. >> >> Putting in the section gives the error: >> Non-resolvable parent POM for mvntst:subproj:[unknown-version]: Failure to >> find >> mvntst:parent:pom:1.0.0 >> >> Adding the to the artifact IDs for the top and subproj doesn't >> help, >> except to change the error message to include the version instead of >> [unknown-version] >> >> Any idea why relative-path works for the top level pom referencing a direct >> subfolder, but the subproject's reference fails? Is this not supported by >> maven? >> >> Thanks. -Marshall >> >> P.S., a great improvement for maven would be to have the error message for >> this >> which says: >> 'parent.relativePath' points at wrong local POM >> be augmented to say why. For example, >> the relative path resolved to , and there was no file there, or >> the relative path resolved to , and that file was not a "pom" xml >> file, or >> the relative path resolved to , and the pom found there didn't >> pass >> this validation test (saying what exactly failed) >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: parent pom relative path not working, with test case
also tried with just released maven 3.6.0 - same behavior. On 11/1/2018 9:34 AM, Marshall Schor wrote: > Hi, > > I can get parent pom relative path to work from a top level pom referencing a > subfolder at the 1st level. > > But it fails for me when the top level includes a sub project > contained > in another 1st level folder next to the parent pom's folder, where that > project's pom references the parent-pom using ../parent/pom.xml. > > I include here a trivial example, with the folder structure and the poms. You > can see the failure by typing mvn help:effective-pom after cd'ing to the top > project's folder. > > Here's the folder structure: > mvntst <- top folder > parent <- subfolder having parent pom > subproj <- subfolder having a sub project > > Using maven version 3.5.4 (current), running on Windows 10, with Java 8 > > The three poms: > > in mvntst folder (the top level folder) > > > 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;> > 4.0.0 > mvntst > top > pom > > mvntst > parent > 1.0.0 > parent/pom.xml > > > subproj > > > > in parent subfolder: > > > 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;> > 4.0.0 > mvntst > parent > 1.0.0 > pom > > > in subproj subfolder: > > > 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;> > 4.0.0 > mvntst > subproj > > mvntst > parent > 1.0.0 > ../parent/pom.xml > > > > In doing various tests: if the top pom is missing its relative-path, you get > an > expected > Non-resolvable parent POM for mvntst:top:[unknown-version]: Failure to find > mvntst:parent:pom:1.0.0 > > putting in the relative-path into the top fixes this, and results in finding > the > parent for the top level. > If you don't have a section in the top level, the mvn > help:effective-pom works OK. > > Putting in the section gives the error: > Non-resolvable parent POM for mvntst:subproj:[unknown-version]: Failure to > find > mvntst:parent:pom:1.0.0 > > Adding the to the artifact IDs for the top and subproj doesn't help, > except to change the error message to include the version instead of > [unknown-version] > > Any idea why relative-path works for the top level pom referencing a direct > subfolder, but the subproject's reference fails? Is this not supported by > maven? > > Thanks. -Marshall > > P.S., a great improvement for maven would be to have the error message for > this > which says: > 'parent.relativePath' points at wrong local POM > be augmented to say why. For example, > the relative path resolved to , and there was no file there, or > the relative path resolved to , and that file was not a "pom" xml > file, or > the relative path resolved to , and the pom found there didn't pass > this validation test (saying what exactly failed) > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
parent pom relative path not working, with test case
Hi, I can get parent pom relative path to work from a top level pom referencing a subfolder at the 1st level. But it fails for me when the top level includes a sub project contained in another 1st level folder next to the parent pom's folder, where that project's pom references the parent-pom using ../parent/pom.xml. I include here a trivial example, with the folder structure and the poms. You can see the failure by typing mvn help:effective-pom after cd'ing to the top project's folder. Here's the folder structure: mvntst <- top folder parent <- subfolder having parent pom subproj <- subfolder having a sub project Using maven version 3.5.4 (current), running on Windows 10, with Java 8 The three poms: in mvntst folder (the top level folder) 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;> 4.0.0 mvntst top pom mvntst parent 1.0.0 parent/pom.xml subproj in parent subfolder: 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;> 4.0.0 mvntst parent 1.0.0 pom in subproj subfolder: 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;> 4.0.0 mvntst subproj mvntst parent 1.0.0 ../parent/pom.xml In doing various tests: if the top pom is missing its relative-path, you get an expected Non-resolvable parent POM for mvntst:top:[unknown-version]: Failure to find mvntst:parent:pom:1.0.0 putting in the relative-path into the top fixes this, and results in finding the parent for the top level. If you don't have a section in the top level, the mvn help:effective-pom works OK. Putting in the section gives the error: Non-resolvable parent POM for mvntst:subproj:[unknown-version]: Failure to find mvntst:parent:pom:1.0.0 Adding the to the artifact IDs for the top and subproj doesn't help, except to change the error message to include the version instead of [unknown-version] Any idea why relative-path works for the top level pom referencing a direct subfolder, but the subproject's reference fails? Is this not supported by maven? Thanks. -Marshall P.S., a great improvement for maven would be to have the error message for this which says: 'parent.relativePath' points at wrong local POM be augmented to say why. For example, the relative path resolved to , and there was no file there, or the relative path resolved to , and that file was not a "pom" xml file, or the relative path resolved to , and the pom found there didn't pass this validation test (saying what exactly failed) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven changes plugin subtitle has unexpanded project.version?
We're using the maven-changes-plugin to prepare an html page describing what was
changed in a release, using the jira-report option.
The report it produces has this html source included:
div class=xleft
span id=publishDateLast Published: 2013-12-27/span
nbsp;| span id=projectVersionVersion:
${project.version}/span
/div
div class=xright
The ** ${project.version} ** I think was supposed be substituted, somewhere
along the way, with a maven project version - is that right? It's showing up as
the literal characters ${project.version} in the browser.
What can we do to fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
How to test with multiple versions
Hi, We would like to run tests that test for compatibility between newer releases and older versions, for a client-server kind of application. The main idea here is that the tests would be run with the client running one version of things, and the server running another. Is there a suggested approach for doing this using Maven? The main issue I see is that the test case would depend on multiple versions of the same artifacts - some version being assigned to the client, and some to the server. But I don't think Maven allows that? It would be good to hear from others who have previously faced down this kind of issue :-) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to test with multiple versions
Thanks for the suggestions. I did look at the invoker plugin, and see you can set up separate maven builds at different versions. I guess what I'm still missing is how to write one test that (ideally, within one JVM) starts a server running with version 2.4.0 of some artifacts, and then runs a client having the same artifacts but at version 2.4.2, in the same JVM (I'm thinking, using class loader stuff), run through its tests - connecting to the service, sending messages, receiving, etc. We already have test cases that do this, but of course, the server and the client are at the same version level. An approach I am considering, is giving up on running within one JVM, and having the test do a Java exec call with a class path set up somehow to point to version 2.4.0 (for example). I'm not sure how to reference that version via maven artifact mechanisms, when the rest of the test would be referencing those same artifacts at a different version... -Marshall On 11/12/2013 10:20 AM, Stephen Connolly wrote: Maven invoker plugin would be one way to do that. Basically you have a child project for each touchstone version... or you can use invoker.properties to pass the touchstone versions through to the executions On 12 November 2013 15:15, Marshall Schor m...@schor.com wrote: Hi, We would like to run tests that test for compatibility between newer releases and older versions, for a client-server kind of application. The main idea here is that the tests would be run with the client running one version of things, and the server running another. Is there a suggested approach for doing this using Maven? The main issue I see is that the test case would depend on multiple versions of the same artifacts - some version being assigned to the client, and some to the server. But I don't think Maven allows that? It would be good to hear from others who have previously faced down this kind of issue :-) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with property substitution into finalName
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates jars
using the substituted value, e.g. org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
Thanks Stephen,
I'm trying to figure out why I'm not seeing this in the actual staged artifacts,
or in previous releases.
Here's what I've concluded:
The maven-gpg-plugin has a bug - it copies the pom.xml to the finalname.pom, in
target, and then signs that, without substituting into the property variable in
the finalname. So, if you look into /target, it's got the wrong name.
But, when the install plugin installs, it
(a) ignores the incorrectly named ...pom in the /target, and instead, copies
the original pom to the install spot. You can see that in the run output for
the install step:
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\pom.xml to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\
uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom
(b) it does copy the incorrectly named .asc file to the repository, but
(SURPRISE !) it fixes up the name in the target :-) :
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\target\org.apache.uima.textmarker.engine_${parsedVersion
.osgiVersion}.pom.asc to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom.asc
So, we're only seeing this issue due to the fact that we happened to look into
the /target directory.
-Marshall
On 2/8/2013 12:33 PM, Stephen Connolly wrote:
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as
the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
gpg plugin signing poms, 2nd finalName part not substituted?
I have a project which specifies in the build a finalName which has 2
substitutable parts:
finalName${project.artifactId}_${parsedVersion.osgiVersion}/finalName
where the parsedVersion.osgiVersion property is set by the
build-helper-maven-plugin, in the first life-cycle-phase.
This property is correctly substituted by the maven-jar-plugin - in that it
builds a jar with the name xyz_2.4.0.jar (assuming for example, that the
project.artifactId is xyz).
This property is correctly substituted by the maven-sources-plugin, too -
building xyz_2.4.0-sources.jar.
However, the maven gpg plugin uses this bit of code to copy the pom to the
target, prior to signing it:
//
// POM
//
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
The file it produces is xyz_${parsedVersion.osgiVersion}.pom.
For some reason, the only the 1st property (${project.artifactId}) is being
substituted, but the 2nd value is not.
The GPG plugin runs after the other plugins - the jar and the sources plugins,
so the property already has a value.
Any ideas on what to do to get the GPG plugin to substitute this value? (I'm
using version 1.3 of the maven-gpg-plugin).
-Marshall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
deploy failing with illegal character
In trying to do an Apache release, the release:perform goal fails when uploading to the Apache repository. I've tried 3 times, with 2 different JVMs (Sun/Oracle and IBM), all give this error: [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project uima-addons-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.uima:uima-addons-parent:pom:2.3.1 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic c2Nob3I6e05CeGU5SlJ3anE4SEFqK0pvcFRUK1I1emo5VDd4N1JEaDl3bFdPbEI2Q0RXUXVRd2k2 [INFO] [ERROR] dm1sSlpzZTVQM0ZrU ... etc. I googled this, and found this http://markmail.org/message/nscp44q2tm6qh3di It says it's a known bug in JRE's base64 encoder, which is used by the lightweight wagon used to deploy. The suggestion is Try to force Maven to use some other wagon instead of the lightweight one. I don't know how to do that; any suggestions? Are there other work-arounds? This is a blocker for our release. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: deploy failing with illegal character
I found the answer, it had nothing to do (mostly) with this error message. I'm using password security - there's an encrypted pw stored in my local settings.xml. It has to be unencrypted by a key. The key is not always available - and if it is not, there is a message but it scrolls by quickly, and doesn't stop the build. Later, the deploy attempts to get to the server using the encrypted pw, which fails. The fix: make the key needed to unencrypt the pw available to the build :-) -Marshall Schor On 8/24/2011 8:32 AM, Marshall Schor wrote: In trying to do an Apache release, the release:perform goal fails when uploading to the Apache repository. I've tried 3 times, with 2 different JVMs (Sun/Oracle and IBM), all give this error: [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project uima-addons-parent: Failed to deploy artifacts: Could not transfer artifact org.apache.uima:uima-addons-parent:pom:2.3.1 from/to apache.releases.https (https://repository.apache.org/service/local/staging/deploy/maven2): java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic c2Nob3I6e05CeGU5SlJ3anE4SEFqK0pvcFRUK1I1emo5VDd4N1JEaDl3bFdPbEI2Q0RXUXVRd2k2 [INFO] [ERROR] dm1sSlpzZTVQM0ZrU ... etc. I googled this, and found this http://markmail.org/message/nscp44q2tm6qh3di It says it's a known bug in JRE's base64 encoder, which is used by the lightweight wagon used to deploy. The suggestion is Try to force Maven to use some other wagon instead of the lightweight one. I don't know how to do that; any suggestions? Are there other work-arounds? This is a blocker for our release. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release plugin versus dependency plugin
The normal preparation goals for release:prepare stop short of install - they are: clean verify. Verify is one before install. You can find this information out by looking in the maven-release-plugin source, in the class PrepareReleaseMojo. I don't know the reason for this choice, but it would seem to me it may be perhaps rooted in a desire to have the release:perform step do a build from a checkout of the tag from SVN and not be dependent on anything (at that version) previously installed into the local repo. -Marshall Schor On 12/24/2010 8:07 PM, Benson Margulies wrote: On Thu, Dec 23, 2010 at 3:25 PM, Mark Struberg strub...@yahoo.de wrote: Hi Benson! Please check the preparationGoals property in the release plugin [1] Maybe you Please try with something like -DpreparationGoals=clean install I used to have that incantation but eliminated it because I didn't know why. I guess now I do. Thanks. LieGrue, strub [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#preparationGoals --- On Thu, 12/23/10, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: release plugin versus dependency plugin To: Maven Users List users@maven.apache.org Date: Thursday, December 23, 2010, 6:17 PM Under a single aggregate project, I have two projects. Project 1 builds an extra artifact with a classifier. Project 2 uses dependency:unpack to unpack it for inclusion in a, yes, larger artifact. All's well until I try to run the release:prepare goal, at which point, the first artifact is missing when the second project asks for it. any ideas? Why is the :prepare run different? [INFO] Embedded error: Unable to download the artifact from any repository [INFO] [INFO] Try downloading the file manually from the project website. [INFO] [INFO] Then, install it using the command: [INFO] mvn install:install-file -DgroupId=com.basistech.jug -DartifactId=rlp-gate-plugin -Dversion=8 -Dclassifier=gate-plugin -Dpackaging=zip -Dfile=/path/to/file [INFO] [INFO] Alternatively, if you host your own repository you can deploy the file there: [INFO] mvn deploy:deploy-file -DgroupId=com.basistech.jug -DartifactId=rlp-gate-plugin -Dversion=8 -Dclassifier=gate-plugin -Dpackaging=zip -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [INFO] [INFO] [INFO] com.basistech.jug:rlp-gate-plugin:zip:8 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with big, slow, unpacks
Here's another way (see below)
On 12/21/2010 4:29 PM, Benson Margulies wrote:
I just spend an afternoon wrestling with the release plugin. Much of
my trouble was a self-inflicted misunderstanding of
preparationGoals/ (*), but that wasn't what sent me down the path to
begin with.
I have a set of maven projects that build, amongst several other
things, a set of daemons. Each daemon is independently packaged using
the assembly plugin using the Tanuki tools, to which we have a
license.
The collection of Tanuki shared libs and other goodies is not small.
So I compressed it and pushed it to Nexus as an artifact of type
.tar.bz2.
Now, the straightforward thing to do, and indeed what I did to begin
with, was to simply list the Tanuki stuff in the assembly descriptor
for each daemon.
This made build-from-clean quite slow, as the build had to uncompress
the tarball every time.
So, I had an inspiration. Unpack it once into the tree in one project,
and then use the magic of '..' to reference it in the other project.
Which was fine, until I went to run the release plugin, which added
'target/checkout' to the path, and there went the .. counting.
Eventually, I got this under control, but only after some other
mishaps that were quite time consuming.
We've made this kind of approach work in our POMs. We keep the idea of
unpacking it once, but do it to a more general spot, such as a place in your .m2
repo.
You can use the property ${settings.localRepository} in your POM to make this
work in general.
-Marshall Schor
So, oh gurus of the maven way, where did I depart from the one true
path? Did I sin mortally by '..'-ing out of the basedir? Is there any
good way to attack the speed issue I set out to attack, or should I
have just lived with the time (and space) to unpack this stuff over
and over?
[*] My unit tests are also quite time consuming, so the debugging
process of multiple attempts at the release process was intolerably
slow with them in release:prepare, and I did not realize for quite
some time and -X reading that prepare forked another copy of maven ...
I thought, incorrectly, that only perform did that.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Dealing with big, slow, unpacks
Also, I think the dependency unpack goal can check for dates, and skip the
unpack if the version in the local .m2 repo is up to date
-Marshall
On 12/22/2010 10:32 AM, Marshall Schor wrote:
Here's another way (see below)
On 12/21/2010 4:29 PM, Benson Margulies wrote:
I just spend an afternoon wrestling with the release plugin. Much of
my trouble was a self-inflicted misunderstanding of
preparationGoals/ (*), but that wasn't what sent me down the path to
begin with.
I have a set of maven projects that build, amongst several other
things, a set of daemons. Each daemon is independently packaged using
the assembly plugin using the Tanuki tools, to which we have a
license.
The collection of Tanuki shared libs and other goodies is not small.
So I compressed it and pushed it to Nexus as an artifact of type
.tar.bz2.
Now, the straightforward thing to do, and indeed what I did to begin
with, was to simply list the Tanuki stuff in the assembly descriptor
for each daemon.
This made build-from-clean quite slow, as the build had to uncompress
the tarball every time.
So, I had an inspiration. Unpack it once into the tree in one project,
and then use the magic of '..' to reference it in the other project.
Which was fine, until I went to run the release plugin, which added
'target/checkout' to the path, and there went the .. counting.
Eventually, I got this under control, but only after some other
mishaps that were quite time consuming.
We've made this kind of approach work in our POMs. We keep the idea of
unpacking it once, but do it to a more general spot, such as a place in your
.m2
repo.
You can use the property ${settings.localRepository} in your POM to make this
work in general.
-Marshall Schor
So, oh gurus of the maven way, where did I depart from the one true
path? Did I sin mortally by '..'-ing out of the basedir? Is there any
good way to attack the speed issue I set out to attack, or should I
have just lived with the time (and space) to unpack this stuff over
and over?
[*] My unit tests are also quite time consuming, so the debugging
process of multiple attempts at the release process was intolerably
slow with them in release:prepare, and I did not realize for quite
some time and -X reading that prepare forked another copy of maven ...
I thought, incorrectly, that only perform did that.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: avoiding overwriting newer file when using maven resources plugin copy-resources with filtering
On 12/9/2010 3:59 AM, Stephen Connolly wrote:
Sounds like you might be better served by writing your own plugin to do the
filtering, that way you can take the timestamps into consideration.
OK, I just thought that since this might be common scenario, there might be an
existing Maven way to do this.
Also I hope you are putting the filtered java source into a sub-folder of
${basedir}/target
Yes, we do that in all cases except one - that of building Eclipse feature
projects.
For that case, I'm injecting the version info into the feature.xml, which I
believe Eclipse (by convention) wants to find at the project top level.
-Marshall
-Stephen
On 8 December 2010 22:49, Marshall Schor m...@schor.com wrote:
On 12/8/2010 4:40 PM, Anders Hammar wrote:
I guess the dependency plugin can't really tell, as the filtering takes a
value outside of the source file which could have changed since the last
time the file was filtered.
The price you pay for filtering I guess?
I was wondering (since I know the source of the filtered values) if there
was
a Maven-way of telling it this information?
Something like being able to declare: file xyz depends on files abc and
def, so
if abc and def are both older than xyz, don't bother updating xyz.
-Marshall Schor
/Anders
On Wed, Dec 8, 2010 at 18:02, Marshall Schor m...@schor.com wrote:
The Maven resources plugin has a goal copy-resources which has a
configuration
parameter overwrite. The default is false - meaning not to
overwrite a
target file if not needed (if the target has a later date than the
source).
This setting is ignored, however, if the file is being filtered.
I'm using this to inject version info from the POM into a Java source
file.
So
everytime this module is built, it always updates this file even though
nothing
(usually) has changed.
Is there a better Maven way to do this?
-Marshall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
avoiding overwriting newer file when using maven resources plugin copy-resources with filtering
The Maven resources plugin has a goal copy-resources which has a configuration parameter overwrite. The default is false - meaning not to overwrite a target file if not needed (if the target has a later date than the source). This setting is ignored, however, if the file is being filtered. I'm using this to inject version info from the POM into a Java source file. So everytime this module is built, it always updates this file even though nothing (usually) has changed. Is there a better Maven way to do this? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: file exists activation
In our poms we have things like:
profile
idprocess-docbook/id
activation
fileexistssrc/docbook/exists/file
/activation
... etc
which runs if the project containing the POM has a src/docbook subdirectory.
We're using Maven 3.0 (not snapshot). This snippet is in a shared parent pom.
Since it works for us and not for you, I'm guessing there's some small detail
that's different, but I don't know what it might be.
Perhaps you could post some small test case scenario for others to try and see
what's going wrong?
-Marshall Schor
On 12/3/2010 6:17 PM, dloy wrote:
I'm a new to maven. I've recently tried unsuccessfully to get
activationfileexists to work unless the absolute file path was given.
I'm running on windows XP, with netbeans IDE 6.8 supposedly using maven
3.0-SNAPSHOT.
I've tried:
existsC:/Documents and Settings/xname/My
Documents/maven/mrt/storage/store-conf/mrt.local.properties/exists --- works
exists${basedir}/mrt.local.properties/exists --- does NOT work
exists./mrt.local.properties/exists --- does NOT work
existsmrt.local.properties/exists --- does NOT work
Any suggestions for getting activationfileexists to work without using
an absolute filepath.
Thanks
David
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: avoiding overwriting newer file when using maven resources plugin copy-resources with filtering
On 12/8/2010 4:40 PM, Anders Hammar wrote: I guess the dependency plugin can't really tell, as the filtering takes a value outside of the source file which could have changed since the last time the file was filtered. The price you pay for filtering I guess? I was wondering (since I know the source of the filtered values) if there was a Maven-way of telling it this information? Something like being able to declare: file xyz depends on files abc and def, so if abc and def are both older than xyz, don't bother updating xyz. -Marshall Schor /Anders On Wed, Dec 8, 2010 at 18:02, Marshall Schor m...@schor.com wrote: The Maven resources plugin has a goal copy-resources which has a configuration parameter overwrite. The default is false - meaning not to overwrite a target file if not needed (if the target has a later date than the source). This setting is ignored, however, if the file is being filtered. I'm using this to inject version info from the POM into a Java source file. So everytime this module is built, it always updates this file even though nothing (usually) has changed. Is there a better Maven way to do this? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: clean then package error
On 10/19/2010 6:14 AM, 冯仁君 wrote: yes, I do this from m2eclipse, not command line. and I have set eclipse running in jdk in the setting.ini of eclipse. my setting: -vm D:\Java\jdk1.6.0_21\bin\javaw.exe I think it's what you say,right? I think that's not right. should be without the \javaw.exe ... should end with ...\bin -Marshall Schor -- From: Anders Hammar and...@hammar.net Sent: Tuesday, October 19, 2010 12:34 PM To: Maven Users List users@maven.apache.org Subject: Re: clean then package error You're doing tis from Eclipse/m2eclipe, right? Not command line? Is you're Eclipseset up to use a JDK? http://tech.karolzielinski.com/m2eclipse-eclipse-is-running-in-a-jre-but-a-jdk-is-required /Anders 2010/10/19 冯仁君 frj1...@126.com yes,I know. but I have set the JAVA_HOME pointing to the directory of JDK. and when I run package without clean before, it works well. if I run clean, and then package, it's error! -- From: MK Tan mktan...@gmail.com Sent: Monday, October 18, 2010 11:34 PM To: Maven Users List users@maven.apache.org Subject: Re: clean then package error I should spell check before I sending this mail. Maven need jdk and not jre. And if possible please include environment variable called JAVA_HOME which point to your jdk installation directory 2010/10/18 MK Tan mktan...@gmail.com Haven require jdk but you are refer to jre On Oct 18, 2010 8:46 PM, 冯仁君 frj1...@126.com wrote: I'm new in using maven. when I try to package a helloworld maven program after I clean in the Eclipse IDE, it comes to an error. it says : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project module: Compilation failure Unable to locate the Javac Compiler in: D:\Java\jre6\..\lib\tools.jar Please ensure you are using JDK 1.4 or above and not a JRE (the com.sun.tools.javac.Main class is required). In most cases you can change the location of your Java installation by setting the JAVA_HOME environment variable. - [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn goals -rf :module I'm sure I have installed the jdk1.6, and my environment variable is also correct. I don't it's the problem of maven, but I don't know what to do. what can I do? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice re: releasing large assembly artifacts
On 11/5/2010 4:01 PM, Antonio Petrelli wrote: 2010/11/5 Marshall Schor m...@schor.com: This seems to require the least special maven POM code (essentially, none, I think - so that might qualify it as a maven best practice :-) ). Does anyone see a flaw in this approach? IMHO as a release manager I would hate it, since I have to do more manual steps. Yes, that is a problem... BTW, probably a good approach is specifying a different repository in distributionManagement just for the assembly project. This way you don't have to move them from the repository to people.a.o and you can move them with a simple mv. Nice... -Marshall Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice re: releasing large assembly artifacts
I've thought more about this, and after exploring a bunch of different paths, I'm thinking of this process for my big assemblies: Have the release process produce the assemblies as attached artifacts (so that the maven-gpg-plugin will do the signing). Let the normal release deploy happen for these assemblies - this will upload them (with checksums added) to the Nexus staging area. Although the assemblies are large, they will then be in a spot where other developers on the project can download them (with or without maven) and test the release. If these assemblies were not put there, they would need to take up space somewhere else in the Apache infrastructure for sharing with the development community for testing, anyways. After a successful release vote, use the Nexus GUI to delete these assemblies, before pushing the release button. This prevents them from going up to Maven Central. And, of course, copy the assemblies you want to have mirrored by the normal Apache distribution mechanism, to the spot for your project. This seems to require the least special maven POM code (essentially, none, I think - so that might qualify it as a maven best practice :-) ). Does anyone see a flaw in this approach? -Marshall Schor On 11/4/2010 5:06 PM, Antonio Petrelli wrote: 2010/11/4 Marshall Schor m...@schor.com: On 11/4/2010 4:21 PM, Antonio Petrelli wrote: 2010/11/4 Marshall Schor m...@schor.com: I not sure why you did the ant task to select/copy/rename some things - was that because you couldn't get the names right in the first place, or the wagon couldn't be configured to deploy just what you wanted? For renaming artifacts and to copy digests that otherwise are not accessible. Remember to activate this: http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#createChecksum Just checking my understanding: The normal deploy operation (which here we've disabled by saying skiptrue/skip) adds checksums when uploading to a repository. The Wagon upload goal doesn't do this. The install plugin (which installs to your local repo) normally (by default) doesn't do checksums. The solution to get the Wagon goal to upload things with checksums, is as follows: 1) First have the install phase run, with an override configuration to generate the checksums. This results in your local .m2 repo having the checksums. 2) Configure the Wagon plugin to upload from the local repo spot, and run after the install phase. Check passed :-D Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Best practice re: releasing large assembly artifacts
We have a multi-module Apache project, with an extra project just for specifying the aggregation of the parts (it has modules element) and doing the aggregate source and binary assemblies. These assemblies are fairly large - 16 mb each, by the time the javaDocs etc. are included. When a release happens, we previously have been putting these artifacts in the Apache distribution spot (only), for the Apache mirror system to make available - all works fine. Now, we are trying to better align with the Maven way, and are using Nexus. The default for assemblies will attach these 16 mb things as artifacts of the aggregation project, and mvn release:perform will put them into the Nexus repository. And when we then vote and the vote passes, they will get released from the staging spot in Nexus up to Maven central. Is this OK for these big assemblies (both binary and source)? I would also copy these to the Apache distribution spot, to have them automatically mirrored, in addition. Is this the right approach? I experimented with marking the binary assembly with the configuration attachfalse/attach - this works, and prevents it from going up to Nexus (and then on to Maven central), but has the bad side effect of preventing the maven-gpg-plugin from signing that artifact. This is because the maven gpg plugin only signs attached artifacts. So, I'm thinking the Maven standard conventional way is to just go ahead and include these big assemblies as attached artifacts, and let them take up space in Maven central, even though they're also in the conventional Apache distribution (with mirrors) system. Is that the best practice? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice re: releasing large assembly artifacts
Thanks! To summarize: Tell assemblies to attach - so the gpg plugin will do the code signing. Block the default deploy step. Use the Wagon plugin to deploy things. I not sure why you did the ant task to select/copy/rename some things - was that because you couldn't get the names right in the first place, or the wagon couldn't be configured to deploy just what you wanted? -Marshall On 11/4/2010 3:46 PM, Antonio Petrelli wrote: 2010/11/4 Marshall Schor m...@schor.com: Now, we are trying to better align with the Maven way, and are using Nexus. The default for assemblies will attach these 16 mb things as artifacts of the aggregation project, and mvn release:perform will put them into the Nexus repository. ... Is this OK for these big assemblies (both binary and source)? I would also copy these to the Apache distribution spot, to have them automatically mirrored, in addition. Is this the right approach? IMHO deploying assemblies in a Maven repository is entirely optional, since other developers rarely take these artifacts as a dependency. IOW, do it if you need it. I experimented with marking the binary assembly with the configuration attachfalse/attach - this works, and prevents it from going up to Nexus (and then on to Maven central), but has the bad side effect of preventing the maven-gpg-plugin from signing that artifact. This is because the maven gpg plugin only signs attached artifacts. There's another way, that I use with Tiles and Velocity: skip the deploy http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#skip and, in the deploy phase, I use Wagon plugin, with some tricks (install signatures in local repository, copy from local repository installed artifacts to target folder), to upload assemblies to their final place. You can see it working here: http://svn.eu.apache.org/repos/asf/tiles/framework/trunk/assembly/pom.xml See the apache-release profile. HTH Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice re: releasing large assembly artifacts
On 11/4/2010 4:21 PM, Antonio Petrelli wrote: 2010/11/4 Marshall Schor m...@schor.com: I not sure why you did the ant task to select/copy/rename some things - was that because you couldn't get the names right in the first place, or the wagon couldn't be configured to deploy just what you wanted? For renaming artifacts and to copy digests that otherwise are not accessible. Remember to activate this: http://maven.apache.org/plugins/maven-install-plugin/install-mojo.html#createChecksum Just checking my understanding: The normal deploy operation (which here we've disabled by saying skiptrue/skip) adds checksums when uploading to a repository. The Wagon upload goal doesn't do this. The install plugin (which installs to your local repo) normally (by default) doesn't do checksums. The solution to get the Wagon goal to upload things with checksums, is as follows: 1) First have the install phase run, with an override configuration to generate the checksums. This results in your local .m2 repo having the checksums. 2) Configure the Wagon plugin to upload from the local repo spot, and run after the install phase. -Marshall Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maybe bug in release plugin for computing next dev release?
I have a pom which has a property which has as a value 2.3.1-SNAPSHOT. The property is used to factor into one spot the version level for dependencies, where the dependencies are for other modules in a multi-module build (most of which have the same version level). When I do mvn release:prepare -DdryRun on a POM which includes this as a module, the release:prepare successfully updates the property, first, to 2.3.1 for the tag, and then, for the next development version, to 2.3.2-SNAPSHOT. I think it figures out that this property is being used as a dependency version value, and matches it to version levels of things in the Reactor, to figure out it needs updating. So far everything seems to be correct. But, if I do exactly the same thing, but leave off the -DdryRun, it updates the property, first (as before), to 2.3.1 for the tag, but then does *not* update it for the next development version. Any idea why? Is this a (known) bug? I can, of course, work around this by manually updating this property to the right level and committing that change to the trunk. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maybe bug in release plugin for computing next dev release?
On 11/1/2010 12:59 PM, Martin Gainty wrote: Hello Marshall Can you confirm the values of Ok set for checkpoint.check-in-development-version as in checkpoint.check-in-development-version=OK in release.properties file? I'm using Maven 3, with release plugin 2.1 The release.properties file doesn't have any elements starting with checkpoint. However, the development version was checked in because I can see the POM version of the projects were updated to the next development level 2.3.2-SNAPSHOT. Only the value under properties was not updated. -Marshall Schor thanks, Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 1 Nov 2010 12:26:27 -0400 From: m...@schor.com To: users@maven.apache.org CC: d...@uima.apache.org Subject: maybe bug in release plugin for computing next dev release? I have a pom which has a property which has as a value 2.3.1-SNAPSHOT. The property is used to factor into one spot the version level for dependencies, where the dependencies are for other modules in a multi-module build (most of which have the same version level). When I do mvn release:prepare -DdryRun on a POM which includes this as a module, the release:prepare successfully updates the property, first, to 2.3.1 for the tag, and then, for the next development version, to 2.3.2-SNAPSHOT. I think it figures out that this property is being used as a dependency version value, and matches it to version levels of things in the Reactor, to figure out it needs updating. So far everything seems to be correct. But, if I do exactly the same thing, but leave off the -DdryRun, it updates the property, first (as before), to 2.3.1 for the tag, but then does *not* update it for the next development version. Any idea why? Is this a (known) bug? I can, of course, work around this by manually updating this property to the right level and committing that change to the trunk. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maybe bug in release plugin for computing next dev release?
On 11/1/2010 1:51 PM, Brett Porter wrote: This was a known bug, fixed in maven-release-plugin 2.1. Are you using that release? Yes. 2.1 shows in the help:effective-pom, and in this info message at the top of the release:prepare: [INFO] --- maven-release-plugin:2.1:prepare (default-cli) -Marshall Schor On 01/11/2010, at 12:26 PM, Marshall Schor wrote: I have a pom which has a property which has as a value 2.3.1-SNAPSHOT. The property is used to factor into one spot the version level for dependencies, where the dependencies are for other modules in a multi-module build (most of which have the same version level). When I do mvn release:prepare -DdryRun on a POM which includes this as a module, the release:prepare successfully updates the property, first, to 2.3.1 for the tag, and then, for the next development version, to 2.3.2-SNAPSHOT. I think it figures out that this property is being used as a dependency version value, and matches it to version levels of things in the Reactor, to figure out it needs updating. So far everything seems to be correct. But, if I do exactly the same thing, but leave off the -DdryRun, it updates the property, first (as before), to 2.3.1 for the tag, but then does *not* update it for the next development version. Any idea why? Is this a (known) bug? I can, of course, work around this by manually updating this property to the right level and committing that change to the trunk. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maybe bug in release plugin for computing next dev release?
Here's a bit more info that might help debug this, perhaps. The release:prepare step shows, for the first transformation (from -SNAPSHOT to release) a mixture of Transforming and Updating messages, here's a sample [INFO] Transforming 'UIMA Base: uimaj-test-util: JUnit utilities'... [INFO] Transforming 'UIMA Base: uimaj-core'... [INFO] Updating uimaj-test-util to 2.3.1 [INFO] Transforming 'UIMA Base: jVinci: Vinci Transport Library'... [INFO] Transforming 'UIMA Base: uimaj-adapter-vinci: Vinci Adapter'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating jVinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-cpe: Collection Processing Engine'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating uimaj-adapter-vinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Updating jVinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Updating uimaj-test-util to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-document-annotation'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating uimaj-test-util to 2.3.1 The same messages, at the end of release:prepare, show only the Transforming messages: [INFO] Transforming 'UIMA Base: uimaj-test-util: JUnit utilities'... [INFO] Transforming 'UIMA Base: uimaj-core'... [INFO] Transforming 'UIMA Base: jVinci: Vinci Transport Library'... [INFO] Transforming 'UIMA Base: uimaj-adapter-vinci: Vinci Adapter'... [INFO] Transforming 'UIMA Base: uimaj-cpe: Collection Processing Engine [INFO] Transforming 'UIMA Base: uimaj-document-annotation'... [INFO] Transforming 'UIMA Base: uimaj-tools: Tools'... [INFO] Transforming 'UIMA Base: uimaj-examples: SDK Examples'... [INFO] Transforming 'UIMA Base: uimaj-adapter-soap: SOAP Adapter'... I think the Updating ... and Ignoring artifact version update... come from the part of the code that updates the properties. And these messages are missing in the 2nd transformation, which probably is indicative of this part of the code not running at this point, for some reason. -Marshall On 11/1/2010 2:01 PM, Marshall Schor wrote: On 11/1/2010 1:51 PM, Brett Porter wrote: This was a known bug, fixed in maven-release-plugin 2.1. Are you using that release? Yes. 2.1 shows in the help:effective-pom, and in this info message at the top of the release:prepare: [INFO] --- maven-release-plugin:2.1:prepare (default-cli) -Marshall Schor On 01/11/2010, at 12:26 PM, Marshall Schor wrote: I have a pom which has a property which has as a value 2.3.1-SNAPSHOT. The property is used to factor into one spot the version level for dependencies, where the dependencies are for other modules in a multi-module build (most of which have the same version level). When I do mvn release:prepare -DdryRun on a POM which includes this as a module, the release:prepare successfully updates the property, first, to 2.3.1 for the tag, and then, for the next development version, to 2.3.2-SNAPSHOT. I think it figures out that this property is being used as a dependency version value, and matches it to version levels of things in the Reactor, to figure out it needs updating. So far everything seems to be correct. But, if I do exactly the same thing, but leave off the -DdryRun, it updates the property, first (as before), to 2.3.1 for the tag, but then does *not* update it for the next development version. Any idea why? Is this a (known) bug? I can, of course, work around this by manually updating this property to the right level and committing that change to the trunk. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maybe bug in release plugin for computing next dev release?
On 11/1/2010 3:05 PM, Marshall Schor wrote: Here's a bit more info that might help debug this, perhaps. The release:prepare step shows, for the first transformation (from -SNAPSHOT to release) a mixture of Transforming and Updating messages, here's a sample [INFO] Transforming 'UIMA Base: uimaj-test-util: JUnit utilities'... [INFO] Transforming 'UIMA Base: uimaj-core'... [INFO] Updating uimaj-test-util to 2.3.1 [INFO] Transforming 'UIMA Base: jVinci: Vinci Transport Library'... [INFO] Transforming 'UIMA Base: uimaj-adapter-vinci: Vinci Adapter'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating jVinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-cpe: Collection Processing Engine'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating uimaj-adapter-vinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Updating jVinci to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Updating uimaj-test-util to 2.3.1 [INFO] Ignoring artifact version update for expression: 2.3.1 because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-document-annotation'... [INFO] Updating uimaj-core to 2.3.1 [INFO] Updating uimaj-test-util to 2.3.1 The same messages, at the end of release:prepare, show only the Transforming messages: [INFO] Transforming 'UIMA Base: uimaj-test-util: JUnit utilities'... [INFO] Transforming 'UIMA Base: uimaj-core'... [INFO] Transforming 'UIMA Base: jVinci: Vinci Transport Library'... [INFO] Transforming 'UIMA Base: uimaj-adapter-vinci: Vinci Adapter'... [INFO] Transforming 'UIMA Base: uimaj-cpe: Collection Processing Engine [INFO] Transforming 'UIMA Base: uimaj-document-annotation'... [INFO] Transforming 'UIMA Base: uimaj-tools: Tools'... [INFO] Transforming 'UIMA Base: uimaj-examples: SDK Examples'... [INFO] Transforming 'UIMA Base: uimaj-adapter-soap: SOAP Adapter'... These messages, from the release:prepare -DdryRun invocation were: [INFO] Transforming 'UIMA Base: uimaj-test-util: JUnit utilities'... [INFO] Transforming 'UIMA Base: uimaj-core'... [INFO] Updating uimaj-test-util to 2.3.2-SNAPSHOT [INFO] Transforming 'UIMA Base: jVinci: Vinci Transport Library'... [INFO] Transforming 'UIMA Base: uimaj-adapter-vinci: Vinci Adapter'... [INFO] Updating uimaj-core to 2.3.2-SNAPSHOT [INFO] Updating jVinci to 2.3.2-SNAPSHOT [INFO] Ignoring artifact version update for expression: 2.3.2-SNAPSHOT because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-cpe: Collection Processing Engine'... [INFO] Updating uimaj-core to 2.3.2-SNAPSHOT [INFO] Updating uimaj-adapter-vinci to 2.3.2-SNAPSHOT [INFO] Ignoring artifact version update for expression: 2.3.2-SNAPSHOT because it is already updated. [INFO] Updating jVinci to 2.3.2-SNAPSHOT [INFO] Ignoring artifact version update for expression: 2.3.2-SNAPSHOT because it is already updated. [INFO] Updating uimaj-test-util to 2.3.2-SNAPSHOT [INFO] Ignoring artifact version update for expression: 2.3.2-SNAPSHOT because it is already updated. [INFO] Transforming 'UIMA Base: uimaj-document-annotation'... [INFO] Updating uimaj-core to 2.3.2-SNAPSHOT [INFO] Updating uimaj-test-util to 2.3.2-SNAPSHOT I think the Updating ... and Ignoring artifact version update... come from the part of the code that updates the properties. And these messages are missing in the 2nd transformation, which probably is indicative of this part of the code not running at this point, for some reason. -Marshall On 11/1/2010 2:01 PM, Marshall Schor wrote: On 11/1/2010 1:51 PM, Brett Porter wrote: This was a known bug, fixed in maven-release-plugin 2.1. Are you using that release? Yes. 2.1 shows in the help:effective-pom, and in this info message at the top of the release:prepare: [INFO] --- maven-release-plugin:2.1:prepare (default-cli) -Marshall Schor On 01/11/2010, at 12:26 PM, Marshall Schor wrote: I have a pom which has a property which has as a value 2.3.1-SNAPSHOT. The property is used to factor into one spot the version level for dependencies, where the dependencies are for other modules in a multi-module build (most of which have the same version level). When I do mvn release:prepare -DdryRun on a POM which includes this as a module, the release:prepare successfully updates the property, first, to 2.3.1 for the tag, and then, for the next development version, to 2.3.2-SNAPSHOT. I think it figures out that this property is being used as a dependency version value, and matches it to version levels of things in the Reactor, to figure out it needs updating. So far everything seems to be correct. But, if I do exactly the same thing, but leave off the -DdryRun, it updates the property, first (as before), to 2.3.1 for the tag, but then does *not* update
Re: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
Thank you for your responses :-).
There are two ideas here:
1) have the configuration pick the right version, using
${project.parent.version}
2) refactor the parent into two parts, to avoid duplication.
1) is like the previous suggestion, but gets around the issue of having children
at different version levels. But 1) requires that you do 2), so that when you
build new sub-parent containing the reference to the build-resources-bundle, it
has now a parent at the proper version level to make that reference work.
This feels to me to be very clever, but perhaps brittle with respect to future
maintenance... but that could be fixed with some careful comments, I suppose.
1) also requires that all build parent-poms be at the same level, which I think
is fine, but is, again, somewhat brittle in the sense above.
I guess this brittleness can be avoided by not doing the 1) part, and instead,
hard-coding the version (maybe in just one place, using a property) in the
parent-pom with the configuration(s) referring to it.
-Marshall
On 10/28/2010 2:29 AM, Vincent Latombe wrote:
I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.
Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.
This way, you avoid duplication of configuration.
2010/10/28 Anders Hammar and...@hammar.net
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle project
containing various build resources, bundled into a Jar artifact. One
of
these
resources is used in configuring the maven remote-resources-plugin, for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare phase
to
go
and update the versions of these from 1-SNAPSHOT to 1 for the tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag
checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version of
the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two artifacts,
and
releasing the build-resources-bundle separately. This would require that
I
duplicate a bunch of things from the common project parent-pom, into the
build-resources-bundle, and do a separate release cycle, just for it, and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: avoiding dependency version number duplication
I may be over my head here, but I think that when you do a *release* (using the release plugin), there is an option to have a version of the pom created for the tag that has the properties fully resolved. See http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html Does this address your use case? -Marshall Schor On 10/26/2010 12:05 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict pbened...@apache.org wrote: I don't believe that's supposed to happen. I realized how vague my answer was. Sorry! I mean the replacement is NOT supposed to happen. It's a substitution variable. You won't get the real value in there because it's resolved at build time. Which is a problem because there's lots of other ways for that variable to be set that aren't going to be available after the pom is deployed. This has been argued about several times, and it looks like it's not going to get fixed because the maven people have something against having a build generate an appropriate pom for deployment. Babak, if you really want to make this work right, you're probably going to have to end up with a weird multi-stage build where first you generate the pom.xml file (perhaps with another pom.xml, or an ant build) and then build using the generated one. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
We have a common project parent-pom, and a build-resources-bundle project containing various build resources, bundled into a Jar artifact. One of these resources is used in configuring the maven remote-resources-plugin, for instance. We start with the configuration where both the parent-pom and build-resources-bundle are at version 1-SNAPSHOT. The parent-pom is set up as an aggregator pom, with one child: the build-resources-bundle project. Executing mvn release:prepare on the parent-pom causes the prepare phase to go and update the versions of these from 1-SNAPSHOT to 1 for the tag. However, this process does not notice that the remote-resource-plugin's configuration in the parent-pom is specifying the build-resources-bundle at version 1-SNAPSHOT - so that version is *not* updated. If a release:perform were to be done, it would build from the tag checkout, and configure the remote-resources-plugin to use the 1-SNAPSHOT version of the build-resources-bundle; I want it to be using the 1 version of the bundle. To work around this, I could run the release:prepare, and then update manually, the tag, to update the reference from 1-SNAPSHOT to 1. The other thing I could imagine doing is uncoupling these two artifacts, and releasing the build-resources-bundle separately. This would require that I duplicate a bunch of things from the common project parent-pom, into the build-resources-bundle, and do a separate release cycle, just for it, and then have the parent-pom depend on the released version. What is the maven way for doing this kind of thing? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-versions-plugin version comparism
This isn't easy to figure out, I think. Here's my guess.
The thing that explains this is here:
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html
This link is found by going to the below referenced link, and then, in that
code, clicking on the link to ComparableVersion
The part that is relevant is this bit:
148
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#148
*private* *static* *final* String[] QUALIFIERS = { alpha, beta,
milestone, rc, snapshot, , sp };
*public* *int* compareTo( Item item )
220
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#220
{
221
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#221
*if* ( item == *null* )
222
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#222
{
223
http://maven.apache.org/ref/3.0/maven-artifact/xref/org/apache/maven/artifact/versioning/ComparableVersion.html#223
/// 1-rc 1, 1-ga 1/
This means, I think (I didn't completely understand this code) that if the
qualifier string
following the dash is one of a small set of strings (such as strings starting
with
rc or snapshot, etc.) then the rule 1-rc 1 applies.
But if the string following the - is not one of these well known strings,
then that rule doesn't apply.
-Marshall Schor
On 10/21/2010 7:14 AM, Stephen Connolly wrote:
Did you read the FAQ?
http://mojo.codehaus.org/versions-maven-plugin/faq.html#comparisonMethod
On 21 October 2010 11:56, Moser, Christian c...@metrohm.com wrote:
I've got following effect with the maven versions plugin 1.2.
If we release a milestone of our software, we declare the components
which are included in the milestone with [version]-[unrel]-[revision].
When the software is in the release process, we remove the additional
declaration. For example: Version 1.1.0-unrel-0038381 will be
transformed to 1.1.0, so in fact, 1.1.0 is newer than
1.1.0-unrel-0038381.
I don't know why the plugin acts like this:
org.codehaus.mojo:versions-maven-plugin:1.2:display-dependency-updates
will
...
The following dependencies in Dependency Management have newer versions:
SnakeYAML:SnakeYAML ... 1.2 - 1.3
mnet:comp-accessoriesconfig . 1.1.0 - 1.1.0-unrel-0038381
mnet:comp-accessoriesconfig-if .. 1.1.0 - 1.1.0-unrel-0038381
mnet:comp-accessoriesconfigview . 1.1.0 - 1.2.0-unrel-0039226
mnet:comp-accessoriesconfigview-if .. 1.0.0 - 1.0.0-unrel-0027036
...
Do you know why?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-gpg-plugin gpg-agent
Just a guess: Check the gpg plugin configuration: gpg.useagenttrue/gpg.useagent This might be in in your poms or in your settings file? -Marshall Schor On 10/9/2010 5:35 PM, Hilco Wijbenga wrote: Hi all, I'm trying to build Spring's Roo and it wants to sign everything using the maven-gpg-plugin. This should be easy because I have gpg-agent running that should provide it with the passphrase. That doesn't happen and I'm forced to type the passphrase myself. A few dozen times. Does anyone know how to get maven-gpg-plugin to use gpg-agent's supplied passphrase? In fact, why doesn't it do this already given that (AFAIK) maven-gpg-plugin already uses gpg directly to do its thing? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ${version} in 3.0
also check parent poms.
-Marshall Schor
On 10/9/2010 8:35 PM, Niall Pemberton wrote:
On Sun, Oct 10, 2010 at 1:18 AM, Jason Chaffee jchaf...@ebates.com wrote:
I am getting this warning for every module, yet I am not using this variable
any of the poms. Some poms do have ${project.version} but some of them
don't have any variable expressions at all and it is still outputting this
warning.
Does this warning just get output regardless of what is the the pom?
[WARNING] The expression ${version} is deprecated. Please use
${project.version} instead.
What about other places like assembly plugin config files?
Niall
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: resources are not aggregated from parent to child pom
On 10/2/2010 7:42 AM, Benjamin Bentmann wrote: Xavier D. wrote: My pom structure is: pom.xml has a parent: parent-pom.xml. Both have aresources section to include files. The (child) pom.xml is executed directly and has the effect of only copying the child's resources. Commenting out this resource section, results in the parent's resources being copied. This is expected behavior, resources given in a child POM are not merged with resources in the parent but completely override those. I'm curious as to why this design decision was taken, versus an approach which allows merging, or perhaps some kind of user (pom - specified) choice. I was bitten by this also. -Marshall Schor Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies between modules of a multi module project
m2eclipse supports both styles of dependency resolution - 1) resolving using normal maven dependency resolution (usually, the prebuilt jar in the .m2 local repository), or 2) from the current workspace (allowing you to pick up changes there, even if the other project(s) weren't built/installed. This is described in the m2eclipse book, here: http://www.sonatype.com/books/m2eclipse-book/reference/dependencies.html#dependencies-sect-resolving-dependencies -Marshall Schor On 10/2/2010 7:22 AM, Antonio Petrelli wrote: 2010/10/2 Iron Eagle iron.ea...@gmx.at: Some times, I use the command line (there its no problem). But most time, I use eclipse. I've searched for a tutorial for that problem, but the result doesn't really satisfy me. If you use m2eclipse and you checkout the entire main pom project as Maven project, the project created for module B will have a reference to the project for module A. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC3
thanks! -Marshall On 10/1/2010 6:31 AM, Benjamin Bentmann wrote: Marshall Schor wrote: Is a workaround (until Nexus is patched), to use -Dmaven.metadata.legacy=true on the maven command line? The workaround is no longer necessary to deploy Apache snapshots, r.a.o has been updated to Nexus 1.8.0 by now. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC3
Tried building our project (uima) - that works, but the deploy (snapshot) deploys a broken file. The file under version-SNAPSHOT/maven-metadata.xml can't be read using http://repository.apache.org/snapshots/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/maven-metadata.xml. A build referring to this gets: [DEBUG] Could not find metadata org.apache.uima:parent-pom-docbook:4-SNAPSHOT/maven-metadata.xml [DEBUG] Using connector WagonRepositoryConnector with priority 0 for http://repository.apache.org/snapshots Downloading: http://repository.apache.org/snapshots/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/maven-metadata.xml [DEBUG] Reading resolution tracking file /home/schor/.m2/repository/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/resolver-status.properties [DEBUG] Writing resolution tracking file /home/schor/.m2/repository/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/resolver-status.properties [DEBUG] Could not find metadata org.apache.uima:parent-pom-docbook:4-SNAPSHOT/maven-metadata.xml in apache.snapshots (http://repository.apache.org/snapshots) If you try that URL in a browser, it returns some message saying the file isn't there. (However, if you try the alternative way to get a file in Nexus: going to the url: http://repository.apache.org , and then clicking on the snapshot repositories, and then navigating to org/apache/uima/parent-pom-docbook/4-SNAPSHOT, you can right click the maven-metadata.xml file and the repository browser pops up a download button, which does work.) A workaround is to use mvn 3.0-beta-1 - it doesn't exhibit this problem, and the deploy to the snapshot works fine; browsing to maven-metadata.xml shows the file in the browser. I compared the two files in my local .m2 repos which I'm guessing are the local copies that are copied up to the server: these are named in the local repo: maven-metadata-apache.snapshots.https.xml The files differ: the RC3 version's top XML element is: metadata modelVersion=1.1.0 The 3.0-beta-1's top element is: metadata xsi:schemaLocation=http://maven.apache.org/METADATA/1.0.0 http://maven.apache.org/xsd/metadata-1.0.0.xsd; xmlns=http://maven.apache.org/METADATA/1.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; So - it looks like RC3 is missing the namespaces declarations? (I think this is also true for RC2). -Marshall Schor On 9/26/2010 12:24 PM, Benjamin Bentmann wrote: Hi, in preparation for the release of Apache Maven 3.0, the Maven team is seeking your help to discover regressions since Maven 2.x. Everybody interested in taking a preview of the upcoming release for a test drive can get source and binary bundles from this URL: https://repository.apache.org/content/repositories/maven-014/org/apache/maven/apache-maven/3.0-RC3/ Before reporting any issues found during testing, please be sure to have a close look at the compatibility notes for Maven 3.x: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes If you encounter unexpected build issues, please fill a report in JIRA that provides sufficient information to reproduce and analyze the issue: http://jira.codehaus.org/browse/MNG The fixes contained in this release candidate since the 3.0-beta-3 release and the previous release candidates can be seen in JIRA: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=13142 Thanks, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC3
On 9/30/2010 9:34 AM, Benjamin Bentmann wrote: Marshall Schor wrote: The file underversion-SNAPSHOT/maven-metadata.xml can't be read using http://repository.apache.org/snapshots/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/maven-metadata.xml. r.a.o/snapshots is a group, the actual repository contains the intact file: https://repository.apache.org/content/repositories/snapshots/org/apache/uima/parent-pom-docbook/4-SNAPSHOT/maven-metadata.xml So - it looks like RC3 is missing the namespaces declarations? The namespace declaration isn't relevant (Maven 2.x doesn't specify it either), the failure is due to the file's extended format, see also [0]. Is a workaround (until Nexus is patched), to use -Dmaven.metadata.legacy=true on the maven command line? -Marshall Schor I know that Nexus has already been updated to support this, will check whether this update/patch can be installed on r.a.o. Benjamin [0] https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-UniqueSnapshotVersionsandClassifiers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multi-module project versioning question
I'm not a maven expert, so others may chime in with corrections/ improvements :-) Here's how I think about this. First, I separate out the idea of parent and aggregator, using parent to denote POMs that factor out common settings from their children, and using aggregator to denote POMs that have a modules element, specifying sub-projects to build together. In fact, these can be entirely separate POMs - since they're for different purposes. You could, even, have several different aggregator projects, over the same set of sub-modules, if that made sense. Then, for releasing, you have a choice: 1) release one (sub) project by itself 2) release several (sub) projects together 3) use an aggregator project to release several projects together. So, in your case, you could release the aggregator project at level 1.0, and then, if you no longer desired to have all the sub-projects at the same level (as you seem to indicate), you could subsequently release just the child-web project. There could be potentially some difference in the builds done by default for an aggregator project versus doing an individual sub-project build. For instance, a common practice is to have the top-most project (the aggregator, for instance), do a consolidated source-release zip packaging over all the submodules. If you built just one project, that project would, of course, have its own source-release zip package. So, I think it's up to you, how you want to manage this. Does this make sense? Or am I missing the main point? -Marshall Schor On 9/29/2010 4:29 PM, Nathaniel Auvil wrote: I am trying to figure out how to leverage mult-module builds in maven. Say i have a project defined as: parent child-core child-service child-web where both child-service and child-web are dependent on child-core ok. i do a first release and everything is at version 1.0 as in: parent (1.0) child-core (1.0) child-service (1.0) child-web (1.0) Some days later there is a bug in the child-web project. What i _want_ is... parent (1.1) child-core (1.0) child-service (1.0) child-web (1.1) how can i do this with maven? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Specifying Multi-value parameters with custom plugin
Just a guess:
Maybe the getItems and setItems methods are not correct?
getItems should return items, and setItems should set items = labels ?
-Marshall Schor
On 9/22/2010 2:52 AM, Xavier D. wrote:
I have written a multi-value plugin with parameter:
/**
* @required
* @parameter
*/
private String[] items;
public String[] getItems(){}
public void setItems(String[] labels) {}
However, mvn reports an error that it is not configured
(itemsVALUE/items) whenever I try to specify the configuration as:
configuration
items
item1/item
item2/item
label3/item
/items
or as:
items
param1/param
param2/param
param3/param
/items
Xavier
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Here's what I think I've learned. The release plugin operates in an unusual way, in that there are two invocations of work, the outer invocation, and an inner one. The inner one is evidenced in the output by having output lines to the console that have two prefixes: [INFO] [INFO] message... The inner one is run with profiles that can be set using the release plugin's configuration parameters: useReleaseProfilefalse/useReleaseProfile arguments-Papache-release/arguments These settings *do-not* affect the running of the outer invocation. The outer invocation, when passed a multi-module configuration, does a couple of interesting things: 1) it sets itself up so it SKIPS all the module processing. You can see this in the build at the end, where it displays a summary of the build steps, and it shows all the other modules in the build with a line: [INFO] ...name... SKIPPED 2) Nevertheless, it uses all the information about all of the projects in the Reactor, to walk through all of them, and do various operations on all of them. These include manipulating the poms to new versions. (This information is also used during release:clean - to clean up all the submodules.) This is why it is able to find and update inter-dependent sets of modules, at -SNAPSHOT levels, and update all of them. The message There are still some remaining snapshot dependencies - comes after the inter-dependent set of modules have been processed to update from the -SNAPSHOT levels. This the meaning of the word *still*, here. This message isn't given if all of the -SNAPSHOTs were resolved during the processing of all the modules in the Reactor in the outer invocation. Maybe one of the implementors of the release plugin can confirm this theory :-). -Marshall On 9/26/2010 5:45 AM, Antonio Petrelli wrote: 2010/9/26 Marshall Schor m...@schor.com: I guess the super-pom turning on apache-release happened after my profile in my top level aggregator project was processed, maybe... (not sure about this). Mmm... Here it is: https://repository.apache.org/service/local/repositories/releases/content/org/apache/apache/7/apache-7.pom The only relevant thing I see is a different configuration of the deploy plugin: updateReleaseInfotrue/updateReleaseInfo Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
Hi, Nicola, Thanks for responding! That wasn't my issue. The release plugin (as of version 2.0) does support flat hierarchies, I'm pretty sure. See for instance, http://brettporter.wordpress.com/2010/01/29/updated-multi-module-support-for-maven-release-plugin/ See my recent post for what the underlying cause of my problem was. Thanks, again. -Marshall Schor On 9/27/2010 8:01 AM, Nicola Musatti wrote: Hallo, Marshall. By flat hierarchy do you mean that the aggregator project directory is not the parent directory of your modules' directories, but resides side by side with them? If so, this may be your problem. I believe that the release plugin expects the modules to reside in subdirectories of the aggregator's directory. Moreover this is to be the case even within your version control system, i.e. Subversion externals or similar mechanisms are not handled properly. Cheers, Nicola Musatti Marshall Schor wrote: Hi, I have a multi-module project, using a *flat* hierarchy. The top pom I'm running the mvn release:prepare -DdryRun=ture command has a modules section which specifies the submodules. The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT. The top pom has *some* of the submodules also listed asdependencies, with the 2.3.1-SNAPSHOT version. When I run the release:prepare goal, it asks me if I want to resolve snapshots, just for those listed independencies. I say yes, and select 1:Project Dependencies at the next prompt. For all dependencies listed independencies it then asks if I want to set to release*; I say yes, and also take the default for the next version. Then it's off and running, and after a while says BUILD SUCCESS. It appears to have prepared poms for the top pom that reflect updating for the release version, OK (the release version of the pom is 2.3.1, without the -SNAPSHOT, etc.). But it did not change any poms for the projects built underneath (the ones in themodules section). Also, a submodule's target/xxx.pom shows the -SNAPSHOT version still. Perhaps I have a mistaken idea hear. I thought that if my multi-module project hadmodule parts with a -SNAPSHOT version, that releasing the top-pom would result in *all* of the modules getting their version updated. What is the right way to get all these modules released, in one go, with their versions switched from -SNAPSHOT to the release version? (Tried using release plugin version 2.0, trying both maven 3.0-beta-1 and 3.0-RC2 - same results.) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non gli sia pervenuto per errore. In tal caso e' pregato di avvisare immediatamente il mittente e, tenuto conto delle responsabilita' connesse all'indebito utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso contenute, voglia cancellare l'originale e distruggere le varie copie o stampe. The receiver of this message is required to check if he/she has received it erroneously. If so, the receiver is requested to immediately inform the sender and - in consideration of the responsibilities arising from undue use and/or disclosure of the message and/or the information contained therein - destroy the original message and any copy or printout thereof. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
On 9/27/2010 6:29 AM, Marshall Schor wrote: Here's what I think I've learned. The release plugin operates in an unusual way, in that there are two invocations of work, the outer invocation, and an inner one. The inner one is evidenced in the output by having output lines to the console that have two prefixes: [INFO] [INFO] message... The inner one is run with profiles that can be set using the release plugin's configuration parameters: useReleaseProfilefalse/useReleaseProfile arguments-Papache-release/arguments These settings *do-not* affect the running of the outer invocation. The outer invocation, when passed a multi-module configuration, does a couple of interesting things: 1) it sets itself up so it SKIPS all the module processing. You can see this in the build at the end, where it displays a summary of the build steps, and it shows all the other modules in the build with a line: [INFO] ...name... SKIPPED Here's how it does that: Each mojo (corresponds to a goal) in the release plugin which operates this way, is annotated with @aggregator. See http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugin-descriptor.html and search for aggregator. -Marshall Schor http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugin-descriptor.html 2) Nevertheless, it uses all the information about all of the projects in the Reactor, to walk through all of them, and do various operations on all of them. These include manipulating the poms to new versions. (This information is also used during release:clean - to clean up all the submodules.) This is why it is able to find and update inter-dependent sets of modules, at -SNAPSHOT levels, and update all of them. The message There are still some remaining snapshot dependencies - comes after the inter-dependent set of modules have been processed to update from the -SNAPSHOT levels. This the meaning of the word *still*, here. This message isn't given if all of the -SNAPSHOTs were resolved during the processing of all the modules in the Reactor in the outer invocation. Maybe one of the implementors of the release plugin can confirm this theory :-). -Marshall On 9/26/2010 5:45 AM, Antonio Petrelli wrote: 2010/9/26 Marshall Schor m...@schor.com: I guess the super-pom turning on apache-release happened after my profile in my top level aggregator project was processed, maybe... (not sure about this). Mmm... Here it is: https://repository.apache.org/service/local/repositories/releases/content/org/apache/apache/7/apache-7.pom The only relevant thing I see is a different configuration of the deploy plugin: updateReleaseInfotrue/updateReleaseInfo Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
I think I've figured out a way around this issue. I did it by doing a very simple test case, where I had an aggregate project, with a submodule *not* specifying the aggregate as the parent. The simple case worked! So, I then gradually narrowed the differences between my test project and my real project, until I found the cause. The cause was that the modules element in my top aggregator pom was inside a profile with id apache-release. The super pom chain of all the poms includes the common Apache pom (org.apache:apache:7), which itself has a profile for apache-release, and also configures the release plugin to use that profile for releasing. The workaround seems to be that I need to specify -Papache-release on my top level mvn command - then two things happen: 1) I no longer get the message: There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : Instead, it just proceeds to ask me about the submodules. 2) It finds and processes the submodules, generating the updated poms for those. I guess the super-pom turning on apache-release happened after my profile in my top level aggregator project was processed, maybe... (not sure about this). -Marshall Schor On 9/25/2010 4:51 AM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: On 9/24/2010 3:22 PM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: Are you saying that the Maven Release plugin, in particular, has the restriction that in order for it to work, it the multimodule project has to be the parent? At this point I really don't know, since I always had modules that have the container as a parent, never tried in another way. Just a question: when you run release:prepare, does it ask you versions for every single module? No, it asks just for versions where I had specified a dependency in the top pom. It's as if the release plugin is set up to only work at the top pom, and not run on the modules within (although it does run the build actions on the modules within). Ok. Instead if you have child modules with the container pom as parent, it asks versions for every module. I'm kind of stumped on how to work around this. Just a shot in the dark, try: http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#autoVersionSubmodules Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Multi-module release, converting -SNAPSHOTs to release versions
Hi, I have a multi-module project, using a *flat* hierarchy. The top pom I'm running the mvn release:prepare -DdryRun=ture command has a modules section which specifies the submodules. The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT. The top pom has *some* of the submodules also listed as dependencies, with the 2.3.1-SNAPSHOT version. When I run the release:prepare goal, it asks me if I want to resolve snapshots, just for those listed in dependencies. I say yes, and select 1:Project Dependencies at the next prompt. For all dependencies listed in dependencies it then asks if I want to set to release*; I say yes, and also take the default for the next version. Then it's off and running, and after a while says BUILD SUCCESS. It appears to have prepared poms for the top pom that reflect updating for the release version, OK (the release version of the pom is 2.3.1, without the -SNAPSHOT, etc.). But it did not change any poms for the projects built underneath (the ones in the modules section). Also, a submodule's target/xxx.pom shows the -SNAPSHOT version still. Perhaps I have a mistaken idea hear. I thought that if my multi-module project had module parts with a -SNAPSHOT version, that releasing the top-pom would result in *all* of the modules getting their version updated. What is the right way to get all these modules released, in one go, with their versions switched from -SNAPSHOT to the release version? (Tried using release plugin version 2.0, trying both maven 3.0-beta-1 and 3.0-RC2 - same results.) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
one more note: Some references I found on the web seemed to indicate that multi-module releasing would work to update sub-poms, but their examples had used the aggregator-pom (the one with the modules) also as the parent pom. In our poms, we've separated Parent-Poms from aggregator-poms; so in our case, the top pom is *not* the parent of any other pom. Is it required that the aggregator pom also be the parent, for this to work? -Marshall Schor On 9/24/2010 12:23 PM, Marshall Schor wrote: Hi, I have a multi-module project, using a *flat* hierarchy. The top pom I'm running the mvn release:prepare -DdryRun=ture command has a modules section which specifies the submodules. The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT. The top pom has *some* of the submodules also listed as dependencies, with the 2.3.1-SNAPSHOT version. When I run the release:prepare goal, it asks me if I want to resolve snapshots, just for those listed in dependencies. I say yes, and select 1:Project Dependencies at the next prompt. For all dependencies listed in dependencies it then asks if I want to set to release*; I say yes, and also take the default for the next version. Then it's off and running, and after a while says BUILD SUCCESS. It appears to have prepared poms for the top pom that reflect updating for the release version, OK (the release version of the pom is 2.3.1, without the -SNAPSHOT, etc.). But it did not change any poms for the projects built underneath (the ones in the modules section). Also, a submodule's target/xxx.pom shows the -SNAPSHOT version still. Perhaps I have a mistaken idea hear. I thought that if my multi-module project had module parts with a -SNAPSHOT version, that releasing the top-pom would result in *all* of the modules getting their version updated. What is the right way to get all these modules released, in one go, with their versions switched from -SNAPSHOT to the release version? (Tried using release plugin version 2.0, trying both maven 3.0-beta-1 and 3.0-RC2 - same results.) -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
On 9/24/2010 2:08 PM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT. The top pom has *some* of the submodules also listed as dependencies, with the 2.3.1-SNAPSHOT version. This does not make any sense, this is a circular dependency, Can you please help explain where the circularity comes in? Are you assuming that the sub-modules have a reference to the top pom? (Maybe you assumed they used the top pom as a parent? - but they don't). and a pom project usually (I'd say *always*) does not need dependencies at all. Yes, in this case, I think you're right, and I could remove these dependencies in the top pom. (They were put in at one point I think when we were contemplating an alternative release strategy). But I don't think that would change my outcome (see below). I suspect that one ore more modules depend on others. They do. They have inter-module dependencies. They build just fine. The release:prepare does invoke a build of all the submodules, and they all build OK. The only thing that doesn't seem to be happening is the updating of the pom versions on those subprojects, which I (maybe incorrectly) assumed the release plugin would do. It does update the versions ok on the top pom (only). Thanks for your help. -Marshall Schor You have to add dependencies to those modules, not in the pom project. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
This is interesting! The example you pointed to indicates in the section http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance_vs_Project_Aggregation that the parent project can serve for refactoring out common configurations and settings. It also says you can have a multi-module project (which it also calls a parent project - but I think this is quite confusing, and prefer to use the term aggregation or multi-module project) which specifies the modules to be built together. It then says that these two POMs, can be the same, which is not the same of course as saying they *must* be the same. This reference (from the Maven - the Complete Reference book), http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html#pom-relationships-sect-multi-vs-inherit shows a counter example, where these two POMs are not the same: see 3.6.2.1 Simple Project. Here, they are using a pom to do aggregation for multi-submodules, and each of those submodules does *not* have that aggregation POM as its parent. The documentation seems to clearly distinguish parent-poms referred to using the parent element in another pom -- used for factoring out common things shared by may child poms -- from aggregation or multimodule project - specifying what a build should include. So, this is how we have structured things. The parent element refers to poms that are holding common factored-out settings, while the pom we use for building/releasing, is just one that gathers all the different submodules together. We don't make these the same, because different submodules have different parents (because different kinds of submodules have differing common parts factored out into the parent). As I've said previously, the other parts of Maven operation (building, installing, etc.) seem to work just fine with this setup. Are you saying that the Maven Release plugin, in particular, has the restriction that in order for it to work, it the multimodule project has to be the parent? -Marshall Schor On 9/24/2010 2:24 PM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: On 9/24/2010 2:08 PM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: The top pom and all the poms in the submodules have version numbers 2.3.1-SNAPSHOT. The top pom has *some* of the submodules also listed as dependencies, with the 2.3.1-SNAPSHOT version. This does not make any sense, this is a circular dependency, Can you please help explain where the circularity comes in? Are you assuming that the sub-modules have a reference to the top pom? (Maybe you assumed they used the top pom as a parent? - but they don't). They don't? It's wrong then: http://docs.codehaus.org/display/MAVENUSER/Multi-modules+projects Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module release, converting -SNAPSHOTs to release versions
On 9/24/2010 3:22 PM, Antonio Petrelli wrote: 2010/9/24 Marshall Schor m...@schor.com: Are you saying that the Maven Release plugin, in particular, has the restriction that in order for it to work, it the multimodule project has to be the parent? At this point I really don't know, since I always had modules that have the container as a parent, never tried in another way. Just a question: when you run release:prepare, does it ask you versions for every single module? No, it asks just for versions where I had specified a dependency in the top pom. It's as if the release plugin is set up to only work at the top pom, and not run on the modules within (although it does run the build actions on the modules within). I see the release plugin is setup to have its execution inherited by child poms - it has inheritedByDefaulttrue/inheritedByDefault as part of its plugin.xml configuration. Maybe this is why it gets executed on submodules, if those submodules declare the aggregating pom as a parent. I'm kind of stumped on how to work around this. The only thing that comes to mind is to take the Reactor order for all the submodules, and run mvn release on each one, separately, and then change the aggregator pom to no longer do aggregation, but instead, just build the release artifacts (big zips of the various components), using the already released parts. -Marshall Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to contact uploader to maven central of org.eclipse.core artifacts
On 9/9/2010 11:59 AM, Brian Fox wrote: This should be fixed now. I just now went to maven central, and looked up this example, and see it is just the same as before. (I even tried clearing all the settings out of an extra browser I use occasionally, to insure nothing was being cached). So I'm confused - it seems to me it is not fixed? What (if anything) changed? -Marshall Schor On Tue, Sep 7, 2010 at 12:27 PM, Marshall Schor m...@schor.com wrote: Today, Maven central was updated with incomplete uploads of several eclipse artifacts: see http://repo2.maven.org/maven2/org/eclipse/core and within that directory are the following subdirectories: org.eclipse.core.contenttype/ 07-Sep-2010 06:27 org.eclipse.core.expressions/ 07-Sep-2010 06:27 org.eclipse.core.filesystem/ 07-Sep-2010 06:27 org.eclipse.core.jobs/ 07-Sep-2010 06:27 org.eclipse.core.resources/07-Sep-2010 06:27 org.eclipse.core.runtime/ 07-Sep-2010 06:27 org.eclipse.core.runtime.compatibility.auth/ 07-Sep-2010 06:27 org.eclipse.core.variables/07-Sep-2010 06:27 Each of these directories has just the maven-metadata.xml file (plus checksums), but no poms, etc. Here's a sample: maven-metadata.xml 03-Sep-2010 12:30 maven-metadata.xml.md5 03-Sep-2010 12:30 maven-metadata.xml.sha103-Sep-2010 12:30 Is this a failure to complete an upload to central? Should someone be contacted to fix this (and if so, who?)? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-gpg-plugin blocked during the execution
Another approach is to install a version of the underlying gpg which includes support for an agent. Then, when gpg needs to get your pass phrase, it asks the agent. The agent pops up an interactive window, and gets your pass phrase, right when it needs it. It then keeps it around for a few minutes, in case you're running things which which need lots of signings, so it doesn't bother you for the pass phrase all the time. To activate this capability in your maven settings file, you add gpg.useagenttrue/gpg.useagent -Marshall Schor On 9/10/2010 1:29 PM, Simone Tripodi wrote: Hi Kalle, thanks a lot for your help, very appreciated. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Sep 10, 2010 at 7:06 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: You need to specify: mavenExecutorIdforked-path/mavenExecutorId in release plugin configuration. See http://jira.codehaus.org/browse/MGPG-9 Kalle On Fri, Sep 10, 2010 at 9:30 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all guys, using the maven-release-plugin and signing artifacts with GnuPG, during the verifying phase, when the gpg-plugin is invoked, the build process is completely stalled. If I don't pass the gpg.passphare I'd expect it would be asked in the prompt, but it doesn't happen :( Follow below my attempts: mvn release:prepare -DdryRun=true -Darguments=-Dgpg.keyname=\ -Dgpg.passphrase= mvn release:prepare -DdryRun=true -Dgpg.passphrase= -PXXX (the keyname is defined as property in the XXX profile) mvn release:prepare -DdryRun=true (tried to insert gpg.passphrase in the prompt) Do you have any idea why? Many thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to contact uploader to maven central of org.eclipse.core artifacts
Today, Maven central was updated with incomplete uploads of several eclipse artifacts: see http://repo2.maven.org/maven2/org/eclipse/core and within that directory are the following subdirectories: org.eclipse.core.contenttype/ 07-Sep-2010 06:27 org.eclipse.core.expressions/ 07-Sep-2010 06:27 org.eclipse.core.filesystem/ 07-Sep-2010 06:27 org.eclipse.core.jobs/ 07-Sep-2010 06:27 org.eclipse.core.resources/07-Sep-2010 06:27 org.eclipse.core.runtime/ 07-Sep-2010 06:27 org.eclipse.core.runtime.compatibility.auth/ 07-Sep-2010 06:27 org.eclipse.core.variables/07-Sep-2010 06:27 Each of these directories has just the maven-metadata.xml file (plus checksums), but no poms, etc. Here's a sample: maven-metadata.xml 03-Sep-2010 12:30 maven-metadata.xml.md5 03-Sep-2010 12:30 maven-metadata.xml.sha103-Sep-2010 12:30 Is this a failure to complete an upload to central? Should someone be contacted to fix this (and if so, who?)? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: nexus, local repository, and m2eclipse
Maybe a good idea is to put a pointer to the nexus list in the most obvious place(s) people would look in the Maven on-line docs, saying something like for questions about Nexus, please post to the Nexus mailing list(s) found here. That way, users would get just in time education :-). -Marshall Schor On 8/23/2010 4:02 PM, Wayne Fay wrote: I didn't know there was a nexus list. Thanks. This happens often. I don't know why there is such confusion. Perhaps the Sonatype folks need to make this more obvious somewhere on the Nexus site? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
property substitution problem in build finalName
In my build I set the build final name for some things using
finalNamea.b.c_${parsedVersion.osgiVersion}/finalName
where ${parsedVersion.osgiVersion} is a parameter value set by executing the
maven-build-helper plugin which is the first plugin run when the build executes
(I checked this and observed it, using the -X debug flag).
If I use the maven-jar-plugin to build the jar, it gets the value of
finalName, which, I suspect, is
a.b.c_${parsedVersion.osgiVersion} and then changes it by substituting the
value of that property, so it comes out something like
a.b.c_2.3.1.
This works fine (it's just what I want) when I use the maven-jar-plugin.
However, I'm now using for some projects the maven-bundle-plugin (groupId
org.apache.felix). This plugin, when it is given the same string, appears to
not rescan it for variables, and does not therefore substitute values. So, its
bundle goal works, but generates the artifact using the name
a.b.c_${parsedVersion.osgiVersion}, which is, obviously, not what I need.
To work around this, I can run an ant-run build step to rename this file. I'm
guessing however, that there could likely be other metadata around that's being
associated to this name, and therefore, this might not be effective.
Maybe I need to do both an ant-run rename, plus a
maven-build-helper:attach-artifact to re-mark the renamed jar as the primary
artifact?
Does anyone have a less kludgy workaround for this kind of issue?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Configuring Authentication: How to specify scm username/password in settings.xml instead of pom.xml
also, for encryption, read http://maven.apache.org/guides/mini/guide-encryption.html -Marshall Schor On 7/23/2010 3:04 AM, Stefan Cordes wrote: Hi! On http://maven.apache.org/scm/maven-scm-plugin/examples/bootstrapping-with-pom.html it is just stated that username/password can be stored in the pom.xml. How to specify it in the settings.xml? -- RSC Commercial Services OHG Wanheimer Strasse 70, D-40468 Duesseldorf Registergericht: Duesseldorf, HRA 12655 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release plugin issue
I'm also using a flat structure. I found that the keys to making this work seem to be: 1) use release 2.0 of the release plugin. This is the release with the support for flat hierarchies. Note that the Apache common parent POM version 7 (the latest) still doesn't specify this release, it specifies an earlier one (2.0-beta-9) which doesn't have this support, so you have to override that - if you're using the Apache common parent pom (i.e. http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ). 2) in each pom in the flat hierarchy, insure the scm element is pointing to the right place in your SVN or whatever. If you let these inherit from parent poms, the inheritance makes often wrong assumptions that the children of the parent are located underneath the parent pom directory. Specifying the actual location overrides this behavior. -Marshall Schor On 7/9/2010 11:28 AM, DeGrande, Rick wrote: I've configured the release plugin in my build. I'm using a flat directory structure like: Aggregator Common Ejb Web When I do a release:prepare from the aggregator directory everything seems to work however the aggregator/... is the only path labeled. Also, when I do a release:perform from the aggregator directory it fails looking for the sibling directories in the aggregator/target/sibling. Maven identifies aggregator/target/checkout as the working directory. Is this because of the directory structure I'm using ? Does the release-plugin only work with a hierarchical dir? Is there a way around this or do I need to change the dir structure I'm using ? Thanks - The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-antrun-plugin not working
I don't think this is a bug. Renaming the id to default-cli makes
it work (tested with maven 3.0-beta-1):
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
executions
execution
!--idechodir/id-- !-- CHANGE THIS TO
--
iddefault-cli/id !-- CHANGED VALUE
--
goals
goalrun/goal
/goals
phaseverify/phase
inheritedfalse/inherited
configuration
tasks
!-- echoBuild Dir:
${project.build.directory}/echo
--
echoarbi test echo/echo
/tasks
/configuration
/execution
/executions
/plugin
The reason for this is that there is often a confusion about how to use
the mvn xxx command. If you type mvn --help it says:
usage: mvn [options] [goal(s)] [phase(s)]
This means, you type mvn, the options, and 0 or more goals or 0 or
more phases. The phases are things like install or package or
deploy. This means to run whatever lifecycle is appropriate for the
POM in the current directory, up to and including that phase, and stop.
The goals are very different - they say run a particular plugin goal.
So, for instance, saying mvn antrun:run runs the run goal in the
antrun plugin.
The POM can specify configuration for different invocations of the
plugin; these are identified by the id tag in the execution.
When a plugin is run by specifying mvn plugin-name:goal-name style,
then the id which is used to configure the plugin for that invocation
is named (by convention :-) ) default-cli - which stands for the the
default command-line interface invocation.
That's why changing the id to that value makes that configuration used
when you invoke it using the mvn antrun:run command line.
-Marshall Schor
It can run specific goals, specified by
On 7/2/2010 9:19 AM, asookazian wrote:
I am reproducing the error with maven-antrun-plugin 1.5-SNAPSHOT and Maven
3.0-BETA1. Is there a JIRA filed for this?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: making a zip of a bunch of jar-with-dependency jars stored in Nexus
Hi Ron, Did you read the documentation for writing descriptors for the assembly plugin? For instance, it has this bit: http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet with the parameter: |useTransitiveDependencies| Determines whether transitive dependencies will be included in the processing of the current dependency set. If true, includes/excludes/useTransitiveFiltering will apply to transitive dependency artifacts in addition to the main project dependency artifacts. If false, useTransitiveFiltering is meaningless, and includes/excludes only affect the immediate dependencies of the project. By default, this value is true. (Since 2.2) The default value is |true|. maybe setting this to false would work for you? -Marshall On 6/30/2010 10:59 AM, Ron Wheeler wrote: I am still struggling with this little task. I am trying to get a tar that contains a bunch of jars that were created using the assembly plug-in as jar-with-dependency. How can this be done? Using the assembly plug-in with dependencyset gets the jars that I want but also adds all of the jars that are already in the jar-with-dependency jars. I can exclude the transitive dependencies in the pom but that creates a maintenance headache since I will have 1 pom that sets them as dependencies to create the jar-with-dependencies and another that has 60+ exclusion to stop them. Is there another way to specify artifacts from Nexus other than dependencySet? Thanks for everyone's help and patience. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
building source-release.zip artifacts for Apache multi-module aggregator projects
The Apache common top-level pom ( http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) has a profile activated when doing releases, which invokes the maven-assembly-plugin to build the source-release.zip artifact. For single module (non-aggregate projects) this seems fine. For multi-module (aggregator-pom) projects, I think this only builds the source-release for the aggregator project by itself, unless the maven convention of having the directory layout have the aggregator pom in a directory which contains all the sub-projects. In our case, we have a flat hierarchy (actually, not exactly - we collect various parent-poms into one directory). My first attempt to alter our release -build process was to include in the maven-assembly-plugin descriptor a moduleSets section, to use the information in the aggregator modules element to locate and include all the subprojects. This kind of worked, but not quite, because it imposed a particular directory layout on the result, which didn't exactly match the SVN and working copy directory layout. (This was because I had put all of our parent-poms under one additional directory, just to keep things nicely organized ... ) After thinking more about this, it seems that the source-release.zip package should include just exactly what is in the SVN, starting with a directory there which is common among all the parts (the aggregating pom, and all of the projects being aggregated), but filtered to exclude all those things not in the set of artifacts being released. For example, in this layout (SVN and working copy): some-top-lvl-common-dir | +- aggregate-project | | | +- aggregate-pom.xml +- parent-poms | | | +- parent1-project | | | | | +- parent1.xml | +- parent2-project | | | | | +- parent2.xml +- some-non-released-thing the some-non-released-thing would be filtered, since it wasn't a module or the aggregate project. Does this sound like the right way to package source-releases for arbitrary layout SVN multi-module Apache projects? If so, is there a plugin which does this? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: building source-release.zip artifacts for Apache multi-module aggregator projects
On 6/28/2010 9:52 AM, Marshall Schor wrote: The Apache common top-level pom ( http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) has a profile activated when doing releases, which invokes the maven-assembly-plugin to build the source-release.zip artifact. I meant to include that Apache source releases are supposed to have what is needed to build the artifact from sources. For single module (non-aggregate projects) this seems fine. For multi-module (aggregator-pom) projects, I think this only builds the source-release for the aggregator project by itself, unless the maven Sorry for the bad English caused by cut/paste - should say unless the maven convention of ... is followed convention of having the directory layout have the aggregator pom in a directory which contains all the sub-projects. In our case, we have a flat hierarchy (actually, not exactly - we collect various parent-poms into one directory). My first attempt to alter our release -build process was to include in the maven-assembly-plugin descriptor a moduleSets section, to use the information in the aggregator modules element to locate and include all the subprojects. This kind of worked, but not quite, because it imposed a particular directory layout on the result, which didn't exactly match the SVN and working copy directory layout. (This was because I had put all of our parent-poms under one additional directory, just to keep things nicely organized ... ) After thinking more about this, it seems that the source-release.zip package should include just exactly what is in the SVN, starting with a directory there which is common among all the parts (the aggregating pom, and all of the projects being aggregated), but filtered to exclude all those things not in the set of artifacts being released. For example, in this layout (SVN and working copy): some-top-lvl-common-dir | +- aggregate-project | | | +- aggregate-pom.xml +- parent-poms | | | +- parent1-project | | | | | +- parent1.xml | +- parent2-project | | | | | +- parent2.xml +- some-non-released-thing the some-non-released-thing would be filtered, since it wasn't a module or the aggregate project. Does this sound like the right way to package source-releases for arbitrary layout SVN multi-module Apache projects? If so, is there a plugin which does this? (In this note, filtering just means including or excluding subtrees of files, not running the maven filtering software). I think the release plugin put in already the code to discover a common parent directory, as described above. (I don't think it has filtering code though). And the release process is already checking out into the target/checkout directory the SVN directory - so before it does any changes beyond the fresh checkout, could it build the source-release.zip from the (filtered) version of what's there? -Marshall -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Building a tar and zip of jars from other projects
On 6/28/2010 4:12 PM, Ron Wheeler wrote:
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we
build that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar
and a zip built?
There are two ways to configure the assembly plugin - one uses
predefined descriptors, the other lets you specify specific
instructions in a descriptor of your own that you point to - use the
parameter descriptors instead of descriptorRefs.
Then write your own assembly descriptor. See
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html for
instructions on how to do this. You'll see an element formats where
you can specify the tar and zip formats.
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as
individual classes?
In the custom assembly descriptor you make, you can control this using
the unpack option, see the details in the above documentation.
For a book chapter on how to do all kinds of things with assemblies, see:
http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
-Marshall Schor
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar
of jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
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
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Building a tar and zip of jars from other projects
On 6/28/2010 6:39 PM, Ron Wheeler wrote:
Thanks for the quick reply. See below.
On 28/06/2010 4:37 PM, Marshall Schor wrote:
On 6/28/2010 4:12 PM, Ron Wheeler wrote:
I am trying to build a pom in its own project that will assemble a tar
file and a zip file that will contain all of the jar files that we
build that need to go into the tomcat/lib directory.
I am missing 2 things.
1) What do I say to tell the maven-assembly-plugin that I want a tar
and a zip built?
There are two ways to configure the assembly plugin - one uses
predefined descriptors, the other lets you specify specific
instructions in a descriptor of your own that you point to - use the
parameterdescriptors instead ofdescriptorRefs.
Where are the predefined descriptors documented?
See
http://www.sonatype.com/books/mvnref-book/reference/assemblies-sect-basics.html#assemblies-sect-predefined
Also see
http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html
Then write your own assembly descriptor.
Do I need to write my own?
Yes, I think so.
See
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html for
instructions on how to do this. You'll see an elementformats where
you can specify the tar and zip formats.
2) How to I tell the maven-assembly-plugin that I want the jar files
zipped up without the contents being extracted and zipped as
individual classes?
In the custom assembly descriptor you make, you can control this using
theunpack option, see the details in the above documentation.
For a book chapter on how to do all kinds of things with assemblies,
see:
http://www.sonatype.com/books/mvnref-book/reference/assemblies.html
Unpack seems to be too late. Once you merge the jars, I don't see how
you can reconstruct the jars during the unpack.
Sorry, I meant to suggest you use the unpackfalse/unpack setting, to
prevent the Jars from being unpacked. According to the documentation,
this is the default - so maybe it will do just what you want by default :-)
-Marshall Schor
Ron
-Marshall Schor
I have built a test pom shown below.
Since it has
descriptorRef
jar-with-dependencies
/descriptorRef
it restructures the internal jar contents rather than creating a tar
of jar files.
I did find a nice article from Sonatype but these questions remain.
Ron
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
parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-master/artifactId
version1.8.3-SNAPSHOT/version
/parent
groupIdcom.artifact_software.lms/groupId
artifactIdlms-deployment-jars/artifactId
version1.8.3-SNAPSHOT/version
packagingpom/packaging
descriptionArtifact LMS Portal Shared Library Archive
builder./description
namelms-deploymentjars/name
properties
project.build.sourceEncodingUTF-8/project.build.sourceEncoding
/properties
dependencies
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-spring-hibernate-mysql-tomcat/artifactId
version${lms-project.version}/version
typepom/type
/dependency
dependency
groupIdcom.artifact_software.lms/groupId
artifactIdlms-pom-jsf/artifactId
version${lms-project.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-2/version
executions
execution
idcreate-jar-deployment-archive/id
phasepackage/phase
goals
goalsingle/goal
/goals
configuration
descriptorRefs
descriptorRef
jar-with-dependencies
/descriptorRef
/descriptorRefs
/configuration
/execution
/executions
/plugin
/plugins
/build
/project
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to Check If some file exists or not in resource folder
On 6/24/2010 2:29 PM, Umer Khan wrote: Hey, Is there any possible way to check if the file exist or not, thorough maven script, Yes, have a look at http://maven.apache.org/enforcer/enforcer-rules/requireFilesExist.html Actualy when packaging my project, I need some files to be in jar, so I just want to make sure if files are present or not, and then show appropriate message, this file doesn't exist. Regards, Umer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Package Speed
It may also help to speed things up to install a local NEXUS repository and use it as a mirror, if the slowness is due to accessing things over the internet. -Marshall On 6/24/2010 4:43 PM, Shan Syed wrote: this has to do with what's in your WAR, perhaps analyze what dependencies its using, and where they are coming from Maven is just like any other program; you can throw hardware at it to speed it up On Thu, Jun 24, 2010 at 4:41 PM, Rajasekar Karthik karthik...@gmail.comwrote: Hi, How can Maven's package of war be speed up? Currently, it is extremely slow - around 7 minutes or more. I even set the following options -DMAVEN_OPTS=-Xms64m –Xmx512m (higher Xmx to see if it will increase speed - but, it does not) Other options being set and command (invoked through NetBeans) mvn.bat -Dnetbeans.deploy=true -Dnetbeans.execution=true -DMAVEN_OPTS=-Xms64m –Xmx512m package -- Best Regards, Rajasekar Karthik karthik...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
using Release plugin version 2.0 doing flat hierarchy release - problem
I'm trying to do our first release using version 2.0 of the maven release plugin for a multi-module project at Apache, with a flat hierarchy. After failing because the Apache common pom was specifying version 2.0-beta-9 of the release plugin (which didn't have the flat hierarchy support), and redoing our top-level project pom to specify release 2.0, I did the release-prepare on this structure: SVN: build/trunk/aggregate-parent-poms build/trunk/parent-pom-1 build/trunk/parent-pom-2 etc. where the aggregate-parent-poms project is one which uses modulesmodule../parent-pom-1/module... etc. to aggregate the other projects. WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms build-trunk-data/parent-pom-1 build-trunk-data/parent-pom-2 etc. mvn release:prepare worked, but it generated in SVN the structure: build/tags/aggregate-parent-poms-1/trunk/aggregate-parent-poms build/tags/aggregate-parent-poms-1/trunk/parent-pom-1 build/tags/aggregate-parent-poms-1/trunk/parent-pom-2 etc. In reading the first comment for the flat-hierarchy support Jira issue http://jira.codehaus.org/browse/MRELEASE-261 I noticed it says the fix was to determine the directory in the maven module hierarchy which is the common owning directory for all the projects with the hierarchy. In this case, in the SVN hierarchy, it is trunk. So I'm not sure if the SVN structure, with the extra trunk directory is intentional or not. However, running, subsequently, the mvn release:perform goal, checked out the SVN tag in to the aggregate-parent-poms/target/checkout with the trunk directory included: WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms/target/checkout/trunk/aggregate-parent-poms build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-1 build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-2 etc. The next step, building the checked-out projects, failed, because it didn't use that extra trunk directory, but instead tried to build the aggregate from target/checkout/aggregate-parent-poms. The failure says: build-trunk-data\aggregate-parent-poms\target\checkout\aggregate-parent-poms does not exist! which is, of course, true, because there's that extra trunk directory in the path as checked out. So the build step apparently doesn't expect the extra trunk directory. A side note: each project has its own scm elements specifying where in SVN it resides; these were correctly updated by the release:prepare. This approach (having each project define its own scm elements) seems to be required by flat hierarchy projects. Is this a known issue, and if so, is there a work-around? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release - problem
forgot to add: I'm using maven version 3.0-beta-1 -Marshall On 6/23/2010 10:31 AM, Marshall Schor wrote: I'm trying to do our first release using version 2.0 of the maven release plugin for a multi-module project at Apache, with a flat hierarchy. After failing because the Apache common pom was specifying version 2.0-beta-9 of the release plugin (which didn't have the flat hierarchy support), and redoing our top-level project pom to specify release 2.0, I did the release-prepare on this structure: SVN: build/trunk/aggregate-parent-poms build/trunk/parent-pom-1 build/trunk/parent-pom-2 etc. where the aggregate-parent-poms project is one which uses modulesmodule../parent-pom-1/module... etc. to aggregate the other projects. WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms build-trunk-data/parent-pom-1 build-trunk-data/parent-pom-2 etc. mvn release:prepare worked, but it generated in SVN the structure: build/tags/aggregate-parent-poms-1/trunk/aggregate-parent-poms build/tags/aggregate-parent-poms-1/trunk/parent-pom-1 build/tags/aggregate-parent-poms-1/trunk/parent-pom-2 etc. In reading the first comment for the flat-hierarchy support Jira issue http://jira.codehaus.org/browse/MRELEASE-261 I noticed it says the fix was to determine the directory in the maven module hierarchy which is the common owning directory for all the projects with the hierarchy. In this case, in the SVN hierarchy, it is trunk. So I'm not sure if the SVN structure, with the extra trunk directory is intentional or not. However, running, subsequently, the mvn release:perform goal, checked out the SVN tag in to the aggregate-parent-poms/target/checkout with the trunk directory included: WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms/target/checkout/trunk/aggregate-parent-poms build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-1 build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-2 etc. The next step, building the checked-out projects, failed, because it didn't use that extra trunk directory, but instead tried to build the aggregate from target/checkout/aggregate-parent-poms. The failure says: build-trunk-data\aggregate-parent-poms\target\checkout\aggregate-parent-poms does not exist! which is, of course, true, because there's that extra trunk directory in the path as checked out. So the build step apparently doesn't expect the extra trunk directory. A side note: each project has its own scm elements specifying where in SVN it resides; these were correctly updated by the release:prepare. This approach (having each project define its own scm elements) seems to be required by flat hierarchy projects. Is this a known issue, and if so, is there a work-around? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release - problem
I looked at the poms in the SVN Tag, and they were re-written as expected by the release-prepare, but without the extra trunk directory. For example: scm connection scm:svn:http://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /connection developerConnection scm:svn:https://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /developerConnection url http://svn.apache.org/viewvc/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /url /scm So it looks like that part worked consistently with how the release:perform expected (with no extra trunk directory. -Marshall On 6/23/2010 10:36 AM, Marshall Schor wrote: forgot to add: I'm using maven version 3.0-beta-1 -Marshall On 6/23/2010 10:31 AM, Marshall Schor wrote: I'm trying to do our first release using version 2.0 of the maven release plugin for a multi-module project at Apache, with a flat hierarchy. After failing because the Apache common pom was specifying version 2.0-beta-9 of the release plugin (which didn't have the flat hierarchy support), and redoing our top-level project pom to specify release 2.0, I did the release-prepare on this structure: SVN: build/trunk/aggregate-parent-poms build/trunk/parent-pom-1 build/trunk/parent-pom-2 etc. where the aggregate-parent-poms project is one which uses modulesmodule../parent-pom-1/module... etc. to aggregate the other projects. WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms build-trunk-data/parent-pom-1 build-trunk-data/parent-pom-2 etc. mvn release:prepare worked, but it generated in SVN the structure: build/tags/aggregate-parent-poms-1/trunk/aggregate-parent-poms build/tags/aggregate-parent-poms-1/trunk/parent-pom-1 build/tags/aggregate-parent-poms-1/trunk/parent-pom-2 etc. In reading the first comment for the flat-hierarchy support Jira issue http://jira.codehaus.org/browse/MRELEASE-261 I noticed it says the fix was to determine the directory in the maven module hierarchy which is the common owning directory for all the projects with the hierarchy. In this case, in the SVN hierarchy, it is trunk. So I'm not sure if the SVN structure, with the extra trunk directory is intentional or not. However, running, subsequently, the mvn release:perform goal, checked out the SVN tag in to the aggregate-parent-poms/target/checkout with the trunk directory included: WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms/target/checkout/trunk/aggregate-parent-poms build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-1 build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-2 etc. The next step, building the checked-out projects, failed, because it didn't use that extra trunk directory, but instead tried to build the aggregate from target/checkout/aggregate-parent-poms. The failure says: build-trunk-data\aggregate-parent-poms\target\checkout\aggregate-parent-poms does not exist! which is, of course, true, because there's that extra trunk directory in the path as checked out. So the build step apparently doesn't expect the extra trunk directory. A side note: each project has its own scm elements specifying where in SVN it resides; these were correctly updated by the release:prepare. This approach (having each project define its own scm elements) seems to be required by flat hierarchy projects. Is this a known issue, and if so, is there a work-around? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: using Release plugin version 2.0 doing flat hierarchy release - problem
Here's a wild guess as to what went wrong: I had previously tried doing release:prepare (using version 2.0-beta-9 of the release plugin which didn't have flat support). That had created the tag in SVN: .../build/tags/aggregate-parent-poms-1 When I now re-ran the release:prepare, it did a svn copy from .../trunk to /build/tags/aggregate-parent-poms-1 I'm guessing that IF the target directory doesn't exist, then it is created and the elements under trunk are copied there. But if the target directory already exists, then the trunk directory is copied underneath that target directory. So, to make this work correctly, I first have to remove the aggregate-parent-poms-1 directory from the build/tags, I think. Perhaps the release plugin could check and complain (fail) if the target directory for this (and maybe other steps) already exists? -Marshall On 6/23/2010 2:26 PM, Marshall Schor wrote: I looked at the poms in the SVN Tag, and they were re-written as expected by the release-prepare, but without the extra trunk directory. For example: scm connection scm:svn:http://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /connection developerConnection scm:svn:https://svn.apache.org/repos/asf/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /developerConnection url http://svn.apache.org/viewvc/uima/build/tags/aggregate-parent-poms-1/aggregate-parent-poms /url /scm So it looks like that part worked consistently with how the release:perform expected (with no extra trunk directory. -Marshall On 6/23/2010 10:36 AM, Marshall Schor wrote: forgot to add: I'm using maven version 3.0-beta-1 -Marshall On 6/23/2010 10:31 AM, Marshall Schor wrote: I'm trying to do our first release using version 2.0 of the maven release plugin for a multi-module project at Apache, with a flat hierarchy. After failing because the Apache common pom was specifying version 2.0-beta-9 of the release plugin (which didn't have the flat hierarchy support), and redoing our top-level project pom to specify release 2.0, I did the release-prepare on this structure: SVN: build/trunk/aggregate-parent-poms build/trunk/parent-pom-1 build/trunk/parent-pom-2 etc. where the aggregate-parent-poms project is one which uses modulesmodule../parent-pom-1/module... etc. to aggregate the other projects. WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms build-trunk-data/parent-pom-1 build-trunk-data/parent-pom-2 etc. mvn release:prepare worked, but it generated in SVN the structure: build/tags/aggregate-parent-poms-1/trunk/aggregate-parent-poms build/tags/aggregate-parent-poms-1/trunk/parent-pom-1 build/tags/aggregate-parent-poms-1/trunk/parent-pom-2 etc. In reading the first comment for the flat-hierarchy support Jira issue http://jira.codehaus.org/browse/MRELEASE-261 I noticed it says the fix was to determine the directory in the maven module hierarchy which is the common owning directory for all the projects with the hierarchy. In this case, in the SVN hierarchy, it is trunk. So I'm not sure if the SVN structure, with the extra trunk directory is intentional or not. However, running, subsequently, the mvn release:perform goal, checked out the SVN tag in to the aggregate-parent-poms/target/checkout with the trunk directory included: WORKING DIR where things are checked out: build-trunk-data/aggregate-parent-poms/target/checkout/trunk/aggregate-parent-poms build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-1 build-trunk-data/aggregate-parent-poms/target/checkout/trunk/parent-pom-2 etc. The next step, building the checked-out projects, failed, because it didn't use that extra trunk directory, but instead tried to build the aggregate from target/checkout/aggregate-parent-poms. The failure says: build-trunk-data\aggregate-parent-poms\target\checkout\aggregate-parent-poms does not exist! which is, of course, true, because there's that extra trunk directory in the path as checked out. So the build step apparently doesn't expect the extra trunk directory. A side note: each project has its own scm elements specifying where in SVN it resides; these were correctly updated by the release:prepare. This approach (having each project define its own scm elements) seems to be required by flat hierarchy projects. Is this a known issue, and if so, is there a work-around? -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
releasing a hierarchy of parent poms with the Release plugin
For a collection of parent poms, arranged in a hierarchy, e.g., A (is parent of) B (is parent of) C, all at version e.g. 1-SNAPSHOT when I put all of these into an aggregate project, specifying modules A, B, and C, the mvn release:prepare -DdryRun=true works fine, but the mvn release:prepare fails when it tries to resolve the parent of B and looks for a version 1 (without the SNAPSHOT), which obviously isn't in any repo (because it's one of the set being released). Is there a way to release all of these together, or do I have to have 3 individual release votes, waiting in each case for the 1 version to reach the central repo before commencing with the release:prepare of the the next lower one in the hierarchy? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: releasing a hierarchy of parent poms with the Release plugin
On 6/17/2010 3:17 PM, Anders Hammar wrote: Have you tried specifying the parent.relativePath element? Thanks, that appears to have done the trick! -Marshall /Anders On Thu, Jun 17, 2010 at 17:43, Marshall Schor m...@schor.com wrote: For a collection of parent poms, arranged in a hierarchy, e.g., A (is parent of) B (is parent of) C, all at version e.g. 1-SNAPSHOT when I put all of these into an aggregate project, specifying modules A, B, and C, the mvn release:prepare -DdryRun=true works fine, but the mvn release:prepare fails when it tries to resolve the parent of B and looks for a version 1 (without the SNAPSHOT), which obviously isn't in any repo (because it's one of the set being released). Is there a way to release all of these together, or do I have to have 3 individual release votes, waiting in each case for the 1 version to reach the central repo before commencing with the release:prepare of the the next lower one in the hierarchy? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where do I put non-java project common files?
On 6/15/2010 2:27 AM, oor wrote:
I have n projects:
project_super: Aggregates the projects project_subi. Just a pom-project.
project_sub1 : Inherits project_super
...
project_subi : Inherits project_super
...
roject_subn : Inherits project_super
1)
Most projects project_subi have an assembly descriptor sited in their
${basedir}\src\main\resources-build directories. They are identical. As n
gets big, these identical files will proliferate with the maintenance
overhead following. I guess this file could be stored/defined in
project_super and referred to by project_subi. How do I achieve this
conforming to best practices?
If you examine the common apache parent pom (
http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom ) it does
this for assembly descriptors. Basically, the idea is
1) to have a Jar project have the assembly descriptor in a particular
place
2) build / install / release that Jar project
3) refer to it in the assembly configuration as a built-in descriptor,
but also
4) tell the assembly to add that Jar to its classpath (so it can be
found), using a plugin dependency
2)
Moreover, most project_subi uses this assembly descriptor in an identical
way, i.e. using the maven-assembly-plugin. The plugin definitions are
identical. I.e. each project_subi pom contains exactly:
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-assembly-plugin/artifactId
version2.2-beta-4/version
executions
execution
idPackage installation archive.../id
phasepre-integration-test/phase
configuration
descriptors
descriptor${basedir}/src/main/resources-build/assembly.descriptor.installation.archive.xml/descriptor
/descriptors
finalName/finalName
outputDirectorytarget/outputDirectory
workDirectorytarget/workDirectory
/configuration
goals
goalassembly/goal
/goals
/execution
/executions
/plugin
...
Could this somehow be defined in project_super and be referred to (run) by
the relevant projects project_subi?
You could define a parent-pom having this as its
buildpluginsplugin ... , and then (since you say *most* projects
use this assembly, have those projects which do use it inherit from this
parent-pom, and those which do not use it, skip inheriting from this pom.
To avoid having the build of this parent-pom run the assembly, you can
put the buildpluginsplugin inside a profile, and activate that
profile by the absence of a file, and put a marker file in the
parent-pom (only).
HTH. -Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: create changes.txt while releasing
Hi, See if the http://maven.apache.org/plugins/maven-changelog-plugin/ does what you want. -Marshall Schor On 6/8/2010 5:34 AM, rgubler2 wrote: Hello, can maven create a changes file from svn log messages between releases? Yours Rüdiger - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependency on assembly?
On 5/20/2010 11:29 AM, C. Benson Manica wrote: Let's say I have a dependency that looks something like dependency groupIdcom.foo/groupId artifactIdbar/artifactId version1.0/version /dependency This artifact gets deployed with an additional assembly, baz.tar.gz, that I want to make use of in this project. Is baz.tar.gz accessible from this project? Yes, I think so. If so, how do I reference it? The name baz.tar.gz is probably more likely formatted like: artifactId - version - classifier . tar.gz where artifactId = bar and the version is 1.0. So the name would be more like: bar-1.0-baz.tar.gz You can write a dependency on this using groupIdcom.foo/groupId artifactIdbar/artifactId classifierbazclassifer typetar.gz/type Followup question, what I really want to do is extract baz.tar.gz to directory baz and arrange for baz to be included in an assembly to be built by this project - how would I arrange for that to happen? The assembly descriptor supports this directly, I think: use dependencySet and specify unpack. -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Preventing an inherited report from running
One technique I've had work in the normal build plugins, that probably would work in the reporting ones, is this: Let's say the Cobertura report you're inheriting (from some parent pom, I presume) is configured there with an execution idxyz/id (If it doesn't have this, then it is using some default id - you can find out what it is by running once with the -X parameter, I think) Then, configure your version of the plugin for Cobertura like: execution idxyz/id !-- must match the inherited one -- phase/ !-- override the phase to be no-phase - this keeps this from executing -- I haven't tried this myself, but if you do, I'd like to know if it succeeds in getting rid of this report :-) -Marshall Schor On 5/20/2010 4:38 PM, Timothy Mcginnis wrote: The skip helps. But there is one I'd like to get rid of, the Cobertura report. And it doesn't have a skip. Tim McGinnis 717 720-1962 Web Development AES/PHEAA From: Wendy Smoak wsm...@gmail.com To: Maven Users List users@maven.apache.org Date: 05/20/2010 04:33 PM Subject: Re: Preventing an inherited report from running On Thu, May 20, 2010 at 4:25 PM, Timothy Mcginnis tmcgi...@aessuccess.org wrote: I have a master pom that specifies the reports to be run. In one of the child projects I do not want to run one of those reports. How do I prevent it from running? In general you can't un-inherit things, but some plugins have a skip parameter that you can configure. If that doesn't help, let us know what report it is and how it's configured... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Setting environment variables in the exec plugin
Maybe you need to set the environmentVariables this way (see [1]):
environmentVariables
DYLD_LIBRARY_PATH
${project.build.directory}/thirdparty/vtk/lib/vtk-5.4/
/DYLD_LIBRARY_PATH
/environmentVariables
-Marshall Schor
[1]
http://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Maps
On 5/20/2010 9:48 AM, Thiébault Benoît wrote:
Hi everyone,
I'm trying to execute a Java program accessing native components, following
the very good blog post http://www.buildanddeploy.com/node/17
I however have a problem setting environment variables within the exec
plugin. Here is an extract of my POM :
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
version1.1/version
executions
execution
goals
goalexec/goal
/goals
/execution
/executions
configuration
environmentVariables
keyDYLD_LIBRARY_PATH/key
value${project.build.directory}/thirdparty/vtk/lib/vtk-5.4//value
/environmentVariables
executablejava/executable
arguments
argument-classpath/argument
classpath /
argument
com.artenum.vtk.maven.ConeDemo
/argument
/arguments
/configuration
/plugin
When I run it, I have a java.lang.UnsatisfiedLinkError.
If I do
export DYLD_LIBRARY_PATH=mypath
then it works...
Do you know what is wrong in my exec configuration ?
Thank you
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Which Jira to use for items concerning the Apache Common Parent POM?
Hi, I've posted earlier about a couple of possible improvements to the Apache Common Parent POM - used by Apache projects [1]. I'd like to add some Jira issues for these, but I was unable to determine what Jira system to use. Does anyone know the right Jira to use for this? -Marshall Schor [1]http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: How to create a report based on annotations
On 5/18/2010 3:17 AM, Lewis, Eric wrote: Anyone? :-) -Ursprüngliche Nachricht- Von: Lewis, Eric [mailto:eric.le...@ipi.ch] Gesendet: Montag, 17. Mai 2010 11:07 An: Maven Users List Betreff: How to create a report based on annotations Hi I'd like to create a Maven report based on annotations (OVal annotations, to be precise). Can I use the apt-maven-plugin for this (and if yes, how would I do it)? Also, is there a tutorial for more sophisticated site plugins? Like using CSS styles, default images etc. This chapter of the Maven complete reference describes these topics: http://www.sonatype.com/books/mvnref-book/reference/site-generation.html -Marshall Schor Best regards, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Deploying site updates to Apache websites
I'm investigating using Maven site-deploy to update parts of our site on Apache. Currently, we don't use maven site-deploy for this; instead we put the generated content (html, etc.) into svn, and then go to people.apache.org and checkout or svn update into a directory there /www/x.y.z/etc where x.y.z is the project's website address. I looked but did not see any documentation on how to configure the distributionManagement url element for this. The docs mention various transports (ftp, webdav, scp) but don't provide information on how to write the url. And, I don't know what protocol(s) people.apache.org supports for this. I know I can log in from a terminal, and scp works. But for instance, if I was using scp, I don't know what I would write in the url to get something uploaded to a point in /www/x.y.z/a/b/c. Would it be: scp://people.apache.org/www/x.y.z/a/b/c/ ? In other words, does the url part starting after the hostname get mapped to people's top directory? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Apache Common Parent Pom 7 - use of maven-source-plugin - why not use the no-fork version?
When doing an apache-release , the common Apache Parent version 7 invokes: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId executions execution idattach-sources/id goals goaljar/goal !-- == ITEM OF INTEREST -- /goals /execution /executions /plugin This causes re-running of the lifecycle up to the package goal, which is inefficient, I think. Is there a reason the goal jar-no-fork isn't used instead? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Apache Common Parent Pom 7 - use of maven-source-plugin - why not use the no-fork version?
ok - where do Jira's for updating the common Apache Parent go? The pom in question is missing an issueManagement element... ;-) -Marshall Schor On 5/17/2010 3:00 PM, Brian Fox wrote: When that was written the jar goal didn't fork iirc. On Mon, May 17, 2010 at 2:37 PM, Marshall Schor m...@schor.com wrote: When doing an apache-release , the common Apache Parent version 7 invokes: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId executions execution idattach-sources/id goals goaljar/goal !-- == ITEM OF INTEREST -- /goals /execution /executions /plugin This causes re-running of the lifecycle up to the package goal, which is inefficient, I think. Is there a reason the goal jar-no-fork isn't used instead? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Multi-module source release assembly, using Common Apache POM version 7 not using moduleSets?
The current common apache parent POM (version 7) [1], when you specify the apache-release profile, activates a part: plugins !-- Create a source-release artifact that contains the fully buildable project directory source structure. This is the artifact which is the official subject of any release vote. -- plugin artifactIdmaven-assembly-plugin/artifactId . . . executions execution idsource-release-assembly/id . . . configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot . . . /configuration When used on a multi-module aggregate project, this only creates the source-release-assembly at the aggregate project level. It seems to me, since this artifact is the official subject of any release vote, that this source assembly should include the sources from this aggregate project, plus all of the sub-modules . (Currently it only has the the source from this aggregate project; none of the submodules are included.) I think the assembly plugin attempts to support this use case, via its moduleSets elements. Are multi-module projects in Apache supposed to override the common Apache Parent and specify the moduleSets form of assembly? Or is there another preferred way to do this? -Marshall Schor [1] http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-module source release assembly, using Common Apache POM version 7 not using moduleSets?
Hi Brian,
I think the moduleSet support was upgraded in the more recent releases,
to support other than tree-structures. My projects are *not* in a
directory tree, but are instead, flat. The modules elements look
like module../submodule1/module.
I built the following and tested it and it seems to work nicely. First,
I created another assembly descriptor and saved it as a loadable
resource for the assembly plugin to reference. This descriptor is
designed to work for either multi-module assemblies, or just single
projects (no modules):
assembly
idsource-release/id !-- match the previous one, becomes
classifier --
formats
formatzip/format
/formats
moduleSets
moduleSet
sources
outputDirectory//outputDirectory
useDefaultExcludestrue/useDefaultExcludes
excludes
!-- here, I copied all those hairy regex things from the
Apache Common Parent version --
...
/excludes
/sources
/moduleSet
/moduleSets
fileSets
!-- this gets the aggregate artifact source, or if no modules,
the main source, as before --
fileSet
directory./directory
outputDirectory/${project.artifactId}/outputDirectory
useDefaultExcludestrue/useDefaultExcludes
excludes
!-- here, I (once again) copied all those hairy regex things
from the Apache Common Parent version --
...
/excludes
/fileSet
!-- license, readme, etc. calculated at build time --
fileSet
directory${project.build.directory}/maven-shared-archive-resources/META-INF/directory
outputDirectory//outputDirectory
/fileSet
/fileSets
/assembly
Having that, I then overrode the Apache Common Parent POM build action
when apache-release is specified as a profile:
properties
sourceReleaseAssemblyDescriptormultimodule-source-release/sourceReleaseAssemblyDescriptor
/properties
plugin
artifactIdmaven-assembly-plugin/artifactId
dependencies
dependency !-- here I stuck in the dependency on the above
saved asm descriptor --
groupIdorg.apache.uima/groupId
artifactIduima-jar-resource-bundle/artifactId
version1-SNAPSHOT/version
/dependency
/dependencies
/plugin
This seems to work (at least for my project). I think it should be
considered for the common Apache Parent pom. Should I open a Jira for
this, and if so, what Jira system is being used for the Apache Parent poms?
-Marshall Schor
On 5/17/2010 5:13 PM, Brian E. Fox wrote:
This descriptor assumes that all modules ate children of the execution
root...or a tree. If that's not the case in your project then you
would need to create a custom bundle descriptor.
--Brian (mobile)
On May 17, 2010, at 3:20 PM, Marshall Schor m...@schor.com wrote:
The current common apache parent POM (version 7) [1], when you specify
the apache-release profile, activates a part:
plugins
!--
Create a source-release artifact that contains the fully buildable
project directory source structure. This is the artifact
which is
the official subject of any release vote.
--
plugin
artifactIdmaven-assembly-plugin/artifactId
. . .
executions
execution
idsource-release-assembly/id
. . .
configuration
runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot
. . .
/configuration
When used on a multi-module aggregate project, this only creates the
source-release-assembly at the aggregate project level. It seems to me,
since this artifact is the official subject of any release vote, that
this source assembly should include the sources from this aggregate
project, plus all of the sub-modules . (Currently it only has
the the source from this aggregate project; none of the submodules are
included.)
I think the assembly plugin attempts to support this use case, via its
moduleSets elements. Are multi-module projects in Apache supposed
to override the common Apache Parent and specify the moduleSets form
of assembly?
Or is there another preferred way to do this?
-Marshall Schor
[1] http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding application generated content to site
On 5/15/2010 10:59 AM, Rob Greene wrote: I have an application that has the ability to generate some documentation I would like to include in the Maven generated site. Is there some manner to do this? Sure. I imagine I would need to invoke my Java to generate the content Right. You could write a maven plugin (it's not really very hard to do) that runs your Java code to generate the content. Or you could use the antrun plugin for this, assuming you know how to have ant invoke your Java. Or, you could use the enforcer plugin (!) because it has one rule called evaluateBeanshell, which you can use to run arbitrary beanshell code (which I think could call your Java). Or you could use the gmaven plugin to run an arbitrary groovy script which could call your Java. You get the idea ... Any of these methods can be configured in the POM to run at a particular phase of the maven build cycle(s). as well as dynamically add links into the menu structure. I'm not sure what the best way to do this is... Since you would be configuring this project to have the maven generated docs plus the ones you generate, it seems that you would be able to un-dynamically add links into the menu structure ahead of time. Or, if the need for dynamic links comes from the Java-generated docs generating lots of alternatives over time, you could have a main static link on the site point to a page generated by your Java which has the dynamically altered information and links. HTH. -Marshall Schor Thanks! -Rob - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: getting multiple forms of the build date
On 4/28/2010 11:53 AM, Marshall Schor wrote: There's a new way to get the build date, documented here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html - search for maven.build.timestamp. This is nice. I would like to have multiple versions of this. For instance, the whole date/time spec for including in Jar Manifests, and just the month and year for substituting in to documentation publication date. Is there a way to get multiple, different formats for this? I couldn't find one. I found one ref that used a groovy script with the gmaven plugin to do this, and it worked, but was slow, because it has to load up groovy. So, I wrote my first maven plugin. It takes a series of specs which are the simple date and time patterns strings described in the Java class SimpleDateFormat API, and sets the value(s) into property names that are also passed in as part of the configuration. Works like a charm, and is very fast. -Marshall -Marshall - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problems with mvn protocol handler in maven 3 beta 1
One more idea to try: Each plugin element in build can define its own additional things to put on the classpath, by including dependenciesdependency elements. See http://maven.apache.org/ref/2.2.1/maven-model/maven.html#class_plugin - the dependency element is defined as Additional dependencies that this project needs to introduce to the plugin's classloader. So, for the felix features-maven-plugin, inside the plugin element for it, try adding a dependency on the artifact(s) that implement the mvn: protocol. If you try this (adding pax-url-mvn version 1.1.2) and it doesn't work, check 2 more things: Run maven with the -X param ( mvn -X ) and look at the debug info to see what classpath was set up for the features-maven-plugin, and insure it has the pax-url-mvn artifact. And, also, check that the pax-url-mvn artifact does indeed provide the mvn: protocol implementation. HTH. -Marshall On 5/9/2010 8:42 AM, Bengt Rodehav wrote: Thanks for you reply Marshal, I've tried to add the artifacts pax-url-mvn and pax-url-commons as extensions as follows: build extensions extension groupIdorg.ops4j.pax.url/groupId artifactIdpax-url-mvn/artifactId version1.1.2/version /extension extension groupIdorg.ops4j.pax.url/groupId artifactIdpax-url-commons/artifactId version1.1.2/version /extension /extensions ... I also added extensionstrue/extensions to the configuration of the features-maven-plugin. However, there is no difference. I still get unknown protocol: null I also note that I was wrong in my previous post. The features-maven-plugin does not work under the 3.0-alpha-7 either. Seems like the problem has to do with maven 3, and possibly the class loading changes that you mentioned. Just can't get it to work though. Any more ideas? /Bengt 2010/5/8 Marshall Schor m...@schor.com: On 5/8/2010 2:55 AM, Bengt Rodehav wrote: No one has any ideas? Here's an idea - Maven 3 has been doing more class loader isolation stuff. Perhaps an extensions element is needed? See https://cwiki.apache.org/MAVEN/maven-3x-class-loading.html -Marshall I'm thinking along the lines that something that wasn't bundled with maven alpha is now bundled with maven beta. Something that takes precedence over what's need for customised url handlers to work. Does anyone know if something has changed in that respect from the alpha to the beta version that could break url handlers. /Bengt 2010/5/7 Bengt Rodehav be...@rodehav.com: I'm using the features-maven-plugin included in Apache Felix. It in turn uses pax-url-mvn (version 1.1.2) to enable the protocol mvn:. This works fine in maven 2.2.1 and also in maven 3.0-alpha-7. However, with everything else the same, it fails under maven 3.0-beta-1. I get java.net.MalformedURLException: unknown protocol: null This happens in a call to uri.toURL() where the uri is created from the string: mvn:org.apache.felix.karaf/apache-felix-karaf/1.4.0/xml/features It seems that the combination of pax-url-mvn and and maven 3.0-beta-1 does not work. Has anyone got any ideas as to what is wrong and possibly a workaround? /Bengt - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problems with mvn protocol handler in maven 3 beta 1
On 5/8/2010 2:55 AM, Bengt Rodehav wrote: No one has any ideas? Here's an idea - Maven 3 has been doing more class loader isolation stuff. Perhaps an extensions element is needed? See https://cwiki.apache.org/MAVEN/maven-3x-class-loading.html -Marshall I'm thinking along the lines that something that wasn't bundled with maven alpha is now bundled with maven beta. Something that takes precedence over what's need for customised url handlers to work. Does anyone know if something has changed in that respect from the alpha to the beta version that could break url handlers. /Bengt 2010/5/7 Bengt Rodehav be...@rodehav.com: I'm using the features-maven-plugin included in Apache Felix. It in turn uses pax-url-mvn (version 1.1.2) to enable the protocol mvn:. This works fine in maven 2.2.1 and also in maven 3.0-alpha-7. However, with everything else the same, it fails under maven 3.0-beta-1. I get java.net.MalformedURLException: unknown protocol: null This happens in a call to uri.toURL() where the uri is created from the string: mvn:org.apache.felix.karaf/apache-felix-karaf/1.4.0/xml/features It seems that the combination of pax-url-mvn and and maven 3.0-beta-1 does not work. Has anyone got any ideas as to what is wrong and possibly a workaround? /Bengt - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:unpack handling of overwrite for individual items in the archive
On 5/1/2010 7:29 AM, Marshall Schor wrote:
Thanks, that saves me from doing another learning experiment :-)
I had occasion to check this while doing something else, and I found
that it doesn't just unpack the whole archive.
While doing the unpack, it iterates over each item in the archive, and
runs this code in the class AbstractZipUnArchiver:
protected void extractFile( File srcF,
File dir,
InputStream compressedInputStream,
String entryName,
Date entryDate,
boolean isDirectory, Integer mode )
throws IOException, ArchiverException
{
File f = FileUtils.resolveFile( dir, entryName );
try
{
if ( !isOverwrite() f.exists() ( f.lastModified() =
entryDate.getTime() ) )
{
return;
This code checks *for each item in the zip* if the existing file's
lastModified date is = the zip entry's, and if so, it skips unzipping.
And this is the behavior that I am seeing. The version of this plexus
Archiver code appears to be:
AbstractZipUnArchiver.java 6650 2007-07-18 01:08:45Z jdcasey (My IDE
(Eclipse) fetched it automagically...)
This contradicts the response I had above, so please let me know if I'm
missing something here...
-Marshall
I think a workaround will be to run the antrun plugin - unzip action to
do the unpacking, which is documented [1] to support a
replace-only-if-newer action on the individual parts as the default, and
also to pay attention to timezone issues in timestamps.
-Marshall
[1] http://ant.apache.org/manual/CoreTasks/unzip.html
On 4/30/2010 10:55 PM, Brian Fox wrote:
Currently it just unpacks the whole archive.
On Thu, Apr 29, 2010 at 10:31 AM, Marshall Schor m...@schor.com wrote:
The documentation for dependency:unpack [1] says that the default is to
overwrite (only) if newer. But it seems to apply to the entire archive
being unpacked, meaning that the check is on whether the archive file
itself is newer or not, using what the plugin calls marker files,
and perhaps not on whether the individual archived items are newer or
not (is that right?).
Is it possible to specify overwrite-if-newer such that it applies to the
timestamps on the individual zipped items in the source (I'm using zip
as the archive format)? Or is this the default behavior (for example,
the Ant task for unZip [2] appears to have this property by default).
-Marshall
[1]
http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules
[2] http://ant.apache.org/manual/CoreTasks/unzip.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: feature request: more verbose error messages
One thing you could do is to follow what this line says:
[INFO] For more information, run Maven with the -e switch
Another thing is you could run with the -X switch which will generate lots of
output, probably enough for you to see what's going wrong.
-Marshall Schor
On 5/7/2010 12:27 PM, Roger Pack wrote:
Currently this occurs:
$ mvn exec:java
-Dexec.mainClass=org.familysearch.digitalarchive.IdisStatusWatcher
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'exec'.
[INFO]
[INFO] Building monitors
[INFO]task-segment: [exec:java]
[INFO]
[INFO] Preparing exec:java
[INFO] No goals needed for project - skipping
[INFO] [exec:java {execution: default-cli}]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An exception occured while executing the Java class.
org.familysearch.digitalarchive.IdisStatusWatcher
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Fri May 07 10:26:01 MDT 2010
[INFO] Final Memory: 8M/123M
[INFO]
This doesn't give me much information as to what Exception occurred
while executing that class.
Feature request:
when it fails, output more information than normal. In this case it
was that that particular class didn't exist--but you can't tell that
from the error output.
Thanks so much!
-rp
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
avoiding kludge when factoring common build steps into parent pom
I have a bunch of project that execute some common build steps. I factored these out into a parent-pom, and change the projects to specify this as their parent. My parent-pom is of package-type pom. The problem I'm having is that the factored-out build steps run when I do mvn install on the parent-pom to get it into my local repo. These steps don't work and throw errors, when run here. So I fixed this with a kludge - and I'm hoping to learn a better way. My kludge: I moved the build steps into a profile, and activated the profile on the absence of a file, named something like marker-file-identifying-parent-pom-XXX. And then, I put a dummy file of that name into the parent project. This keeps the pom from running the build steps in the parent, but makes those steps available to the children. Is there a better way? -Marshall Schor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: avoiding kludge when factoring common build steps into parent pom
On 5/7/2010 2:52 PM, Wayne Fay wrote: The problem I'm having is that the factored-out build steps run when I do mvn install on the parent-pom to get it into my local repo. These steps don't work and throw errors, when run here. Put the common stuff in depMgmt in the parent, and only declare the plugins in the build section where you want to use them (not parent). They will inherit their parameters etc from depMgmt in the parent. The common stuff is build plugin things, not dependencies. I don't think you can put those into depMgmt. I could put them into pluginManagement, but then all of the projects would have to call-out all of the executions of the various things, which was one of the things I was trying to factor out. Did I misunderstand your suggestion? -Marshall Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached files not getting unique identifier when deployed
Well, I was able to reproduce your problem, and then found a work-around for it... Here's the work-around: Change your POM from: plugin artifactIdmaven-jar-plugin/artifactId version2.2/version configuration classifierconfig/classifier /configuration /plugin to plugin artifactIdmaven-jar-plugin/artifactId version2.2/version executions execution iddefault-jar/id !-- special name for normal jar build -- goalsgoaljar/goal/goals configuration classifierconfig/classifier /configuration /execution /executions /plugin If you don't put in the id.../id with that name, you get 2 jars built - one by default without the classifier, plus the classifier. I don't know why this works, and the other one doesn't work. Maybe someone else can say... -Marshall On 5/4/2010 8:30 AM, Michael Delaney wrote: Sure. Please see the attached pom file. I do have a parent defined but it's there just to define release profiles as well as version information. No additional configuration (for the maven-jar-plugin) is in the parent pom. On 5/3/2010 7:53 PM, Marshall Schor wrote: it looks like your jar file has no classifier. A plain jar file is being uploaded. Can you post the part of the POM where you are defining the classifier artifact, and attaching it? -Marshall On 5/3/2010 7:09 PM, Michael Delaney wrote: All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached files not getting unique identifier when deployed
On 5/4/2010 3:31 PM, Michael Delaney wrote: I tried this and the deployed jars still lacks the unique time stamp identifier. Sorry, I guessed wrong. To fix, change the name in the id to something other than default-jar, such as my very own jar. Then it works (it did for me), except, that you'll get an extra artifact, the main one, which is a jar without a classifier. (To get rid of this extra jar, you could change the packaging type from jar to pom. This says that the main output of the project is the POM artifact, and the rest of the outputs are attachments to that.) Maven always wants to have 1 main artifact per project; the rest of the things are called attachments. The exception is the POM, which is always carried along, and isn't normally considered the main output artifact (except for packaging type=pom). See http://www.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/ for a discussion of this. -Marshall On 5/4/2010 2:39 PM, Marshall Schor wrote: Well, I was able to reproduce your problem, and then found a work-around for it... Here's the work-around: Change your POM from: plugin artifactIdmaven-jar-plugin/artifactId version2.2/version configuration classifierconfig/classifier /configuration /plugin to plugin artifactIdmaven-jar-plugin/artifactId version2.2/version executions execution iddefault-jar/id !-- special name for normal jar build -- goalsgoaljar/goal/goals configuration classifierconfig/classifier /configuration /execution /executions /plugin If you don't put in theid.../id with that name, you get 2 jars built - one by default without the classifier, plus the classifier. I don't know why this works, and the other one doesn't work. Maybe someone else can say... -Marshall On 5/4/2010 8:30 AM, Michael Delaney wrote: Sure. Please see the attached pom file. I do have a parent defined but it's there just to define release profiles as well as version information. No additional configuration (for the maven-jar-plugin) is in the parent pom. On 5/3/2010 7:53 PM, Marshall Schor wrote: it looks like your jar file has no classifier. A plain jar file is being uploaded. Can you post the part of the POM where you are defining the classifier artifact, and attaching it? -Marshall On 5/3/2010 7:09 PM, Michael Delaney wrote: All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May
Re: project version as a property?
What I've surmised from the various sources of maven thinking, is that
1) The parent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent the groupId
3) The child project should also define its version explicitly
The release plugin expects this and has code to adjust these values
inside the pom, as the release happens. They go from x.y.z-SNAPSHOT to
x.y.z (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).
The point of all that is that the tooling tries to take care of
mass-updating these fixed version numbers. This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
propagated to the other poms).
-Marshall Schor
On 5/3/2010 12:37 PM, Frank Maritato wrote:
Hi,
I have a multi module project and in my top level pom I am using a
property to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all define version the
same way. Within the context of this project it all works and
everything is cool. The problem I have is when I try to import one of
these libraries into another project I get an error that it can't
resolve the parent of my dependency because it isn't resolving that
property value.
When I look in my .m2/repository directory at the pom for that project
it still has the unresolved ${myproject.version} string in there. I
have tried defining that property in the other project that is
importing that dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
--
Frank Maritato
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: project version as a property?
On 5/3/2010 4:05 PM, Ron Wheeler wrote:
Does this imply a rule 4) The parent should define properties for all
of the dependency versions for the shared libraries that the children
need?
Things go in parents when you can see you are repeating yourself in the
children; moving those items to parents generally improves the
maintainability. But if a child is the only thing using a dependency,
moving it to a parent makes the child less easy to read and understand
(because, of course, you have to go and read the parent too).
Does this go in dependency management or simply as a set of
properties that are passed on to the children?
The POMs are clearer when you put these in dependencyManagement, I think.
-Marshall
Ron
On 03/05/2010 2:44 PM, Marshall Schor wrote:
What I've surmised from the various sources of maven thinking, is that
1) Theparent element should identify the parent using explicit (no
properties) values
2) The child project can then inherit from the parent thegroupId
3) The child project should also define its version explicitly
The release plugin expects this and has code to adjust these values
inside the pom, as the release happens. They go from x.y.z-SNAPSHOT to
x.y.z (without the snapshot), to x.y.(z+1)-SNAPSHOT for the next
release snapshot (the last one is changeable, to correspond to your
release numbering - see the documentation for the release plugin).
The point of all that is that the tooling tries to take care of
mass-updating these fixed version numbers. This might reduce the
motivation of using substitutable property names (that is, if the
motivation was to have one spot to update, and have that update
propagated to the other poms).
-Marshall Schor
On 5/3/2010 12:37 PM, Frank Maritato wrote:
Hi,
I have a multi module project and in my top level pom I am using a
property to define the version number like this:
version${myproject.version}/version
properties
myproject.version0.1/myproject.version
/properties
All my submodules inherit from this pom and all defineversion the
same way. Within the context of this project it all works and
everything is cool. The problem I have is when I try to import one of
these libraries into another project I get an error that it can't
resolve the parent of my dependency because it isn't resolving that
property value.
When I look in my .m2/repository directory at the pom for that project
it still has the unresolved ${myproject.version} string in there. I
have tried defining that property in the other project that is
importing that dependency but it still doesn't work.
Is this not the way we should define our project? Should we just use
explicit version numbers in our pom's?
--
Frank Maritato
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Attached files not getting unique identifier when deployed
it looks like your jar file has no classifier. A plain jar file is being uploaded. Can you post the part of the POM where you are defining the classifier artifact, and attaching it? -Marshall On 5/3/2010 7:09 PM, Michael Delaney wrote: All, I have a simple maven project that generates a jar file; with the classifier 'config'. When I call the 'deploy' phase, the pom file is uploaded with unique identifier (as expected) but the jar file is not (see examples below); the maven metadata is updated with the timestamp as well. When I put a dependency on the jar file, Maven can not resolve the artifact because it's looking for the jar file with the timestamp (as denoted by the maven-metadata file). Has anyone else seen this issue? I'm using Maven 2.2.1 on Solaris. [Example] -rw-r--r-- 1 archiva archiva 382 May 3 18:47 maven-metadata.xml -rw-r--r-- 1 archiva archiva 52 May 3 18:47 maven-metadata.xml.md5 -rw-r--r-- 1 archiva archiva 60 May 3 18:47 maven-metadata.xml.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224504-1.pom.sha1 -rw-r--r-- 1 archiva archiva 1106 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-20100503.224537-2.pom.sha1 -rw-r--r-- 1 archiva archiva 4080 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.jar.sha1 -rw-r--r-- 1 archiva archiva 757 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom -rw-r--r-- 1 archiva archiva 32 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:47 myApplication-1.0.0-20100503.224708-3.pom.sha1 -rw-r--r-- 1 archiva archiva 4157 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar -rw-r--r-- 1 archiva archiva 32 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.md5 -rw-r--r-- 1 archiva archiva 40 May 3 18:45 myApplication-1.0.0-SNAPSHOT-config.jar.sha1 [maven-metadata.xml] ?xml version=1.0 encoding=UTF-8? metadata groupIdcom.mycompany/groupId artifactIdmyApplication/artifactId version1.0.0-SNAPSHOT/version versioning snapshot buildNumber3/buildNumber timestamp20100503.224708/timestamp /snapshot lastUpdated20100503224708/lastUpdated /versioning /metadata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency:unpack handling of overwrite for individual items in the archive
Thanks, that saves me from doing another learning experiment :-) I think a workaround will be to run the antrun plugin - unzip action to do the unpacking, which is documented [1] to support a replace-only-if-newer action on the individual parts as the default, and also to pay attention to timezone issues in timestamps. -Marshall [1] http://ant.apache.org/manual/CoreTasks/unzip.html On 4/30/2010 10:55 PM, Brian Fox wrote: Currently it just unpacks the whole archive. On Thu, Apr 29, 2010 at 10:31 AM, Marshall Schor m...@schor.com wrote: The documentation for dependency:unpack [1] says that the default is to overwrite (only) if newer. But it seems to apply to the entire archive being unpacked, meaning that the check is on whether the archive file itself is newer or not, using what the plugin calls marker files, and perhaps not on whether the individual archived items are newer or not (is that right?). Is it possible to specify overwrite-if-newer such that it applies to the timestamps on the individual zipped items in the source (I'm using zip as the archive format)? Or is this the default behavior (for example, the Ant task for unZip [2] appears to have this property by default). -Marshall [1] http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules [2] http://ant.apache.org/manual/CoreTasks/unzip.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency:unpack handling of overwrite for individual items in the archive
The documentation for dependency:unpack [1] says that the default is to overwrite (only) if newer. But it seems to apply to the entire archive being unpacked, meaning that the check is on whether the archive file itself is newer or not, using what the plugin calls marker files, and perhaps not on whether the individual archived items are newer or not (is that right?). Is it possible to specify overwrite-if-newer such that it applies to the timestamps on the individual zipped items in the source (I'm using zip as the archive format)? Or is this the default behavior (for example, the Ant task for unZip [2] appears to have this property by default). -Marshall [1] http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite_Rules [2] http://ant.apache.org/manual/CoreTasks/unzip.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
