RFP: Version Range Policy
*Maven Developers* 1) This is a formal request to resolve long standing version range policy problem in maven, expressed for example in the following ticket: http://jira.codehaus.org/browse/MNG-3092 THE PROBLEM: LACK OF VERSION RANGE POLICY. 2) I there are no better ideas, I suggest Maven to adopt OSGI Semantic Version Guidelines. https://github.com/barchart/barchart-version-tester/wiki/Version-Policy 3) I have working prototype based on maven 3.0.4 with back port of aether 0.9.0.M2 specifically applied to karaf use case, which could be generalized. https://github.com/barchart/barchart-maven-karaf-plugin 4) there is an Aries version check plugin, that shows generic java binary compatibility checks which should be part of the new maven semantic version contract. https://github.com/apache/aries/tree/trunk/versioning Thank you, Andrei
Re: RFP: Version Range Policy
I am more optimistic then you. here is the idea https://github.com/barchart/barchart-version-tester/wiki/Maven-OSGI Original Message Subject: Re: RFP: Version Range Policy From: David Jencks david_jen...@yahoo.com To: Maven Developers List dev@maven.apache.org Date: Wed 10 Apr 2013 12:44:19 PM CDT Can you explain how you think osgi semantic versioning can reasonably be applied to non-osgi-bundles? It typically takes a project a year or two to figure out what semantic versioning means when converting a project to osgi, I think you would find that trying to apply semantic versioning to non-osgi projects will mean that every update is a major version change. It would be nice if all projects converted to osgi and used semantic versioning correctly, but I don't think that is going to happen any time soon and I don't think the majority of maven projects will be osgi any time soon. thanks david jencks On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Maven Developers* 1) This is a formal request to resolve long standing version range policy problem in maven, expressed for example in the following ticket: http://jira.codehaus.org/browse/MNG-3092 THE PROBLEM: LACK OF VERSION RANGE POLICY. 2) I there are no better ideas, I suggest Maven to adopt OSGI Semantic Version Guidelines. https://github.com/barchart/barchart-version-tester/wiki/Version-Policy 3) I have working prototype based on maven 3.0.4 with back port of aether 0.9.0.M2 specifically applied to karaf use case, which could be generalized. https://github.com/barchart/barchart-maven-karaf-plugin 4) there is an Aries version check plugin, that shows generic java binary compatibility checks which should be part of the new maven semantic version contract. https://github.com/apache/aries/tree/trunk/versioning Thank you, Andrei - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RFP: Version Range Policy
I would deal with this same way osgi does: guidelines, annotations, tools. example: * be clear if your jar is API artifact vs API consumer artifact vs API provider artifact. * @ConsumerType and @ProviderType will tell people what to expect. * enforcement plugins will quickly educate about the distinctions. since maven is convention over configuration, this should work. Have you tried - not yet, about to start :-). please share your experience. Original Message Subject: Re: RFP: Version Range Policy From: David Jencks david_jen...@yahoo.com To: Maven Developers List dev@maven.apache.org Date: Wed 10 Apr 2013 05:54:53 PM CDT so you are basically saying all packages are exported. I think you will find that few meaningful code changes will result in a non-major-version change whether or not the intended api changes. Have you tried this out with some real non-osgi projects to see what versions you'd come up with and whether they correspond in any way with what the project developers think the versions are? thanks david jencks On Apr 10, 2013, at 3:23 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: I am more optimistic then you. here is the idea https://github.com/barchart/barchart-version-tester/wiki/Maven-OSGI Original Message Subject: Re: RFP: Version Range Policy From: David Jencks david_jen...@yahoo.com To: Maven Developers List dev@maven.apache.org Date: Wed 10 Apr 2013 12:44:19 PM CDT Can you explain how you think osgi semantic versioning can reasonably be applied to non-osgi-bundles? It typically takes a project a year or two to figure out what semantic versioning means when converting a project to osgi, I think you would find that trying to apply semantic versioning to non-osgi projects will mean that every update is a major version change. It would be nice if all projects converted to osgi and used semantic versioning correctly, but I don't think that is going to happen any time soon and I don't think the majority of maven projects will be osgi any time soon. thanks david jencks On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Maven Developers* 1) This is a formal request to resolve long standing version range policy problem in maven, expressed for example in the following ticket: http://jira.codehaus.org/browse/MNG-3092 THE PROBLEM: LACK OF VERSION RANGE POLICY. 2) I there are no better ideas, I suggest Maven to adopt OSGI Semantic Version Guidelines. https://github.com/barchart/barchart-version-tester/wiki/Version-Policy 3) I have working prototype based on maven 3.0.4 with back port of aether 0.9.0.M2 specifically applied to karaf use case, which could be generalized. https://github.com/barchart/barchart-maven-karaf-plugin 4) there is an Aries version check plugin, that shows generic java binary compatibility checks which should be part of the new maven semantic version contract. https://github.com/apache/aries/tree/trunk/versioning Thank you, Andrei - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
this will work as well, thank you for the idea. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Nigel Magnay nigel.mag...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Tue 09 Apr 2013 03:47:21 AM CDT This keeps coming up, over and over and over. e.g: http://maven.40175.n5.nabble.com/Meta-information-about-dependencies-in-a-pom-td4971927.html The maven 'answer' seems to amount to 'hard cheese, you must re-specify each and every one of your dependencies again in your plugin config'. And then pointing to the configuration horror that is the assembly plugin, and completely ignoring the duplication of, like, every single dependency in your use-case. And if your language has scopes other than the burnt-in ones in maven, double-hard cheese with a cherry on top - welcome to screenfuls of warnings and a non-working transitive dependency mechanism. Despite the fact you're already paying the XML tax (so each dependency takes 5 lines in your POM file, compared to single lines in other tools), *and* the fact that XML has a well-defined capability with namespaces to compatibly extend the data (and have those extensions easy to strip out), maven refuses to contemplate this, it seems. How about project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:karaf=maven:plugin:com.apache:karaf 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; dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version karaf:osgiStartLevel99/karaf:osgiStartLevel karaf:bootInstalltrue/karaf:bootInstall /dependency On Thu, Apr 4, 2013 at 2:57 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Hervé: thank you for taking the time to respond. issue at hand: karaf http://karaf.apache.org/ has features.xml, which are built from pom.xml http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html what is missing from maven is the ability to communicate arbitrary custom attributes on per-dependency basis, such as: provide osgiStartLevel value, to specify to osgi runtime bundle start level: dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version osgiStartLevel99/osgiStartLevel /dependency or provide karafBootInstall flag, to specify that karaf runtime should install this dependency at boot-time vs build-time: dependency groupIdcom.example/groupId artifactIdbundle-feature/artifactId version1.0.1/version classifierfeatures/classifier typexml/type karafBootInstalltrue/karafBootInstall /dependency in lieu of these, karaf-maven-plugin is trying to encode this information via scope https://github.com/apache/karaf/blob/trunk/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/InstallKarsMojo.java#L215 which contradicts the dependency resolution rules and really does not work. hence my request to relax. is there any other ways to address this need? Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 01:21:32 AM CDT AFAIK, there is nothing relaxed from Mven 3.0.x planned But I don't really understand your case (and miss time to investigate in Karaf). Can you give us a pointer to SCM, or paste such a dependency with custom tags? Regards, Hervé Le mercredi 3 avril 2013 08:51:01 Andrei Pozolotin a écrit : I am curious if 3.1.0 will be more relaxed with custom tags inside dependency? Use case: karaf-maven-plugin uses bizarre conventions on how to map from scope into osgi bundle properties (like start level) because there is no way to have a custom tag in dependency and express this requirement. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Tue 02 Apr 2013 12:04:18 PM CDT Thanks. On Apr 2, 2013, at 1:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Staged documentation: http://maven.apache.org/ref/3.1.0-alpha-1/ Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500versio n=18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/ mave n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason
Re: Dependency properties
Hervé here are few thoughts: 1) transitive concern is valid, but should not be enforced the way it is now. 2) user properties on dependencies are a valid feature to help plugin writers. 3) it would help to have standard api to extract these user properties from dependency 4) it could be implemented as optional xsd entry for dependency/properties where properties is a modello component identical to the project/properties Thank you, Andrei Original Message Subject: Dependency properties From: Hervé BOUTEMY herve.bout...@free.fr To: dev@maven.apache.org Date: Fri 05 Apr 2013 12:37:09 AM CDT what about the shortcoming described in the Why there are no dependency properties in Maven2 article? Notice we're back at a the POM model question (+ compatibility and so on) [1] But let's start with understanding the need and how it can scale or not Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model Le jeudi 4 avril 2013 12:54:50 Andrei Pozolotin a écrit : yes: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-Whytherearenodepend encypropertiesinMaven2 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
Jörg: you are right. but for me it feels like violation of http://en.wikipedia.org/wiki/Don't_repeat_yourself http://en.wikipedia.org/wiki/Don%27t_repeat_yourself especially if I have half a hundred entries in pom.xml. Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Jörg Schaible joerg.schai...@scalaris.com To: dev@maven.apache.org Date: Fri 05 Apr 2013 02:35:06 AM CDT Hi Andrei, Andrei Pozolotin wrote: *Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Then why don't you use custom properties that follow simple naming conventions? Just run in your mojo through the list of (resolved) dependencies and look if an appropriate custom property has been defined: dependencies ... dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version /dependency dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version classifierfeatures/classifier typexml/type /dependency ... /dependencies ... properties ... karaf.com.example.bundle.osgiStartLevel99/karaf.com.example.bundle.osgiStartLevel karaf.com.example.bundle.features.bootInstalltrue/karaf.com.example.bundle.features.bootInstall ... /properties Obvious naming convention: karaf.groupId.artifactId[.classifier].variable - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
Hervé: thank you for taking the time to respond. issue at hand: karaf http://karaf.apache.org/ has features.xml, which are built from pom.xml http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html what is missing from maven is the ability to communicate arbitrary custom attributes on per-dependency basis, such as: provide osgiStartLevel value, to specify to osgi runtime bundle start level: dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version osgiStartLevel99/osgiStartLevel /dependency or provide karafBootInstall flag, to specify that karaf runtime should install this dependency at boot-time vs build-time: dependency groupIdcom.example/groupId artifactIdbundle-feature/artifactId version1.0.1/version classifierfeatures/classifier typexml/type karafBootInstalltrue/karafBootInstall /dependency in lieu of these, karaf-maven-plugin is trying to encode this information via scope https://github.com/apache/karaf/blob/trunk/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/InstallKarsMojo.java#L215 which contradicts the dependency resolution rules and really does not work. hence my request to relax. is there any other ways to address this need? Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 01:21:32 AM CDT AFAIK, there is nothing relaxed from Mven 3.0.x planned But I don't really understand your case (and miss time to investigate in Karaf). Can you give us a pointer to SCM, or paste such a dependency with custom tags? Regards, Hervé Le mercredi 3 avril 2013 08:51:01 Andrei Pozolotin a écrit : I am curious if 3.1.0 will be more relaxed with custom tags inside dependency? Use case: karaf-maven-plugin uses bizarre conventions on how to map from scope into osgi bundle properties (like start level) because there is no way to have a custom tag in dependency and express this requirement. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Tue 02 Apr 2013 12:04:18 PM CDT Thanks. On Apr 2, 2013, at 1:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Staged documentation: http://maven.apache.org/ref/3.1.0-alpha-1/ Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500versio n=18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/ mave n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org .
Re: [VOTE] Apache 3.1.0-alpha-1
Wayne: the way I understand your suggestions is essentially I must duplicate configuration: 1) first I have to mention the dependency, because I need the dependency 2) second, I need some extra entry somewhere to map same dependency to custom properties. am I getting you right? Andrei. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 09:43:24 AM CDT what is missing from maven is the ability to communicate arbitrary custom attributes on per-dependency basis, such as: provide osgiStartLevel value, to specify to osgi runtime bundle start level: ... or provide karafBootInstall flag, to specify that karaf runtime should install this dependency at boot-time vs build-time: ... in lieu of these, karaf-maven-plugin is trying to encode this information via scope https://github.com/apache/karaf/blob/trunk/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/InstallKarsMojo.java#L215 which contradicts the dependency resolution rules and really does not work. hence my request to relax. is there any other ways to address this need? IMO this can and should all be handled via configuration in the karaf-m-p and not via adding attributes in dependencies which are specific to one plugin. Otherwise the Assembly plugin could reasonably ask to put outputFileNameMapping as an (optional) attribute of the dependency, and the Ear plugin could ask to put bundleFileName as an (optional) attribute, etc. That way lies madness. Look at how Assembly and Ear plugins (and others) are doing similar things for guidance on how to implement these features in the karaf plugin itself. FWIW I agree that doing it via scope is the wrong way to do it. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
*Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 09:56:40 AM CDT the way I understand your suggestions is essentially I must duplicate configuration: Yes, just like you do with the other plugins mentioned. Wayne
Re: [VOTE] Apache 3.1.0-alpha-1
Fred I am sorry I do not understand what you mean. Can you please clarify? The only reason am I bothering people on maven dev list is because maven refuses to work at all when I add custom xml entries to the dependency. I would assume it would be easy change just to ignore things maven does not expect, and do not blow up. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Fred Cooke fred.co...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 10:31:57 AM CDT Can you not programatically access the dependencies by index? Sure it would be fragile to dep order changes, but it would not be duplication. +1 to everything Wayne said. On Thu, Apr 4, 2013 at 5:03 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 09:56:40 AM CDT the way I understand your suggestions is essentially I must duplicate configuration: Yes, just like you do with the other plugins mentioned. Wayne
Re: [VOTE] Apache 3.1.0-alpha-1
Michael: re classifiers or build qualiafiers - these are not variations on dependency this is same dependency, but in different poms this dependency have different custom property. think of it like @Inject annotation in guice Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Michael-O 1983-01...@gmx.net To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 11:08:01 AM CDT Am 2013-04-04 15:57, schrieb Andrei Pozolotin: Hervé: thank you for taking the time to respond. issue at hand: karaf http://karaf.apache.org/ has features.xml, which are built from pom.xml http://karaf.apache.org/manual/latest-2.3.x/users-guide/provisioning.html what is missing from maven is the ability to communicate arbitrary custom attributes on per-dependency basis, such as: provide osgiStartLevel value, to specify to osgi runtime bundle start level: dependency groupIdcom.example/groupId artifactIdbundle/artifactId version1.0.1/version osgiStartLevel99/osgiStartLevel /dependency or provide karafBootInstall flag, to specify that karaf runtime should install this dependency at boot-time vs build-time: dependency groupIdcom.example/groupId artifactIdbundle-feature/artifactId version1.0.1/version classifierfeatures/classifier typexml/type karafBootInstalltrue/karafBootInstall /dependency I think that variations of depenencies must go either in classifiers or build qualiafiers. If we start allow arbitrary elements in dependency, people will start to ask for custom elements in X. Therefore custom elements are allow in a plugin's configuration only. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
got it, thank you. I still would like you to conciser my change request. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Fred Cooke fred.co...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 11:14:46 AM CDT I mean, you can grab any array pom properties by index in a variable, why not do it in code, if you don't want duplication. This way the fragility is limited to index and easily fixed if it gets messed up by an added dependency. http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide http://jira.codehaus.org/browse/PLXUTILS-37 It's just an idea, and not something I'd do. Fred. On Thu, Apr 4, 2013 at 5:53 PM, Andrei Pozolotin andrei.pozolo...@gmail.com mailto:andrei.pozolo...@gmail.com wrote: Fred I am sorry I do not understand what you mean. Can you please clarify? The only reason am I bothering people on maven dev list is because maven refuses to work at all when I add custom xml entries to the dependency. I would assume it would be easy change just to ignore things maven does not expect, and do not blow up. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Fred Cooke fred.co...@gmail.com mailto:fred.co...@gmail.com To: Maven Developers List dev@maven.apache.org mailto:dev@maven.apache.org Date: Thu 04 Apr 2013 10:31:57 AM CDT Can you not programatically access the dependencies by index? Sure it would be fragile to dep order changes, but it would not be duplication. +1 to everything Wayne said. On Thu, Apr 4, 2013 at 5:03 PM, Andrei Pozolotin andrei.pozolo...@gmail.com mailto:andrei.pozolo...@gmail.com wrote: *Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com mailto:wayne...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com mailto:andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org mailto:dev@maven.apache.org Date: Thu 04 Apr 2013 09:56:40 AM CDT the way I understand your suggestions is essentially I must duplicate configuration: Yes, just like you do with the other plugins mentioned. Wayne
Re: [VOTE] Apache 3.1.0-alpha-1
Tamás Thank you very much for the complete nexus plugin example, it seems like one-to-one mapping to our osgi problem domain. I now totally get what you are saying, and yes, we could use the approach similar to nexus plugin declarations in the karaf maven plugin. However (unfortunately?), I was watching Jason Van Zyl presentation about maven 3.1.0 and got (over?) inspired by the promise to get free from the constrains of the past :-) And the approach the nexus plugin is taking seems like a needless kludge work around basic need to be able to annotate dependency with user properties - the kind of constrains I would like maven to remove in 3.1.0. So: can I please respectfully request a formal PMC vote on my change request or should I just go away and leave you all alone? :-) Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Tamás Cservenák ta...@cservenak.net To: Maven Developers List dev@maven.apache.org Cc: Wayne Fay wayne...@gmail.com Date: Thu 04 Apr 2013 11:19:01 AM CDT Andrei, Wayne is right, the dependencies (or even depMgt) section is NOT a place for information like these. This is Karaf plugin specific, it must go into plugin configuration. As _similar_ example, here is a quite simple example, but with very similar intention (true, the amount of params here is 1, but the plugin config is easily extensible to receive whatever you want): https://github.com/sonatype/nexus-plugin-bundle This plugin above is meant to create Nexus Plugin Bundles. While those are NOT OSGi plugins, they are designed similarly. Every Nexus plugin (might) have a set of dependencies, and it might choose to keep the private or export them (make those available for other plugin bundles depending on this plugin). A good example plugin configuration is the one for nexus-indexer-lucene-plugin (that bundles Maven Indexer as Nexus plugin). The Maven Indexer API sadly has Lucene refefences, so it _has_ to export Lucene too. Hence, the nexus-plugin-bundle-plugin config looks like this: https://github.com/sonatype/nexus/blob/master/plugins/indexer/nexus-indexer-lucene-plugin/pom.xml#L135 As you see, the plugin defines dependencies as usual, and the plugin configuration simply enlists the GAs of deps needed to make them public. This means that change for plugin config is needed only when G or A changes of a dependency, or a new dependency needs to be exported... Now, in your case, this list here https://github.com/sonatype/nexus-plugin-bundle/blob/master/maven-plugin/src/main/java/org/sonatype/nexus/pluginbundle/maven/GenerateMetadataMojo.java#L83 Might be something other than ListString, it might be a list of some beans, or even list of maps (can maven do that from plugin config?) that can hold ANY property you want to use in your plugin. HTH, ~t~ On Thu, Apr 4, 2013 at 5:03 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 09:56:40 AM CDT the way I understand your suggestions is essentially I must duplicate configuration: Yes, just like you do with the other plugins mentioned. Wayne
Re: [VOTE] Apache 3.1.0-alpha-1
Wayne and ALL: Thank you very much for considering this request, I got my answer. Does it make sense to file a jira at this point? Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 12:10:07 PM CDT to be able to annotate dependency with user properties - the kind of constrains I would like maven to remove in 3.1.0. Doubtful to be removed in 3.1.0. So: can I please respectfully request a formal PMC vote on my change request or should I just go away and leave you all alone? :-) No need to go away but please appreciate this is an issue that we are aware of and will continue to discuss for enhancement/change in some future release of Maven. Calling for a formal vote of the PMC at this time is unlikely to provide the result you desire. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
yes: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-WhytherearenodependencypropertiesinMaven2 Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 12:47:18 PM CDT Are you talking about properties on dependencies like we used to have in Maven 1.x? On Apr 4, 2013, at 1:28 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Wayne and ALL: Thank you very much for considering this request, I got my answer. Does it make sense to file a jira at this point? Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 12:10:07 PM CDT to be able to annotate dependency with user properties - the kind of constrains I would like maven to remove in 3.1.0. Doubtful to be removed in 3.1.0. So: can I please respectfully request a formal PMC vote on my change request or should I just go away and leave you all alone? :-) No need to go away but please appreciate this is an issue that we are aware of and will continue to discuss for enhancement/change in some future release of Maven. Calling for a formal vote of the PMC at this time is unlikely to provide the result you desire. Wayne - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: [VOTE] Apache 3.1.0-alpha-1
ideally, yes, I would expect to get user properties from dependencies as part of standard maven api. IIRC it was just a string-only property bag multimap in maven 1.x but I am not even asking that, I can parse pom.xml again in my plugin and find what I need. where I need your help is not to enforce the model - I can not seem to find a way to bypass current behavior alternatively, lets revert to how it was in maven 1.x Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 04:18:09 PM CDT if we add such relaxed load during build, how do you expect to retrieve the info? I suppose you'll need an API to catch the info Regards, Hervé Le jeudi 4 avril 2013 10:03:25 Andrei Pozolotin a écrit : *Wayne* 1) in this case I choose madness :-) 2) here is my request: please provide an option to modello or whoever is enforcing strict xml model in maven to relax the rules, so people can use maven they way it fits them, while enforcing the rules by default. Thank you, Andrei Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Wayne Fay wayne...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Thu 04 Apr 2013 09:56:40 AM CDT the way I understand your suggestions is essentially I must duplicate configuration: Yes, just like you do with the other plugins mentioned. Wayne - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache 3.1.0-alpha-1
I am curious if 3.1.0 will be more relaxed with custom tags inside dependency? Use case: karaf-maven-plugin uses bizarre conventions on how to map from scope into osgi bundle properties (like start level) because there is no way to have a custom tag in dependency and express this requirement. Original Message Subject: Re: [VOTE] Apache 3.1.0-alpha-1 From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Tue 02 Apr 2013 12:04:18 PM CDT Thanks. On Apr 2, 2013, at 1:00 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Staged documentation: http://maven.apache.org/ref/3.1.0-alpha-1/ Regards, Hervé Le lundi 1 avril 2013 08:12:09 Jason van Zyl a écrit : Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18 967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/mave n/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: [VOTE] Apache 3.1.0-alpha-1
I am curious if 3.1.0 will be more relaxed with custom tags inside dependency? Use case: karaf-maven-plugin uses bizarre conventions on how to map from scope into osgi bundle properties (like start level) because there is no way to have a custom tag in dependency and express this requirement. Original Message Subject: [VOTE] Apache 3.1.0-alpha-1 From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Mon 01 Apr 2013 07:12:09 AM CDT Here are the release bits for 3.1.0-alpha-1: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967 Staging repository: https://repository.apache.org/content/repositories/maven-042/ Staged distribution: https://repository.apache.org/content/repositories/maven-042/org/apache/maven/apache-maven/3.1.0-alpha-1/ Anyone trying this in advance should know that the Site, Dependency, and Shade plugin are not going to work. We are aware of this and those responsible for those plugins are looking into it. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare
Re: WTF is Tesla?
great, thank you for the update. Original Message Subject: Re: WTF is Tesla? From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Date: Mon 01 Apr 2013 06:52:44 AM CDT I have been focusing on getting this next Maven release out which has taken a lot longer than I had wished. This release of Maven will serve as the first building block of Tesla. I require the JSR330, SLF4J, and Eclipse Aether changes in order for the features I plan to be a pure superset of Maven. I do not want a forked core if it can be avoided, and I think it can. So, first things first, once this release is out I can take the Maven binary distribution and layer in parts of Tesla. I won't use the Maven lists to promote it so keep watching the tesla.io site (it's back up) if you're interested. Ultimately to get where I would like to there are some proposals I still need to make for Maven. The core still needs some refactoring to do some of the more advanced things I'd like to do. On Mar 31, 2013, at 9:32 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Hello*. I am curious if there is any progress with this http://tesla.io/tesla/index.html Thank you, Andrei Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
WTF is Tesla?
*Hello*. I am curious if there is any progress with this http://tesla.io/tesla/index.html Thank you, Andrei
Re: Multi-project releases
*Robert:*
I actually relaxed no module nesting requirement. just not tested
well yet.
Thank you,
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Wed 27 Mar 2013 03:59:42 PM CDT
@Andrei,
I've taken a look at your project and I think I understand what you're
trying to do with the maven-cascade-release-plugin. It requires a
non-chained project structure, that's not an option for us.
If these local-aggregators can be under source control and if they can
be layered we have a different challenge.
Stephen, I can give my thoughts a try by forking your plugin, but it's
missing tests.
Robert
Op Mon, 25 Mar 2013 00:50:16 +0100 schreef Andrei Pozolotin
andrei.pozolo...@gmail.com:
got it, thank you.
this is the problem I have solved with my jenkins plugin.
there your release root goes by the name of layout project.
I also go 2 steps further:
1) I require that there are no module declarations in non-root
projects, so all modules and parents are independent.
2) I do recursive release of the whole layout automatically, from any
point in the middle tree, releasing what needs be released.
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org, Robert Scholte
rfscho...@apache.org
Date: Sun 24 Mar 2013 03:59:40 PM CDT
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom and list as modules all the projects you
are working on.
Each of those checked out projects are release roots if they are the
root of a multi-module release.
The local only pom allows within reactor resolution of dependencies so
as soon as you make changes to a module, the rest if the modules in
the reactor can pick them up (by linking in -snapshot dependencies)
Now when it comes time to release from such a local aggregator, you
need to find out which ones you've made changes on and release each
one in turn, perhaps upping within reactor dependencies as you go.
Some of the locale modules could be in git, some in svn, some in HG,
etc. but each release root has all its child modules in the one SCM
root and part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root
modules? (need a better term :-))
* can your envisioned plugin automatically recursively release all
other dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
javascript:_e({}, 'cvml', 'stephen.alan.conno...@gmail.com');
To: Andrei Pozolotin andrei.pozolo...@gmail.com
javascript:_e({}, 'cvml', 'andrei.pozolo...@gmail.com');
Cc: Maven Developers List dev@maven.apache.org
javascript:_e({}, 'cvml', 'dev@maven.apache.org');, Robert
Scholte rfscho...@apache.org javascript:_e({}, 'cvml',
'rfscho...@apache.org');
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom /
monolithic is a wrong approach.
please consider instead start-from-any-module /
from-bottom-up / incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a
release) and then run release on that one.
You then iterate until it says all done or you have released what
you need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh
out all assumptions that currently go into release
as well as to list the use cases people really need. here is
one of my use cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition
releaseRoot (or in my
Re: [ANN] Maven Release Plugin 2.4.1 Released
Robert 1) great, thank you! 2) does it mean 2.4.1 does not blow up with this: http://jira.codehaus.org/browse/SCM-709 ? Andrei Original Message Subject: [ANN] Maven Release Plugin 2.4.1 Released From: Robert Scholte rfscho...@apache.org To: annou...@maven.apache.org, us...@maven.apache.org Cc: dev@maven.apache.org Date: Wed 27 Mar 2013 03:49:46 PM CDT The Apache Maven team is pleased to announce the release of the Maven Release Plugin, version 2.4.1 This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform. http://maven.apache.org/plugins/maven-release-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.4.1/version /plugin Release Notes - Maven 2.x Release Plugin - Version 2.4.1 ** Bug * [MRELEASE-818] - release:perform ignores localCheckout=true * [MRELEASE-819] - preparationGoals parameter supported before version 2.4 ** Improvement * [MRELEASE-820] - Upgrade Plexus Utils dependency ** Task * [MRELEASE-830] - Fall back to SCM-1.7 until git status --porcelain issues are resolved Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi-project releases
Robert, Stephen: 1) from my experience release root / top-to-bottom / monolithic is a wrong approach. please consider instead start-from-any-module / from-bottom-up / incremental approach, as implemented here: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki 2) it would be good to have some wiki page somewhere to flesh out all assumptions that currently go into release as well as to list the use cases people really need. here is one of my use cases: https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 09:42:27 AM CDT Hi Stephen, I've just checked your code. Most interesting is our difference of the definition releaseRoot (or in my case rootProject, I think we mean the same thing with it). If I'm correct you base it on the existence of the scm-section and if it has ever been released (assuming a specific scm comment). MRELEASE-814[1] is probably a good example for which this strategy won't work. I try to base it on the parent/module relationship. Although this looks close related to MRELEASE-516[2] it is actually a complete other issue. The problem I have with MRELEASE-516 is that it's not the plug-and-play behavior you'd like to have, which means that the developer is responsible for checking out separate projects in the right structure. Robert [1] https://jira.codehaus.org/browse/MRELEASE-814 [2] https://jira.codehaus.org/browse/MRELEASE-516 Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multi-project releases
*Robert*
what I am trying to say is that I can not really understand whether
the following make sense
Returns {@code true} if this project has no parent, or it has a
parent but isn't one of its modules
isRootProject( MavenProject project )
unless I see how it will be used by a release-like plugin. well,
never mind, I guess it is too early for questions.
Thank you,
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin
andrei.pozolo...@gmail.com
Cc: Stephen Connolly stephen.alan.conno...@gmail.com
Date: Sun 24 Mar 2013 11:36:04 AM CDT
Andrei,
First of all I'm only talking about the definition of root project,
not about release stuff yet, because this has already consequences for
other plugins as well.
Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You
should see that it does match your start-from-any-module.
If this will be the component for plugins (and maybe other projects)
which contains the actual definitions and transformations, we have a
good place to document it and to refer to.
Robert
[1]
http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39
Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin
andrei.pozolo...@gmail.com:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
2) it would be good to have some wiki page somewhere to flesh out all
assumptions that currently go into release
as well as to list the use cases people really need. here is one of my
use cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition releaseRoot (or
in my case rootProject, I think we mean the same thing with it).
If I'm correct you base it on the existence of the scm-section and
if it has ever been released (assuming a specific scm comment).
MRELEASE-814[1] is probably a good example for which this strategy
won't work.
I try to base it on the parent/module relationship.
Although this looks close related to MRELEASE-516[2] it is actually a
complete other issue.
The problem I have with MRELEASE-516 is that it's not the
plug-and-play behavior you'd like to have,
which means that the developer is responsible for checking out
separate projects in the right structure.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-814
[2] https://jira.codehaus.org/browse/MRELEASE-516
Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
Hey one and all,
So we all know how multiple projects with multiple release roots are a
pain...
Here's some experiments I've been playing with...
Not yet brave enough to have it fire up release:prepare
release:perform on
each release root, nor fire up versions:set on the downstream
projects with
explicit dependencies, nor lather rinse repeat until there is nothing
needing a release...
But even the simple report should be useful, and if anyone has
suggestions
to help improve its recommendations towards getting confidence that
the
automated stuff could work... please give me pull requests.
If this proves useful, I will probably roll it into the release
plugin...
but for now I'll keep it in a holding pattern on github (where it is
not in
a default plugin groupId and hence relocation is less of an issue if
I do
happen to make any releases into central)
$ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots
from an aggregator pom should identify all the release roots and
whether
they might need a release
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multi-project releases
*Robert* unrelated question, may be you can clarify: in the current maven-release-plugin what is the way to release parent w/o releasing its modules? Thank you, Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Stephen Connolly stephen.alan.conno...@gmail.com Date: Sun 24 Mar 2013 11:36:04 AM CDT Andrei, First of all I'm only talking about the definition of root project, not about release stuff yet, because this has already consequences for other plugins as well. Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You should see that it does match your start-from-any-module. If this will be the component for plugins (and maybe other projects) which contains the actual definitions and transformations, we have a good place to document it and to refer to. Robert [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39 Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin andrei.pozolo...@gmail.com: Robert, Stephen: 1) from my experience release root / top-to-bottom / monolithic is a wrong approach. please consider instead start-from-any-module / from-bottom-up / incremental approach, as implemented here: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki 2) it would be good to have some wiki page somewhere to flesh out all assumptions that currently go into release as well as to list the use cases people really need. here is one of my use cases: https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 09:42:27 AM CDT Hi Stephen, I've just checked your code. Most interesting is our difference of the definition releaseRoot (or in my case rootProject, I think we mean the same thing with it). If I'm correct you base it on the existence of the scm-section and if it has ever been released (assuming a specific scm comment). MRELEASE-814[1] is probably a good example for which this strategy won't work. I try to base it on the parent/module relationship. Although this looks close related to MRELEASE-516[2] it is actually a complete other issue. The problem I have with MRELEASE-516 is that it's not the plug-and-play behavior you'd like to have, which means that the developer is responsible for checking out separate projects in the right structure. Robert [1] https://jira.codehaus.org/browse/MRELEASE-814 [2] https://jira.codehaus.org/browse/MRELEASE-516 Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Multi-project releases
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root modules?
(need a better term :-))
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org, Robert Scholte
rfscho...@apache.org
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic
is a wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a release)
and then run release on that one.
You then iterate until it says all done or you have released what you need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh out
all assumptions that currently go into release
as well as to list the use cases people really need. here is one
of my use cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org javascript:_e({},
'cvml', 'rfscho...@apache.org');
To: Maven Developers List dev@maven.apache.org
javascript:_e({}, 'cvml', 'dev@maven.apache.org');
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition
releaseRoot (or in my case rootProject, I think we mean the
same thing with it).
If I'm correct you base it on the existence of the scm-section
and if it has ever been released (assuming a specific scm comment).
MRELEASE-814[1] is probably a good example for which this
strategy won't work.
I try to base it on the parent/module relationship.
Although this looks close related to MRELEASE-516[2] it is
actually a complete other issue.
The problem I have with MRELEASE-516 is that it's not the
plug-and-play behavior you'd like to have,
which means that the developer is responsible for checking out
separate projects in the right structure.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-814
[2] https://jira.codehaus.org/browse/MRELEASE-516
Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com javascript:_e({}, 'cvml',
'stephen.alan.conno...@gmail.com');:
Hey one and all,
So we all know how multiple projects with multiple release roots
are a
pain...
Here's some experiments I've been playing with...
Not yet brave enough to have it fire up release:prepare
release:perform on
each release root, nor fire up versions:set on the downstream
projects with
explicit dependencies, nor lather rinse repeat until there is
nothing
needing a release...
But even the simple report should be useful, and if anyone has
suggestions
to help improve its recommendations towards getting confidence
that the
automated stuff could work... please give me pull requests.
If this proves useful, I will probably roll it into the release
plugin...
but for now I'll keep it in a holding pattern on github (where
it is not in
a default plugin groupId and hence relocation is less of an
issue if I do
happen to make any releases into central)
$ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots
from an aggregator pom should identify all the release roots and
whether
they might need a release
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
javascript:_e({}, 'cvml', 'dev-unsubscr...@maven.apache.org');
For additional commands, e-mail: dev-h...@maven.apache.org
javascript:_e({}, 'cvml', 'dev-h...@maven.apache.org');
--
Sent from my phone
Re: Multi-project releases
I do not mind - children being part of the tag . so what is the way to release a parent w/o its modules? Original Message Subject: Re: Multi-project releases From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 02:30:10 PM CDT That's still going to result in all the children being part of the tag though On Sunday, 24 March 2013, Jeff Jensen wrote: -N Same for other operations to not recurse into children/modules. On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin andrei.pozolo...@gmail.com javascript:; wrote: *Robert* unrelated question, may be you can clarify: in the current maven-release-plugin what is the way to release parent w/o releasing its modules? Thank you, Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Stephen Connolly stephen.alan.conno...@gmail.com Date: Sun 24 Mar 2013 11:36:04 AM CDT Andrei, First of all I'm only talking about the definition of root project, not about release stuff yet, because this has already consequences for other plugins as well. Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You should see that it does match your start-from-any-module. If this will be the component for plugins (and maybe other projects) which contains the actual definitions and transformations, we have a good place to document it and to refer to. Robert [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39 Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin andrei.pozolo...@gmail.com: Robert, Stephen: 1) from my experience release root / top-to-bottom / monolithic is a wrong approach. please consider instead start-from-any-module / from-bottom-up / incremental approach, as implemented here: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki 2) it would be good to have some wiki page somewhere to flesh out all assumptions that currently go into release as well as to list the use cases people really need. here is one of my use cases: https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 09:42:27 AM CDT Hi Stephen, I've just checked your code. Most interesting is our difference of the definition releaseRoot (or in my case rootProject, I think we mean the same thing with it). If I'm correct you base it on the existence of the scm-section and if it has ever been released (assuming a specific scm comment). MRELEASE-814[1] is probably a good example for which this strategy won't work. I try to base it on the parent/module relationship. Although this looks close related to MRELEASE-516[2] it is actually a complete other issue. The problem I have with MRELEASE-516 is that it's not the plug-and-play
Re: Multi-project releases
re: where these required-to-be-released-artifacts live?
by looking into scm tag, and using still one more convention (to be
decided)
where to look locally before attempting independent remote clone.
Original Message
Subject: Re: Multi-project releases
From: Fred Cooke fred.co...@gmail.com
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 03:27:10 PM CDT
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Generalising this out a bit, if it's not a multi-module build we're talking
about, and it's not in SVN (repo per project/module in Git for example),
how will the proposed plugin even find where these
required-to-be-released-artifacts live?
On Sun, Mar 24, 2013 at 9:23 PM, Andrei Pozolotin
andrei.pozolo...@gmail.com wrote:
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root modules?
(need a better term :-))
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org, Robert Scholte
rfscho...@apache.org
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic
is a wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a release)
and then run release on that one.
You then iterate until it says all done or you have released what you
need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh out
all assumptions that currently go into release
as well as to list the use cases people really need. here is one
of my use cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org javascript:_e({},
'cvml', 'rfscho...@apache.org');
To: Maven Developers List dev@maven.apache.org
javascript:_e({}, 'cvml', 'dev@maven.apache.org');
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition
releaseRoot (or in my case rootProject, I think we mean the
same thing with it).
If I'm correct you base it on the existence of the scm-section
and if it has ever been released (assuming a specific scm comment).
MRELEASE-814[1] is probably a good example for which this
strategy won't work.
I try to base it on the parent/module relationship.
Although this looks close related to MRELEASE-516[2] it is
actually a complete other issue.
The problem I have with MRELEASE-516 is that it's not the
plug-and-play behavior you'd like to have,
which means that the developer is responsible for checking out
separate projects in the right structure.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-814
[2] https://jira.codehaus.org/browse/MRELEASE-516
Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com javascript:_e({}, 'cvml',
'stephen.alan.conno...@gmail.com');:
Hey one and all,
So we all know how multiple projects with multiple release roots
are a
pain...
Here's some experiments I've been playing with...
Not yet brave enough to have it fire up release:prepare
release:perform on
each release root, nor fire up versions:set on the downstream
projects with
explicit dependencies, nor lather rinse repeat until there is
nothing
needing a release...
But even the simple report should be useful, and if anyone has
suggestions
to help improve its recommendations towards getting confidence
that the
automated stuff could work... please give me pull requests.
If this proves useful, I will probably roll it into the release
plugin...
but for now I'll keep it in a holding pattern on github (where
it is not in
a default plugin groupId and hence relocation is less of an
issue if I do
happen to make any releases into central
Re: Multi-project releases
got it, thank you.
this is the problem I have solved with my jenkins plugin.
there your release root goes by the name of layout project.
I also go 2 steps further:
1) I require that there are no module declarations in non-root
projects, so all modules and parents are independent.
2) I do recursive release of the whole layout automatically, from any
point in the middle tree, releasing what needs be released.
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Andrei Pozolotin andrei.pozolo...@gmail.com
Cc: Maven Developers List dev@maven.apache.org, Robert Scholte
rfscho...@apache.org
Date: Sun 24 Mar 2013 03:59:40 PM CDT
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom and list as modules all the projects you
are working on.
Each of those checked out projects are release roots if they are the
root of a multi-module release.
The local only pom allows within reactor resolution of dependencies so
as soon as you make changes to a module, the rest if the modules in
the reactor can pick them up (by linking in -snapshot dependencies)
Now when it comes time to release from such a local aggregator, you
need to find out which ones you've made changes on and release each
one in turn, perhaps upping within reactor dependencies as you go.
Some of the locale modules could be in git, some in svn, some in HG,
etc. but each release root has all its child modules in the one SCM
root and part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root
modules? (need a better term :-))
* can your envisioned plugin automatically recursively release all
other dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
javascript:_e({}, 'cvml', 'stephen.alan.conno...@gmail.com');
To: Andrei Pozolotin andrei.pozolo...@gmail.com
javascript:_e({}, 'cvml', 'andrei.pozolo...@gmail.com');
Cc: Maven Developers List dev@maven.apache.org
javascript:_e({}, 'cvml', 'dev@maven.apache.org');, Robert
Scholte rfscho...@apache.org javascript:_e({}, 'cvml',
'rfscho...@apache.org');
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom /
monolithic is a wrong approach.
please consider instead start-from-any-module /
from-bottom-up / incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a
release) and then run release on that one.
You then iterate until it says all done or you have released what
you need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh
out all assumptions that currently go into release
as well as to list the use cases people really need. here is
one of my use cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition
releaseRoot (or in my case rootProject, I think we mean
the same thing with it).
If I'm correct you base it on the existence of the
scm-section and if it has ever been released (assuming a
specific scm comment).
MRELEASE-814[1] is probably a good example for which this
strategy won't work.
I try to base it on the parent/module relationship.
Although this looks close related to MRELEASE-516[2] it is
actually a complete other issue.
The problem I have with MRELEASE-516 is that it's not the
plug-and-play behavior you'd like to have,
which means that the developer is responsible for checking
out separate projects in the right structure.
Robert
[1] https://jira.codehaus.org/browse/MRELEASE-814
[2] https://jira.codehaus.org
Re: Multi-project releases
Jeff got it, thank you. Andrei Original Message Subject: Re: Multi-project releases From: Jeff Jensen jeffjen...@upstairstechnology.com To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 04:00:28 PM CDT I am not aware of a Maven feature to fully ignore them other than -N with the tag caveat. When I've done what you asked, I did not miss a Maven feature to do so. You could temporarily move the module dirs or release the parent in a new location without the modules (-N is still your friend to accomplish that so Maven does not try to process the listed modules). Depending how you release (e.g. manually, via CI job), having a release area separate from the dev area is a good idea anyway to prevent hassles with your dev work (while release plugin prevents releasing with uncommitted work, it's nice to not have to worry about *anything* by performing release in a clean area - a release CI job or separate local checkout). On Sun, Mar 24, 2013 at 3:24 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: I do not mind - children being part of the tag . so what is the way to release a parent w/o its modules? Original Message Subject: Re: Multi-project releases From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 02:30:10 PM CDT That's still going to result in all the children being part of the tag though On Sunday, 24 March 2013, Jeff Jensen wrote: -N Same for other operations to not recurse into children/modules. On Sun, Mar 24, 2013 at 11:55 AM, Andrei Pozolotin andrei.pozolo...@gmail.com javascript:; wrote: *Robert* unrelated question, may be you can clarify: in the current maven-release-plugin what is the way to release parent w/o releasing its modules? Thank you, Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org, Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Stephen Connolly stephen.alan.conno...@gmail.com Date: Sun 24 Mar 2013 11:36:04 AM CDT Andrei, First of all I'm only talking about the definition of root project, not about release stuff yet, because this has already consequences for other plugins as well. Please verify the ProjectUtils.isRootProject( MavenProject ) [1]. You should see that it does match your start-from-any-module. If this will be the component for plugins (and maybe other projects) which contains the actual definitions and transformations, we have a good place to document it and to refer to. Robert [1] http://svn.apache.org/viewvc/maven/shared/trunk/maven-project-utils/src/main/java/org/apache/maven/shared/project/utils/ProjectUtils.java?view=markup#l39 Op Sun, 24 Mar 2013 17:19:14 +0100 schreef Andrei Pozolotin andrei.pozolo...@gmail.com: Robert, Stephen: 1) from my experience release root / top-to-bottom / monolithic is a wrong approach. please consider instead start-from-any-module / from-bottom-up / incremental approach, as implemented here: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki 2) it would be good to have some wiki page somewhere to flesh out all assumptions that currently go into release as well as to list the use cases people really need. here is one of my use cases: https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md Andrei Original Message Subject: Re: Multi-project releases From: Robert Scholte rfscho...@apache.org To: Maven Developers List dev@maven.apache.org Date: Sun 24 Mar 2013 09:42:27 AM CDT Hi Stephen, I've just checked your code. Most interesting is our difference of the definition releaseRoot (or in my case rootProject, I think we mean the same thing with it). If I'm correct you base it on the existence of the scm-section and if it has ever been released (assuming a specific scm comment). MRELEASE-814[1] is probably a good example for which this strategy won't work. I try to base it on the parent/module relationship. Although this looks close related to MRELEASE-516[2] it is actually a complete other issue. The problem I have with MRELEASE-516 is that it's not the plug-and-play
Re: Multi-project releases
is there a way to designate local-aggregator poms as such? say, have
version = 0.0.0, since they are never released.
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 04:44:20 PM CDT
Let me answer my own question: no, it is not the same.
Main difference is that your release-trees are correct, which is not
the case for MRELEASE-516.
The local-aggregator makes the difference.
I still have my doubts if the suggested solution is solid enough.
Maybe it is not the collection of release-roots we need to find, but
only the local-aggregator(s). All its modules are or should be
release-roots by definition.
Can we assume that the root-pom is the only local-aggregator or could
one of its modules also be a local-aggregator?
Can we assume that local-aggregators are never checked in?
In the past I've had good discussions with Fred Cooke about
multi-modules in combination with the maven-release-plugin, so after
sharing some thoughts over the IRC-chat I asked him to join this thread.
Robert
Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte
rfscho...@apache.org:
So you actually are talking about
https://jira.codehaus.org/browse/MRELEASE-516 ?
Robert
Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom and list as modules all the projects you
are
working on.
Each of those checked out projects are release roots if they are
the root
of a multi-module release.
The local only pom allows within reactor resolution of dependencies
so as
soon as you make changes to a module, the rest if the modules in the
reactor can pick them up (by linking in -snapshot dependencies)
Now when it comes time to release from such a local aggregator, you
need to
find out which ones you've made changes on and release each one in
turn,
perhaps upping within reactor dependencies as you go.
Some of the locale modules could be in git, some in svn, some in HG,
etc.
but each release root has all its child modules in the one SCM root and
part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root
modules?
(need a better term :-))
* can your envisioned plugin automatically recursively release all
other
dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly
stephen.alan.conno...@gmail.comjavascript:_e({}, 'cvml',
'stephen.alan.conno...@gmail.com');
To: Andrei Pozolotin andrei.pozolo...@gmail.com javascript:_e({},
'cvml', 'andrei.pozolo...@gmail.com');
Cc: Maven Developers List dev@maven.apache.org javascript:_e({},
'cvml', 'dev@maven.apache.org');, Robert Scholte
rfscho...@apache.orgjavascript:_e({}, 'cvml',
'rfscho...@apache.org');
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic
is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a
release) and
then run release on that one.
You then iterate until it says all done or you have released what you
need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh out all
assumptions that currently go into release
as well as to list the use cases people really need. here is one of
my use
cases:
https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition releaseRoot
(or in
my case rootProject, I think we mean the same thing with it).
If I'm correct you base it on the existence of the scm-section
and if it
has ever been released (assuming a specific scm comment).
MRELEASE-814[1] is probably a good example for which this strategy
won't
work.
I try to base it on the parent/module relationship.
Although this looks close related to MRELEASE-516[2] it is actually a
complete
Re: Multi-project releases
sharing is a key. I suggest you change your assumption to have
aggregation pom be part of the source repo
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 05:55:56 PM CDT
I usually don't check them in, but they can be useful for others, so not a
valid assumption, also I do tend to layer them as the scope if a change
grows.
On Sunday, 24 March 2013, Robert Scholte wrote:
Let me answer my own question: no, it is not the same.
Main difference is that your release-trees are correct, which is not the
case for MRELEASE-516.
The local-aggregator makes the difference.
I still have my doubts if the suggested solution is solid enough.
Maybe it is not the collection of release-roots we need to find, but only
the local-aggregator(s). All its modules are or should be release-roots by
definition.
Can we assume that the root-pom is the only local-aggregator or could one
of its modules also be a local-aggregator?
Can we assume that local-aggregators are never checked in?
In the past I've had good discussions with Fred Cooke about multi-modules
in combination with the maven-release-plugin, so after sharing some
thoughts over the IRC-chat I asked him to join this thread.
Robert
Op Sun, 24 Mar 2013 22:07:51 +0100 schreef Robert Scholte
rfscho...@apache.org:
So you actually are talking about https://jira.codehaus.org/**
browse/MRELEASE-516 https://jira.codehaus.org/browse/MRELEASE-516 ?
Robert
Op Sun, 24 Mar 2013 21:59:40 +0100 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
There is a trick called the local aggregator pom that advanced users
employ.
You create a local only pom and list as modules all the projects you are
working on.
Each of those checked out projects are release roots if they are the root
of a multi-module release.
The local only pom allows within reactor resolution of dependencies so as
soon as you make changes to a module, the rest if the modules in the
reactor can pick them up (by linking in -snapshot dependencies)
Now when it comes time to release from such a local aggregator, you need to
find out which ones you've made changes on and release each one in turn,
perhaps upping within reactor dependencies as you go.
Some of the locale modules could be in git, some in svn, some in HG, etc.
but each release root has all its child modules in the one SCM root and
part of the same tag
That is the problem space I am addressing
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
you are right, I am not: You are not getting my plan :-)
* please define what you mean by release root?
* can release root contain other release roots as modules?
* can I release the release root w/o releasing the release root modules?
(need a better term :-))
* can your envisioned plugin automatically recursively release all other
dependencies moving upward in the reactor dependency tree?
Original Message
Subject: Re: Multi-project releases
From: Stephen Connolly stephen.alan.conno...@gmail.comjavascript:_e({},
'cvml', 'stephen.alan.conno...@gmail.com');
To: Andrei Pozolotin andrei.pozolo...@gmail.com javascript:_e({},
'cvml', 'andrei.pozolo...@gmail.com');
Cc: Maven Developers List dev@maven.apache.org javascript:_e({},
'cvml', 'dev@maven.apache.org');, Robert Scholte
rfscho...@apache.orgjavascript:_e({},
'cvml', 'rfscho...@apache.org');
Date: Sun 24 Mar 2013 02:32:39 PM CDT
On Sunday, 24 March 2013, Andrei Pozolotin wrote:
Robert, Stephen:
1) from my experience release root / top-to-bottom / monolithic is a
wrong approach.
please consider instead start-from-any-module / from-bottom-up /
incremental approach, as implemented here:
https://github.com/barchart/**barchart-jenkins-cascade-**plugin/wikihttps://github.com/barchart/barchart-jenkins-cascade-plugin/wiki
You are not getting my plan.
The plugin I envision will allow picking a release root from the
reactor's set of release roots (suggesting which ones need a release) and
then run release on that one.
You then iterate until it says all done or you have released what you
need
No Big Bang from my PoV
2) it would be good to have some wiki page somewhere to flesh out all
assumptions that currently go into release
as well as to list the use cases people really need. here is one of my use
cases:
https://github.com/barchart/**barchart-jenkins-tester-**
ecosystem/blob/master/readme.**mdhttps://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md
Andrei
Original Message
Subject: Re: Multi-project releases
From: Robert Scholte rfscho...@apache.org
To: Maven Developers List dev@maven.apache.org
Date: Sun 24 Mar 2013 09:42:27 AM CDT
Hi Stephen,
I've just checked your code.
Most interesting is our difference of the definition releaseRoot (or in
my
Re: Multi-project releases
*Stephen** * I made this solution for the problem: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki Please let me know what you think? Thank you, Andrei Original Message Subject: Multi-project releases From: Stephen Connolly stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org Date: Mon 11 Mar 2013 06:50:38 AM CDT Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen
Re: Multi-project releases
*Stephen* 1) great. lets collaborate on your plugin. in the end, I do not care how it works, 100% maven or maven + jenkins. 2) do you know about other initiatives to address this issue? 3) do you know of a way to relax maven-release-plugin so it does not always release children with parent. (i.e. I want to release parent of multi-module project w/o children) Thank you, Andrei Original Message Subject: Re: Multi-project releases From: Stephen Connolly stephen.alan.conno...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: Maven Developers List dev@maven.apache.org Date: Mon 11 Mar 2013 10:32:45 AM CDT Well with my Maven hat on, I don't like that it requires Jenkins nor that it is (most likely from a quick look) using the (IMPO fundamentally broken) Maven Project type for jobs But in essence I envision a Maven plugin with a similar end-goal... just not yet confident enough of my logic for detecting downstream projects. I think my logic for detecting release roots is sound though. (although it probably fails for some of the maven plugins @ asf as they can inherit their SCM even though they are released independently... might be worth checking for some other explicit markers) On 11 March 2013 14:18, Andrei Pozolotin andrei.pozolo...@gmail.com mailto:andrei.pozolo...@gmail.com wrote: *Stephen** * I made this solution for the problem: https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki Please let me know what you think? Thank you, Andrei Original Message Subject: Multi-project releases From: Stephen Connolly stephen.alan.conno...@gmail.com mailto:stephen.alan.conno...@gmail.com To: Maven Developers List dev@maven.apache.org mailto:dev@maven.apache.org Date: Mon 11 Mar 2013 06:50:38 AM CDT Hey one and all, So we all know how multiple projects with multiple release roots are a pain... Here's some experiments I've been playing with... Not yet brave enough to have it fire up release:prepare release:perform on each release root, nor fire up versions:set on the downstream projects with explicit dependencies, nor lather rinse repeat until there is nothing needing a release... But even the simple report should be useful, and if anyone has suggestions to help improve its recommendations towards getting confidence that the automated stuff could work... please give me pull requests. If this proves useful, I will probably roll it into the release plugin... but for now I'll keep it in a holding pattern on github (where it is not in a default plugin groupId and hence relocation is less of an issue if I do happen to make any releases into central) $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots from an aggregator pom should identify all the release roots and whether they might need a release -Stephen
maven-release-plugin : How to better manage cascading releases
Hello, there! I am curious : How to better manage cascading releases for the following use case and what you think about possible solution: # Releasing core bundles and dependent bundles Changing the API of a core bundle for an application requires a rebuild of everything down the line in order to use the new feature. For projects with large numbers of modules (platform, news) this is a very lengthy process of splitting the bundles into dependency phases, then for each phase, releasing a new version of each bundle, updating the next phase's bundles with the newly released versions, and then releasing next phase's bundles, etc, etc. This can be a multiple hour process with Jenkins, compounded by the fact that you can only release one sub-project at a time in a Git repository to avoid push conflicts causing the build to fail. This process occurs much more frequently than I would have originally assumed. Right now I have a bash script that attempts to automate this for news with a combination of the maven release and version plugins, but a better generic solution would be very welcome. *Proposal: Modify Jenkins maven release plugin with the following behavior:* 1. Add a Cascade release dependent projects checkbox on release page 2. After the release completes, look for jobs that are explicitly dependent on the pre-release snapshot version 3. Update these dependent modules with the newly release version, and trigger a Maven release on them as well 4. Failing releases should be skipped, and then trigger a build failure at the very end, with clearly noted messages as to which sub-tree failed so the user can check the logs and manually cascade release the subtree Step c) would need some cycle detection to support scenarios where B and C depend on A, but C also depends on B - both A and B would have to be released before C could be released. # Thank you, Andrei
