RE: versions maven plugin
I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however... IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!). If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness. Or to put it another way Staging with any human intervention is evil. Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now). Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) Z is released into a stage The library is picked up in product X (inside say another RPM) QC start testing Z. QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped QC finish testing Z from the stage and then promote it as its good. The Y developers re-spin 1.2.3... Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo. The build Z is unreproducible - this is the worst possible situation to be in, Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM. Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible. /James -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 20 January 2014 19:40 To: Maven Users List Subject: Re: versions maven plugin Consider staging support on your repo manager On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com javascript:; wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you increase all your versions to your next RC-2-SNAPSHOT as soon as you create your RC-1, but if that RC-1 happens to be released, then all your poms will be depending on the SNAPSHOT of an RC-2 that will never be made so you have to downgrade your dependency versions Am I doing something out of the ordinary here? Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:;javascript: ; To: Maven Users List users@maven.apache.org javascript:;javascript:;, Date: 2014-01-20 12:34 Subject:Re: versions maven plugin v-m-p does not roll back version numbers On 20 January 2014 16:59, alejandro.e...@miranda.com javascript:;javascript:; wrote: Not sure if this is the right list for codehaus plugins. If not I apologize I have a pom with this dependencies dependency groupIdfoo.blah/groupId artifactIdbar/artifactId version1.2.0-RC-7-SNAPSHOT/version /dependency /dependencies I want to run the versions plugin to replace 1.2.0-RC-7-SNAPSHOT with the version we actually released of the code, which is 1.2.0-RC-6. Looking at the available mojos, it seems like versions:use-latest-releases is the right one to use. In the matrix here it says that this goal will modify -SNAPSHOT dependencies.
Re: versions maven plugin
On 21 January 2014 09:41, James Nord (jnord) jn...@cisco.com wrote: I wouldn't have normally chimed in here against Stephen (He knows what he is on about) however... IMHO Staging only works with very small teams with dedicated infrastructure (in which case QC generally are ok with a rebuild!). If you have larger teams and share infrastructure (repo manager, CI) across projects (and binaries across teams) then that way will lead to madness. Or to put it another way Staging with any human intervention is evil. Staging without human intervention is doing things too late - you should know before hand that your code is good to go (if you use releases) - and if you are doing things without human intervention then you should know up front that the code is good to go - which means you don't need staging (apart form for an atomic deployment of a multi module build; but there are other ways to do that now). Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's The case of Z may be OK as Z may be an arch specific component... but you are calling it a product, so if it is a product then you should have closed and released the library Y stage *before* you consume from Z Z is released into a stage The library is picked up in product X (inside say another RPM) QC start testing Z. QC test X and it reveals a bug in Y. Both stages (Y and X) are dropped QC finish testing Z from the stage and then promote it as its good. The Y developers re-spin 1.2.3... Well the issue here is that you should only stage the last layer. In this example Y cannot be tested on its own, so there is no point spinning RCs, etc. You just have to bite the bullet and cut a release. It doesn't matter whether you call the release 1.5-RC-1 or 1.5.0 because if you need to respin, you'll be bumping another version anyway. Where staging matters is at the last, publically visible, layer... i.e. Z. You use staging for Z and just spin version numbers and releases for everything else. If Y and Z are in the same release root... then they both get staged. If they are in separate release roots, then Y just bangs out releases and Z has staging. More complex is when both Y and Z are public... i.e. Y is the API client that Z uses... well in that case how is a broken 1.5-RC-1 being out there any different from a broken 1.5.0... the solution is obvious... you need tests that you can trust... get those tests and then apply staging on Y Z is released into the field with a verison of Y that doesn't match what's at some point going to be in the repo. The build Z is unreproducible - this is the worst possible situation to be in, Now there are those that say - your staging rules on your MRM should check the dependencies - but now you are at the behest of your MRM. Nexus certainly can't do this without custom effort on your side - and then you will have to intimately have full knowledge of the inside of the build that produced this artifact - what groups on your MRM use, what version of maven.. You can't just unpack and look at the use the dependencies - what about shaded deps. To do all this work post build is IMHO nigh on impossible. /James -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: 20 January 2014 19:40 To: Maven Users List Subject: Re: versions maven plugin Consider staging support on your repo manager On Monday, 20 January 2014, alejandro.e...@miranda.com wrote: I didn't. QA is not happy about rebuilding the system once it's been approved so we have to release the RC as approved. So all our versions are always RC-X-SNAPSHOT or RC-X Alejandro Endo | Software Designer/Concepteur de logiciels From: Stephen Connolly stephen.alan.conno...@gmail.com javascript:; To: Maven Users List users@maven.apache.org javascript:;, Date: 2014-01-20 13:50 Subject:Re: versions maven plugin How did you turn your RC into a released version? (I would do it with the release plugin and just verify the SCM changelog is unchanged) On Monday, 20 January 2014, alejandro.e...@miranda.com javascript:; wrote: Thank you Stephen. Are there any other ways to stabilize my dependencies then? i have 300 poms all depending on the released+1 development version. This must be a common use-case when using RCs, no? you
RE: versions maven plugin
Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's But it did not sound like that was the original authors request as he was using RCs of dependencies (libraries). So I felt like the solution of staging here would leave to a somewhat similar example to that above. /James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: versions maven plugin
It sounded like a single reactor release of everything to me... in which case staging is fine On 21 January 2014 11:07, James Nord (jnord) jn...@cisco.com wrote: Or to put a contrived (yet realistic) example on this - Consider a shared library Y. You have no auto testing of it so its only tested inside products (otherwise you know its good to go - and wouldn't release RCs). Library Y is in a stage at version 1.2.3 This library is picked up from the stage and placed into a product Z (inside say an RPM) If you are doing this then you are using staging wrong IMHO. A stage should *only* be used for either testing the staged release *or* for where there is a synchronized deliverable that must be built from a different machine, e.g. the windows .DLL and the linux .so's But it did not sound like that was the original authors request as he was using RCs of dependencies (libraries). So I felt like the solution of staging here would leave to a somewhat similar example to that above. /James - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-deploy-plugin: exclude specific project artifact(s)?
Hello We use this to prevent deploying ears/wars into our repo. Everything is built but not everything gets deployed. Newer versions of the deploy plugin allow you to skip deployment so within a few specific poms you can add. plugin artifactIdmaven-deploy-plugin/artifactId version2.8.1/version configuration skiptrue/skip /configuration /plugin This should work as long as you assemble each piece separately (each has its own pom.xml) so divide and conquer. Hope this helps. -- Best Regards, Gord Cody Release Manager Zafin Labs Americas Inc. 179 Colonnade Road-Suite 100, Ottawa ON, Canada Phone: +1 (613) 216-2504 Fax: +1 (613) 688-1374 Mobile: +1 613-601-2734 Web: http://zafin.com Email: gordon.c...@zafin.com -- Zafin - Canada -- http://zafin.com http://zafin.com/ -- Connect with us http://www.youtube.com/user/ZafinGlobal http://www.linkedin.com/company/Zafin http://twitter.com/Zafin News and Events Zafin among Top 10 FinTech Companies to Watch in 2014: American Bankerhttp://zafin.com/zafin-among-top-10-fintech-companies-to-watch-in-2014-american-banker/
Excluding a submodule from package/install phases.
Hello, In our multi-module project we have one module that is only used for development in our IDE. Is there a way to configure this project so that it is always excluded from package phase? Thanks, -Todd
Re: Excluding a submodule from package/install phases.
Hi Todd, In our multi-module project we have one module that is only used for development in our IDE. Is there a way to configure this project so that it is always excluded from package phase? With Eclipse, you can do something similar using profiles: profiles profile ideclipse/id activation property namem2e.version/name /property /activation modules modulemy-eclipse-specific-module/module /modules /profile /profiles This excludes the my-eclipse-specific-module module completely from the command-line build. If you aren't using Eclipse, perhaps your IDE sets a similar property. Regards, Curtis On Tue, Jan 21, 2014 at 10:52 AM, Todd Chapman t...@chaka.net wrote: Hello, In our multi-module project we have one module that is only used for development in our IDE. Is there a way to configure this project so that it is always excluded from package phase? Thanks, -Todd
Re: turns EAR into an OSGi
Hi thank you very much for your response. Maybe I asked in a wrong way but I have everything made yet with maven. I have all the poms that build my whole project. I would like to know If making only some changes in my pom.xml that package a ear I could change it into an osgi bundle. I don't want to change my architecture or design only add the necessary OSGi metadata to my project. Thank you very much. -- View this message in context: http://maven.40175.n5.nabble.com/turns-EAR-into-an-OSGi-tp5781929p5781991.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: turns EAR into an OSGi
have all the poms that build my whole project. I would like to know If making only some changes in my pom.xml that package a ear I could change it into an osgi bundle. I don't want to change my architecture or design This is not an unreasonable question, but you just might not get an answer to your question here. I have never (thus far) needed to do such a thing, so while I know a lot about Maven and plugins etc, I have no idea how to turn an EAR into an OSGi module. You may have better luck asking this question on an OSGi list somewhere - perhaps there is an OSGi plugin for Maven and you could ask their user/dev list? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven add resource
Hi, I would have a question to Maven and additional resources. I have build a simple Maven project, afterwards I did mvn eclipse:eclipse and than I imported it into Eclipse. This all worked fine. Afterwards I would like to extend the pom.xml (below) in order to have new file structure which is in classpath to the existion one: src/main/java and src/test/java I would like this additional folder structure: src/main/generated in my Maven project and also in my Eclipse project. Therefore I have defined src/main/generated into my pom. My opinion was that if I add it to the pom than it appears at the file system and also in eclipse after a refresh - but this isn't. Does anyone know why this is so and what I'am doing wrong? Thanks a lot and all the best PollerJava 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 groupIdat.company.app/groupId artifactIdmy-project/artifactId packagingjar/packaging namemy-project/name urlhttp://maven.apache.org/url parent groupIdat.company.app/groupId artifactIdmy-master/artifactId version1.0-SNAPSHOT/version relativePath../my-master/pom.xml/relativePath /parent properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId executions execution phasegenerate-sources/phase goalsgoaladd-source/goal/goals configuration sources sourcesrc/main/generated/source /sources /configuration /execution /executions /plugin /plugins /build /project -- View this message in context: http://maven.40175.n5.nabble.com/Maven-add-resource-tp5781977.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Deprecated ArtifactMetadataSource
Hi everyone, I am currently working on a maven plugin and we made use of the interface ArtifactMetadataSource, which is deprectaed by now. I was trying to find whatelse we could use but unfortunatly without any success until now. It would be nice if someone could help me. Best regards! -- View this message in context: http://maven.40175.n5.nabble.com/Deprecated-ArtifactMetadataSource-tp5781983.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven add resource
Hi PollerJava, I would like this additional folder structure: src/main/generated in my Maven project and also in my Eclipse project. I suggest using M2E rather than the eclipse:eclipse goal. With a modern Eclipse for Java Developers IDE, Maven support is built in, and you don't need eclipse:eclipse anymore. Just do File Import Existing Maven Project. To get generated-sources to work, you may also need to follow the directions here: http://stackoverflow.com/a/7160614 Regards, Curtis On Tue, Jan 21, 2014 at 3:24 AM, PollerJava max...@gmx.at wrote: Hi, I would have a question to Maven and additional resources. I have build a simple Maven project, afterwards I did mvn eclipse:eclipse and than I imported it into Eclipse. This all worked fine. Afterwards I would like to extend the pom.xml (below) in order to have new file structure which is in classpath to the existion one: src/main/java and src/test/java I would like this additional folder structure: src/main/generated in my Maven project and also in my Eclipse project. Therefore I have defined src/main/generated into my pom. My opinion was that if I add it to the pom than it appears at the file system and also in eclipse after a refresh - but this isn't. Does anyone know why this is so and what I'am doing wrong? Thanks a lot and all the best PollerJava 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 groupIdat.company.app/groupId artifactIdmy-project/artifactId packagingjar/packaging namemy-project/name urlhttp://maven.apache.org/url parent groupIdat.company.app/groupId artifactIdmy-master/artifactId version1.0-SNAPSHOT/version relativePath../my-master/pom.xml/relativePath /parent properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency /dependencies build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdbuild-helper-maven-plugin/artifactId executions execution phasegenerate-sources/phase goalsgoaladd-source/goal/goals configuration sources sourcesrc/main/generated/source /sources /configuration /execution /executions /plugin /plugins /build /project -- View this message in context: http://maven.40175.n5.nabble.com/Maven-add-resource-tp5781977.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Deprecated ArtifactMetadataSource
Hi lsommer,
we made use of the interface ArtifactMetadataSource, which is
deprectaed by now. I was trying to find whatelse we could use but
unfortunatly without any success until now.
Unfortunately, I do not have an answer for you. But I will take the
opportunity to sympathize with you -- and chastise anyone who deprecates
code without explaining what the migration path is in the javadoc. IMHO, a
@Deprecated tag should *always* be accompanied by something like
@deprecated Use {@link Foo#bar()} instead. in the corresponding javadoc.
*Especially* for really heavily used APIs like Maven's.
Regards,
Curtis
On Tue, Jan 21, 2014 at 4:24 AM, lsommer lsom...@zeb.de wrote:
Hi everyone,
I am currently working on a maven plugin and we made use of the interface
ArtifactMetadataSource, which is deprectaed by now. I was trying to find
whatelse we could use but unfortunatly without any success until now.
It would be nice if someone could help me.
Best regards!
--
View this message in context:
http://maven.40175.n5.nabble.com/Deprecated-ArtifactMetadataSource-tp5781983.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
