You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Max Carpentier <ma...@gmail.com> on 2011/12/09 14:27:42 UTC
Multi modules release best practices
Hi,
We have a standard maven multi module layout, like this :
project
- - -project-external-api (1.2.1-SNAPSHOT) -> contains wsdl and stubs of
external client needed by the project
- - -project-core (1.2.1-SNAPSHOT) -> core of the project
- - -project-ws (1.2.1-SNAPSHOT) -> webapp of the project
- - -project-ws-api (1.2.1-SNAPSHOT) -> wsdl exposed by the project
- pom.xml (1.2.1-SNAPSHOT)
the root pom.xml references the 3 modules :
<modules>
<module>project-external-api</module>
<module>project-core</module>
<module>project-ws-api</module>
<module>project-ws</module>
</modules>
We would like to make a new release of the project, but there's a problem
: project-external-api and and project-ws-api haven't changed since the
last release...
what should we do ?
1) mvn release on the root pom.xml, that will tag and release the full
directory, even if some projects haven't changed
2) mvn release only on the project-ws pom and project-core...but we will
first have to manually change the dependencies versions
3) change the modules of the root pom.xml, so that it will only build and
release project-ws and project-core...but we will first have to manually
change the dependencies versions, and the project-external-api and
project-ws-api will have their parents still pointing to the 1.2.1-SNAPHSOT
root pom.xml
any other idea ?
What are the best practices for this kind of situation ? have we missed
something in maven multi modules setup ?
Thanxs for your help
Max
Re: Multi modules release best practices
Posted by David Hoffer <dh...@gmail.com>.
General practice I follow is...group modules in your multi-module project
that you do want to version as a group, move things that don't need to be
versions as often (or more often) to a separate project and add as
dependency.
-Dave
On Fri, Dec 9, 2011 at 6:27 AM, Max Carpentier <ma...@gmail.com> wrote:
> Hi,
>
> We have a standard maven multi module layout, like this :
>
> project
> - - -project-external-api (1.2.1-SNAPSHOT) -> contains wsdl and stubs of
> external client needed by the project
> - - -project-core (1.2.1-SNAPSHOT) -> core of the project
> - - -project-ws (1.2.1-SNAPSHOT) -> webapp of the project
> - - -project-ws-api (1.2.1-SNAPSHOT) -> wsdl exposed by the project
> - pom.xml (1.2.1-SNAPSHOT)
>
> the root pom.xml references the 3 modules :
> <modules>
> <module>project-external-api</module>
> <module>project-core</module>
> <module>project-ws-api</module>
> <module>project-ws</module>
> </modules>
>
> We would like to make a new release of the project, but there's a problem
> : project-external-api and and project-ws-api haven't changed since the
> last release...
> what should we do ?
>
> 1) mvn release on the root pom.xml, that will tag and release the full
> directory, even if some projects haven't changed
> 2) mvn release only on the project-ws pom and project-core...but we will
> first have to manually change the dependencies versions
> 3) change the modules of the root pom.xml, so that it will only build and
> release project-ws and project-core...but we will first have to manually
> change the dependencies versions, and the project-external-api and
> project-ws-api will have their parents still pointing to the 1.2.1-SNAPHSOT
> root pom.xml
>
> any other idea ?
> What are the best practices for this kind of situation ? have we missed
> something in maven multi modules setup ?
> Thanxs for your help
>
> Max
>
Re: Multi modules release best practices
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 12/12/2011 9:33 AM, Max Carpentier wrote:
> Thanxs Ron,
> In fact our project is an old mulitple individual jars project (we had like
> ~40 jars), but eclipse had an hard time compiling/refreshing workspace so
> we decided to merge a lot of projects.
There is no need for Eclipse to have any more than 1 or 2 projects open
at a time and we hardly ever have anyone who has more than a few modules
even closed in the workspace.
Close projects that you are not actively editing.
Delete projects that you are not referencing regularly.
The best way to use Eclipse is to check out projects as you work on
them, work on them, publish, commit and delete.
Build your jars and put them in Nexus (or some other Repo) as they are
released for testing (SNAPSHOTS) or released as finished versions.
Keep your projects small and functionally organized.
Think about your stuff the way Apache does their projects. Lots of
projects, each with a single purpose.
Don't mix your messaging utilities with your reporting functions. Don't
put any visualization in your messaging utility core.
Don't be afraid to separate your API into separate libraries along
functional lines with layers of abstraction.
Think SOA even if you can not fully convert the project at once. At
least start to move in that direction.
You will end up with more projects but they will be easier to
understand, easier to debug, faster to build and more likely to turn
into stable libraries that don't change during maintenance cycles and
only require minor tweaking and testing during major development releases.
Check-in the project often to your SCM as you work on it with proper
tagging and branching strategies.
Beat the crap out of people who put stuff in the SCM without proper
comments. Give you staff the same pleasure when you forget.
Let Maven and Eclipse get what they need from the repo not from the
Workspace.
We generally suppress Maven's search of the Workspace for dependencies
to ensure that it is building with the latest published SNAPSHOT rather
than some possibly leftover Eclipse project that the person downloaded a
week ago.
Ron
> Anyways thanxs for your anwser, i think a mix of multi module projects and
> individual projects may be the most acceptable solution to our problem.
> A short term solution is also to individually release projects (solution 2
> in my question)
>
> Regards,
> Max
>
>
> On Mon, Dec 12, 2011 at 2:26 PM, Ron Wheeler<rwheeler@artifact-software.com
>> wrote:
>> We did exactly what you want to do.
>> We built a learning management system that includes more than 70 jar and
>> war files.
>> We started out changing every version with each release but soon reached a
>> point where most of the modules did not change as we improved the
>> modularity of the system and as maintenance and new portlets became the
>> cause of the majority of the new releases so even a minor release version
>> actually only involved the core, some web services and a few modules.
>>
>> We moved to individually versioned projects with a shared parent.
>> At the beginning of a development cycle we document the versions of each
>> project that makes up the application.
>> We have to be careful about upward compatibility but other than that, it
>> works very well.
>>
>> We do not use CI.
>> It seems to be more trouble than it is worth and I am suspicious that it
>> can be used as a substitute for thinking or proper testing.
>> We are also a small group so the sense of personal responsibility is high
>> and communication is not a huge problem.
>>
>> We also use a lot of `provided` scope which keeps the artifacts small and
>> free of third party libraries or our own libraries so that the 1.10 war has
>> nothing in it that will conflict with any 1.11 jar file that holds the api
>> or core or utilities.
>>
>> I hope that our experience is useful to you.
>>
>> Ron
>>
>>
>>
>> On 12/12/2011 5:23 AM, Karl Heinz Marbaise wrote:
>>
>>> Hi,
>>>
>>> Well, that's the problem..we don't want to release a new version of
>>>> unchanged projects because it will confuse our users, especially for the
>>>> api projects...
>>>> maybe we did wrong using this kind of layout ?
>>>> Thanxs for your answers anyways
>>>>
>>> In this case you should separate out the api module and use this as a
>>> dependency in your project and release it separately...
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Multi modules release best practices
Posted by Max Carpentier <ma...@gmail.com>.
Thanxs Ron,
In fact our project is an old mulitple individual jars project (we had like
~40 jars), but eclipse had an hard time compiling/refreshing workspace so
we decided to merge a lot of projects.
Anyways thanxs for your anwser, i think a mix of multi module projects and
individual projects may be the most acceptable solution to our problem.
A short term solution is also to individually release projects (solution 2
in my question)
Regards,
Max
On Mon, Dec 12, 2011 at 2:26 PM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> We did exactly what you want to do.
> We built a learning management system that includes more than 70 jar and
> war files.
> We started out changing every version with each release but soon reached a
> point where most of the modules did not change as we improved the
> modularity of the system and as maintenance and new portlets became the
> cause of the majority of the new releases so even a minor release version
> actually only involved the core, some web services and a few modules.
>
> We moved to individually versioned projects with a shared parent.
> At the beginning of a development cycle we document the versions of each
> project that makes up the application.
> We have to be careful about upward compatibility but other than that, it
> works very well.
>
> We do not use CI.
> It seems to be more trouble than it is worth and I am suspicious that it
> can be used as a substitute for thinking or proper testing.
> We are also a small group so the sense of personal responsibility is high
> and communication is not a huge problem.
>
> We also use a lot of `provided` scope which keeps the artifacts small and
> free of third party libraries or our own libraries so that the 1.10 war has
> nothing in it that will conflict with any 1.11 jar file that holds the api
> or core or utilities.
>
> I hope that our experience is useful to you.
>
> Ron
>
>
>
> On 12/12/2011 5:23 AM, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> Well, that's the problem..we don't want to release a new version of
>>> unchanged projects because it will confuse our users, especially for the
>>> api projects...
>>> maybe we did wrong using this kind of layout ?
>>> Thanxs for your answers anyways
>>>
>> In this case you should separate out the api module and use this as a
>> dependency in your project and release it separately...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Multi modules release best practices
Posted by Ron Wheeler <rw...@artifact-software.com>.
We did exactly what you want to do.
We built a learning management system that includes more than 70 jar and
war files.
We started out changing every version with each release but soon reached
a point where most of the modules did not change as we improved the
modularity of the system and as maintenance and new portlets became the
cause of the majority of the new releases so even a minor release
version actually only involved the core, some web services and a few
modules.
We moved to individually versioned projects with a shared parent.
At the beginning of a development cycle we document the versions of
each project that makes up the application.
We have to be careful about upward compatibility but other than that, it
works very well.
We do not use CI.
It seems to be more trouble than it is worth and I am suspicious that it
can be used as a substitute for thinking or proper testing.
We are also a small group so the sense of personal responsibility is
high and communication is not a huge problem.
We also use a lot of `provided` scope which keeps the artifacts small
and free of third party libraries or our own libraries so that the 1.10
war has nothing in it that will conflict with any 1.11 jar file that
holds the api or core or utilities.
I hope that our experience is useful to you.
Ron
On 12/12/2011 5:23 AM, Karl Heinz Marbaise wrote:
> Hi,
>
>> Well, that's the problem..we don't want to release a new version of
>> unchanged projects because it will confuse our users, especially for the
>> api projects...
>> maybe we did wrong using this kind of layout ?
>> Thanxs for your answers anyways
> In this case you should separate out the api module and use this as a
> dependency in your project and release it separately...
>
> Kind regards
> Karl Heinz Marbaise
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Multi modules release best practices
Posted by Max Carpentier <ma...@gmail.com>.
Yes, indeed that can be a long term solution to this problem if we see that
a few projects don't change too much in the next releases/months.
Regards,
Max
On Mon, Dec 12, 2011 at 11:23 AM, Karl Heinz Marbaise <kh...@gmx.de>wrote:
> Hi,
>
>
> Well, that's the problem..we don't want to release a new version of
>> unchanged projects because it will confuse our users, especially for the
>> api projects...
>> maybe we did wrong using this kind of layout ?
>> Thanxs for your answers anyways
>>
> In this case you should separate out the api module and use this as a
> dependency in your project and release it separately...
>
>
> Kind regards
> Karl Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
> Hauptstrasse 177 USt.IdNr: DE191347579
> 52146 Würselen http://www.soebes.de
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Multi modules release best practices
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
> Well, that's the problem..we don't want to release a new version of
> unchanged projects because it will confuse our users, especially for the
> api projects...
> maybe we did wrong using this kind of layout ?
> Thanxs for your answers anyways
In this case you should separate out the api module and use this as a
dependency in your project and release it separately...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi modules release best practices
Posted by Max Carpentier <ma...@gmail.com>.
Well, that's the problem..we don't want to release a new version of
unchanged projects because it will confuse our users, especially for the
api projects...
maybe we did wrong using this kind of layout ?
Thanxs for your answers anyways
Max
On Sat, Dec 10, 2011 at 9:09 PM, Anders Hammar <an...@hammar.net> wrote:
> > In a multi-module situation it can of course happen that you have modules
> > which don't change between two or more releases....
> > Is that a problem ? No it is not...
>
> Well, it depends on your configuration management view on this. If I
> wear a CM hat, I think that the version of the API should not change
> if there is no change to the API. However, that would make your Maven
> projects setup slightly more complicated as you can't keep everything
> as one multi-module build. If you have a more relaxed view of this,
> you therefore release everything together (which is what most open
> source projects do). But, IMHO, that could confuse your users as a new
> version of an API suggests a change.
>
> /Anders
>
> >
> > The idea with multi-module builds to have a single point where you can
> > release a consistent state of your project...
> >
> > I'm using multi modules build very often and of course be faced with the
> > situation where only a small part of the project has been changed (only
> 1 or
> > 2 modules out of 10-15) ...but i will release them all....with a new
> version
> > (as mvn release will handle for me).
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -----
> > Kind regards
> > Karl Heinz Marbaise
> > ----
> > http://www.soebes.de
> > http://www.skmwiki.de
> > http://supose.org/wiki/supose
> > --
> > View this message in context:
> http://maven.40175.n5.nabble.com/Multi-modules-release-best-practices-tp5061771p5061858.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: Multi modules release best practices
Posted by Anders Hammar <an...@hammar.net>.
> In a multi-module situation it can of course happen that you have modules
> which don't change between two or more releases....
> Is that a problem ? No it is not...
Well, it depends on your configuration management view on this. If I
wear a CM hat, I think that the version of the API should not change
if there is no change to the API. However, that would make your Maven
projects setup slightly more complicated as you can't keep everything
as one multi-module build. If you have a more relaxed view of this,
you therefore release everything together (which is what most open
source projects do). But, IMHO, that could confuse your users as a new
version of an API suggests a change.
/Anders
>
> The idea with multi-module builds to have a single point where you can
> release a consistent state of your project...
>
> I'm using multi modules build very often and of course be faced with the
> situation where only a small part of the project has been changed (only 1 or
> 2 modules out of 10-15) ...but i will release them all....with a new version
> (as mvn release will handle for me).
>
> Kind regards
> Karl Heinz Marbaise
>
> -----
> Kind regards
> Karl Heinz Marbaise
> ----
> http://www.soebes.de
> http://www.skmwiki.de
> http://supose.org/wiki/supose
> --
> View this message in context: http://maven.40175.n5.nabble.com/Multi-modules-release-best-practices-tp5061771p5061858.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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
Re: Multi modules release best practices
Posted by Karl Heinz Marbaise <ka...@soebes.de>.
Hi,
Max Carpentier wrote
>
> We would like to make a new release of the project, but there's a problem
> : project-external-api and and project-ws-api haven't changed since the
> last release...
> what should we do ?
>
Very short answer: So what? Just make the release and it's done.
Is it a problem in your version control to tag a directory structure ?
Max Carpentier wrote
>
> ...
> any other idea ?
> What are the best practices for this kind of situation ? have we missed
> something in maven multi modules setup ?
>
In a multi-module situation it can of course happen that you have modules
which don't change between two or more releases....
Is that a problem ? No it is not...
The idea with multi-module builds to have a single point where you can
release a consistent state of your project...
I'm using multi modules build very often and of course be faced with the
situation where only a small part of the project has been changed (only 1 or
2 modules out of 10-15) ...but i will release them all....with a new version
(as mvn release will handle for me).
Kind regards
Karl Heinz Marbaise
-----
Kind regards
Karl Heinz Marbaise
----
http://www.soebes.de
http://www.skmwiki.de
http://supose.org/wiki/supose
--
View this message in context: http://maven.40175.n5.nabble.com/Multi-modules-release-best-practices-tp5061771p5061858.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Multi modules release best practices
Posted by Cem Koc <ce...@gmail.com>.
We were almost in same situation and after deeply analyzing projects such as
Jetty, Camel etc. concluded that the best practice for us releasing all of
the modules at one time even if some projects haven't changed. At first it
seems that there is nothing changed but it has very crucial side effects.
Tests. Each release should increase the safety level of the library despite
of unchanging. The key point here is correct classification. If you feel
that all of your libraries are tightly coupled to each other, I feel that
you are in the correct way to release all of them at one time. However
separating API modules to another project seems more reasonable for me in
order to prevent confusion for your users.
--
View this message in context: http://maven.40175.n5.nabble.com/Multi-modules-release-best-practices-tp5061771p5070889.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org