dependencyManagament dependencies within profiles are not activated by settings.xml
Hi Could someone give me a comment to this issue, please? Is it by design or a bug? http://jira.codehaus.org/browse/MNG-4538 Thanks for advice, Christian Moser
Maven 3 alpha status
Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 alpha status
On 2010-01-29, at 12:08 PM, Julien HENRY wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. We have a nice stream of people testing it right now and Maven 3.x is progressing nicely. I honestly don't want mass corporate use until 3.0 is ready because they are the users that tend to treat us like a support desk whenever something goes wrong. The alpha and beta signifiers keep those people away which is the intention. The people who are willing to try the alphas and betas are the people I want trying them. We can handle the feedback we're getting now and we're about to do another large push in 3.0-alpha-7 to try and drastically reduce the bug count. After the 3.0-alpha-7 is finished I think we will start the betas. Once we switch to betas then I think we'll get another additional wave of users and I'm sure we'll find a lot more incompatibilities that need to be fixed. Naming the release inappropriately would be misleading and ultimately give people the impression we're just trying to foist our QA on the users. RCs will start coming out when we can't find anything else wrong and we are still continually finding small things even though I believe the 3.0-alphas are now an order of magnitude better then any version of Maven 2.x. It will be released when its ready and no sooner. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 alpha status
Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge
Re: Maven 3 alpha status
could we use milestone as names in replacement for alpha, so that we get more early-adopter to test the (pre)release and detected regressions ? I can understand the difficulty to suggest a build tool with alpha in version name. Would you install Windows 8 alpha on your @work computer ? ;) 2010/1/29 Stephane Nicoll stephane.nic...@gmail.com Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge
Re : Maven 3 alpha status
Hi, The bug is something similar to [1] (at leat same error message except the type is xml.zip in my case). The EAR module is building fine alone, but as soon as I launch a full reactor build, the build fails. Running with -X show the dependency is in the EAR plugin classpath but it should not be the case. The xml.zip dependency is used in that way: pom (of a transitive dependency of EAR module) plugin artifactIdandromda-maven-plugin/artifactId dependencies artifactIdfoo/artifactId typexml.zip/type /dependencies /plugin Do you think there is a chance this issue will be fixed in Maven 2.2.x? I fear the answer will be = fixed in Maven 3... [1] http://www.mail-archive.com/us...@maven.apache.org/msg94040.html - Message d'origine De : Stephane Nicoll stephane.nic...@gmail.com À : Maven Developers List dev@maven.apache.org Envoyé le : Ven 29 Janvier 2010, 15 h 14 min 59 s Objet : Re: Maven 3 alpha status Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re : Maven 3 alpha status
I don't think it will be fixed in Maven 2.2 but as far as the ear plugin is concerned you can workaround it, just declare your zip dependency as provided. The problem here is that your EAR project has a wrong zip dependency with please bundle it scope. S. On Fri, Jan 29, 2010 at 4:33 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, The bug is something similar to [1] (at leat same error message except the type is xml.zip in my case). The EAR module is building fine alone, but as soon as I launch a full reactor build, the build fails. Running with -X show the dependency is in the EAR plugin classpath but it should not be the case. The xml.zip dependency is used in that way: pom (of a transitive dependency of EAR module) plugin artifactIdandromda-maven-plugin/artifactId dependencies artifactIdfoo/artifactId typexml.zip/type /dependencies /plugin Do you think there is a chance this issue will be fixed in Maven 2.2.x? I fear the answer will be = fixed in Maven 3... [1] http://www.mail-archive.com/us...@maven.apache.org/msg94040.html - Message d'origine De : Stephane Nicoll stephane.nic...@gmail.com À : Maven Developers List dev@maven.apache.org Envoyé le : Ven 29 Janvier 2010, 15 h 14 min 59 s Objet : Re: Maven 3 alpha status Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge
Re: Maven 3 alpha status
On 2010-01-29, at 4:09 PM, nicolas de loof wrote: could we use milestone as names in replacement for alpha, so that we get more early-adopter to test the (pre)release and detected regressions ? I can understand the difficulty to suggest a build tool with alpha in version name. Would you install Windows 8 alpha on your @work computer ? ;) I'm not really into playing the name game to please managers. I think what we're doing is the right way to go. It's going to take a bit longer, but we're absorbing the change requests as fast as we can now. The error reports are of good quality and helpful. When those dry up then it will be time to move on. 2010/1/29 Stephane Nicoll stephane.nic...@gmail.com Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 alpha status
Just as a side note: in most projects, alpha implies that changes in features or public APIs is possible or likely. Maybe it's not the case for Maven... []s Gus On Fri, Jan 29, 2010 at 7:38 AM, Jason van Zyl ja...@sonatype.com wrote: On 2010-01-29, at 4:09 PM, nicolas de loof wrote: could we use milestone as names in replacement for alpha, so that we get more early-adopter to test the (pre)release and detected regressions ? I can understand the difficulty to suggest a build tool with alpha in version name. Would you install Windows 8 alpha on your @work computer ? ;) I'm not really into playing the name game to please managers. I think what we're doing is the right way to go. It's going to take a bit longer, but we're absorbing the change requests as fast as we can now. The error reports are of good quality and helpful. When those dry up then it will be time to move on. 2010/1/29 Stephane Nicoll stephane.nic...@gmail.com Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New Release Tree Maven Module
I'm a little confused as to what this approach involves, as you seem to suggest releasing up the dependency tree from a given leaf project? I'd certainly advocate a release goal to release in the opposite direction, i.e. a project and all its snapshot dependencies down the dependency tree. Mark On 16 January 2010 13:37, Daniel Frey qwer12...@gmx.ch wrote: Hi I would like to write my first maven module that does releases over all the dependencies of a main module. I am interested in your opinion, recommondations and critical feedback. Let me first illustrate why I would like to do that. The maven-release-plugin does a release in a way that it: 1. Adds a tag to the repository for the main module 2. Releases al artifacts of the main module (JARs, website) 3. Deploys all artifacts of the main module to the remote repository (JARs for bitecode, sources and javadoc) 4. Allows to change the development versions of the dependent modules What I miss in this approach is: 1. The sites of all dependent modules (including test results and coverage, javadocs, dependencies) 2. Dependent modules artifacts in the repository (distinctly versioned JARs for bitecode, sources and javadoc) 3. Distinct versions of the dependent modules when copying all the needed libraries to the official website (say in a JNLP release) The idea of the new module would be to iterate through all dependent modules from dependency tree leaf towards its root and: 1. Investigate the existing tags on the SVN repository to find one for the dependent module 2. If the dependent module has code changes since the tags revision: 2a. Alter the POM dependent module so it reflects the dependencies to its dependent modules correctly by replacing SNAPSHOT versions with distinct tagged versions 2b. Release the dependent module 3. Else do not release the module but keep the tagged version as the one to replace SNAPSHOTs in subsequent dependent modules Let me illustrate that with a concrete example. Say I have the following multi-module project dependencies for my main module ch.xmatrix.ups.tools.ust (filtering out only my own dependencies): ch.xmatrix.ups.tools.ust 2.1-SNAPSHOT +- ch.xmatrix.ups.tools.common 2.0-SNAPSHOT | +- ch.xmatrix.common.utils-all 2.3-SNAPSHOT | | \- ch.xmatrix.common.icon 1.4-SNAPSHOT | +- ch.xmatrix.ups.data.taxa 2.0-SNAPSHOT | \- ch.xmatrix.ups.data.constraints SNAPSHOT +- ch.xmatrix.ups.data.sessions SNAPSHOT +- ch.xmatrix.ups.data.courses SNAPSHOT \- ch.xmatrix.ups.server.client 2.0-SNAPSHOT \- ch.xmatrix.ups.server.interface 2.0-SNAPSHOT And there would be no current tag for ch.xmatrix.common.utils-all, ch.xmatrix.ups.data.constraints, ch.xmatrix.ups.server.interface and ch.xmatrix.ups.tools.ust without any changes in the meantime. I would like to be prompted for the desired development version change of each these remaining dependent modules. If I choose to keep the same development version, then the release order, the current development version would stay and the release version of this example would be: ch.xmatrix.common.utils-all 2.3-SNAPSHOT 2.3 ch.xmatrix.ups.data.constraints SNAPSHOT 1.0 ch.xmatrix.ups.server.interface 2.0-SNAPSHOT 2.0 ch.xmatrix.ups.tools.ust 2.1-SNAPSHOT 2.1 I currently achive that with a perl script. However, I wonder whether such a task would make sense to be done as a maven module (maven-releasetree-module). If it would make sense, I would see the following main limitation: My approach would use other maven modules like maven-dependency-modules and maven-release-module. Having had a quick look at the maven modules howto, this seem not to be a valid approach. Each module should be self-contained and independent of others. Any advices, recommondations, critical feedback, thoughts would be highly appreciated... Thanks for feedback in advance Daniel Daniel Frey Senior Software Engineer xmatrix Kellerweg 65 CH-8055 Zürich daniel.f...@xmatrix.ch http://www.xmatrix.ch tel: mobile: +41 (44) 241 64 46 +41 (77) 425 28 57 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3 alpha status
On 2010-01-29, at 5:02 PM, Gustavo Hexsel wrote: Just as a side note: in most projects, alpha implies that changes in features or public APIs is possible or likely. Maybe it's not the case for Maven... From the CLI perspective nothing should change, so from that perspective there is less change. It's really finding bugs and making sure the CLI is full compatible. Internally the APIs are still changing as we are improving embedded use as new situations present themselves. []s Gus On Fri, Jan 29, 2010 at 7:38 AM, Jason van Zyl ja...@sonatype.com wrote: On 2010-01-29, at 4:09 PM, nicolas de loof wrote: could we use milestone as names in replacement for alpha, so that we get more early-adopter to test the (pre)release and detected regressions ? I can understand the difficulty to suggest a build tool with alpha in version name. Would you install Windows 8 alpha on your @work computer ? ;) I'm not really into playing the name game to please managers. I think what we're doing is the right way to go. It's going to take a bit longer, but we're absorbing the change requests as fast as we can now. The error reports are of good quality and helpful. When those dry up then it will be time to move on. 2010/1/29 Stephane Nicoll stephane.nic...@gmail.com Which bug are your talking about? Have you filled something in Jira? S. On Fri, Jan 29, 2010 at 12:08 PM, Julien HENRY henr...@yahoo.fr wrote: Hi, Yesterday I spend 2 hours fixing a nasty bug with EAR plugin and dependency with type xml.zip. This dependency was declared in another module of the reactor, and was a dependency of a plugin (maven-andromda-plugin). So there is no reason that the ear plugin see this dependency. As I read Maven 3 is much more precise dealing with plugin classpath and dependencies, I asked the project leader to try with Maven 3 alpha 6. Hourra! It worked fine. So I told the project to migrate to Maven 3 but the project leader was reluctant as it is flagged as alpha. As it seems many Maven guys say Maven 3 alpha 6 is much better than Maven 2.2.1, could you please for next release use a version with a higher qualifier that will not afraid corporate people. IMHO beta will face the same issue, so I suggest rc or something like that. Best regards, Julien - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
