maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Maven API: how to get "reactor" order
Date Fri, 22 Jul 2011 15:01:05 GMT
On 22/07/2011 10:33 AM, Julien HENRY wrote:
>> 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.
How can maven build project 1-1 when project 2-1 does not exist?
How can maven build project 2-1 when project 1-1 does not exist?

Of course, once you trick maven into doing the first build, it will 
succeed after that.

The point is to make it harder for someone to build in cyclical 
dependencies and force them to split out the code that is causing the 
problem.

Ultimately, this is a bad architectural decision that someone made and 
no one has corrected.

It should not happen in the first place.

>
>> 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.
 From what I know of Maven, in a properly constructed set of projects, 
Maven should be able to do this itself.
> Bonus is to detect cycles that could prevent the release.
This should be a one-time operation.
Once you fix the problem it should stay fixed.
>
>> 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.
If the parent POM carries the versions, then you can keep them in synch 
and prevent the first build of the poorly constructed projects.

We have built some pretty large applications but we always (eventually) 
got our utility routines into the right structure so that separate 
projects that shared code were able to be built correctly.
In each project we had a core and API module that had to be built first 
as well as utility projects such as our messaging subsystem or our 
portal facades or JSF utilities that were separately controlled/versioned.
We did not allow circular dependencies.
If you want to do things in a single command, build a batch script that 
calls Maven in the right order.

>> 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... ;)
You may want to hire Sonatype or one of the real Maven experts in the 
forum to do some consulting for you, in that case.



>
>
> ----- Mail original -----
>> De : Ron Wheeler<rwheeler@artifact-software.com>
>> À : users@maven.apache.org
>> 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<rwheeler@artifact-software.com>
>>>>   À : users@maven.apache.org
>>>>   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: users-unsubscribe@maven.apache.org
>>>>>     For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>   ---------------------------------------------------------------------
>>>>   To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>   For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>   ---------------------------------------------------------------------
>>>   To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>   For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message