>So you must have version 5.1 of project 1-1 depending on version 5.0 of >project 2-1 >and version 5.1 of 2-1 depending on 5.0 of project 1-2?
No, Maven is able to build even when all have the same version. See attached test project. But I would like to prevent users of doing so. >Is that what you are trying to detect? My initial wish is to find automatically which one of module-1 or module-2 I should release first. Bonus is to detect cycles that could prevent the release. >A better way to fix the problem is to use Maven properties to specify the >versions of the project >Then project 2-1 and 1-1 would be version "myproject.version" and would depend >on "myproject.version" of each other. Maybe my previous message was not clear enough: module-1 and module-2 are separate projects with their own versions. They are not always released together, but only when they are integrated in the same "release train". The aggregator project is created artificially in SVN using svn:externals. This allow to do a full build with a single Maven command execution. >Screwing with Maven and writing plug-ins to fix this, is the hard way to solve >a simple problem. I don't think this is a simple problem... ;) ----- Mail original ----- > De : Ron Wheeler <[email protected]> > À : [email protected] > Cc : > Envoyé le : Vendredi 22 Juillet 2011 15h06 > Objet : Re: Maven API: how to get "reactor" order > > So you must have version 5.1 of project 1-1 depending on version 5.0 of > project 2-1 > and version 5.1 of 2-1 depending on 5.0 of project 1-2? > > Is that what you are trying to detect? > > A better way to fix the problem is to use Maven properties to specify > the versions of the project > Then project 2-1 and 1-1 would be version "myproject.version" and > would > depend on "myproject.version" of each other. > Then, when you changed the value of myproject.version, the build would > break at that instant and you could fix it. > > Screwing with Maven and writing plug-ins to fix this, is the hard way to > solve a simple problem. > > Ron > > > On 22/07/2011 8:28 AM, Julien HENRY wrote: >> I have just tested to be sure and it works (Maven 3.0.3): >> >> [INFO] Reactor Summary: >> [INFO] >> [INFO] module-1 .......................................... SUCCESS [0.471s] >> [INFO] module-1-2 ........................................ SUCCESS [2.141s] >> [INFO] module-2 .......................................... SUCCESS [0.007s] >> [INFO] module-2-1 ........................................ SUCCESS [1.116s] >> [INFO] module-1-1 ........................................ SUCCESS [0.751s] >> [INFO] aggregator ........................................ SUCCESS [0.005s] >> [INFO] > ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESS >> >> aggregator/pom.xml >> - module-1/pom.xml >> --- module-1-1/pom.xml >> --- module-1-2/pom.xml >> - module-2/pom.xml >> >> --- module-2-1/pom.xml >> >> 1-1 depends on 2-1 >> 2-1 depends on 1-2 >> >> Anyway I want to detect and prevent this case. In my organisation module-1 > and module-2 would be top level projects that have their own trunk/tag/branch. >> >> Going back to my question: which API can I use to get the reactor order, or > better the reactor graph. >> >> Thanks >> >> Julien >> >> >> ----- Mail original ----- >>> De : Ron Wheeler<[email protected]> >>> À : [email protected] >>> Cc : >>> Envoyé le : Vendredi 22 Juillet 2011 13h07 >>> Objet : Re: Maven API: how to get "reactor" order >>> >>> On 22/07/2011 4:08 AM, Julien HENRY wrote: >>>> Hi, >>>> >>>> Background: I'm trying to develop a release helper tool for > my company. >>> We can't use the maven-release-plugin for several reasons. We have > a notion >>> that is like a "release train" were several projects must be > released >>> at the same time. These projects can be Maven multi-module projects. > These >>> projects can have interdependencies (SNAPSHOT). But of course no > SNAPSHOT >>> dependency is allowed on a project that is not in the release train. >>>> Basically, I'm trying to have a tool to replace the current > manual >>> process: >>>> 1) think about release order according to inter dependencies > (cycles >>> are forbidden) >>>> 2) mvn release:prepare release:perform on first project >>>> 3) update all references to this project (replace SNAPSHOT > version by >>> released version) in all pom of the release train >>>> 4) mvn release:prepare release:perform on second project >>>> 5) update all references to this project (replace SNAPSHOT > version by >>> released version) in all pom of the release train >>>> ... (repeat for all projects of the train) >>>> >>>> >>>> We already have a "tweak" to allow a full build of the > release >>> train with one Maven command. We have a tool that create a Maven > aggregator pom >>> where each submodule is a svn:externals linking to the trunk of each > project. >>>> pom.xml (aggregator) >>>> >>>> project1 -> svn:externals to another_location/project1/trunk >>>> >>>> project2-> svn:externals to another_location/project2/trunk >>>> ... >>>> >>>> projectN-> svn:externals to another_location/projectN/trunk >>>> >>>> Now I try to do step 1 automatically. I want to find release > order based on >>> inter dependencies of my release train. I found the ProjectSorter class > in Maven >>> API, but it seems I have to create a MavenProject for each project, and > each sub >>> module (as it seems this is not recursive). >>>> Is there a better way ? >>>> >>>> In fact the best would be to create a graph of interdependencies. > Because I >>> would also try to detect and prevent this kind of cycle: >>>> project1/submodule1 depend on project2/submodule1 >>>> project2/submodule1 depend on project1/submodule2 >>> Can you explain how this would come about. >>> >>> I do not see how this is possible, You would never get the projects to >>> build as SNAPSHOTs in the first place. >>> >>> Ron >>> >>>> Thanks for any pointer. >>>> >>>> Julien >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
aggregator.tar.gz
Description: GNU Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
