You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Andrew Close <ac...@gmail.com> on 2010/06/01 16:09:40 UTC
Versioning of company SuperPOM
the organization that i currently work at is in the process of
updating our POM hierarchy. we're moving to a common company SuperPOM
which everyone will inherit from as opposed to the handful of
semi-SuperPOMs we have now. :) we currently have over 300 artifacts
that are downstream of this architecture and we'll be rolling this
model out in phases since it would be very difficult to schedule a
release with all of our artifacts at once. we're hoping to take
advantage of the common plugin management and dependency management to
keep our third party dependencies more manageable. this sounds good,
but i'm guessing we'll get halfway through the rollout and realize
that we need to make some changes to the SuperPOM, which entails a new
version, which means updating all the downstream artifacts so they
inherit from the new parent. this could become a very vicious cycle.
so, the question i have is how do other large organizations with this
model handle versioning their SuperPOMs? do you actually update the
version and then go through all the artifacts and update their parent
block? or do you keep the SuperPOM at a static version (probably not
a very good idea) so all updates are handled dynamically?
is there a way to enforce which version of the SuperPOM should be
used? or at least warn the developer that there is a newer version of
the SuperPOM that they should be inheriting from?
--
Andrew Close
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Versioning of company SuperPOM
Posted by Andrew Close <ac...@gmail.com>.
On Tue, Jun 1, 2010 at 9:18 AM, Stephen Connolly
<st...@gmail.com> wrote:
> We just use the latest version at the time of the downstream project's
> release.
>
> using
> mvn versions:update-parent
> helps make this easy.
thank you Stephen, we'll give this a try.
--
Andrew Close
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Versioning of company SuperPOM
Posted by Stephen Connolly <st...@gmail.com>.
We just use the latest version at the time of the downstream project's
release.
using
mvn versions:update-parent
helps make this easy.
On 1 June 2010 15:09, Andrew Close <ac...@gmail.com> wrote:
> the organization that i currently work at is in the process of
> updating our POM hierarchy. we're moving to a common company SuperPOM
> which everyone will inherit from as opposed to the handful of
> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
> that are downstream of this architecture and we'll be rolling this
> model out in phases since it would be very difficult to schedule a
> release with all of our artifacts at once. we're hoping to take
> advantage of the common plugin management and dependency management to
> keep our third party dependencies more manageable. this sounds good,
> but i'm guessing we'll get halfway through the rollout and realize
> that we need to make some changes to the SuperPOM, which entails a new
> version, which means updating all the downstream artifacts so they
> inherit from the new parent. this could become a very vicious cycle.
>
> so, the question i have is how do other large organizations with this
> model handle versioning their SuperPOMs? do you actually update the
> version and then go through all the artifacts and update their parent
> block? or do you keep the SuperPOM at a static version (probably not
> a very good idea) so all updates are handled dynamically?
> is there a way to enforce which version of the SuperPOM should be
> used? or at least warn the developer that there is a newer version of
> the SuperPOM that they should be inheriting from?
>
>
> --
> Andrew Close
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Versioning of company SuperPOM
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/06/2010 12:37 PM, Justin Edelson wrote:
> On 6/1/10 12:02 PM, Ron Wheeler wrote:
>
>> On 01/06/2010 11:30 AM, Justin Edelson wrote:
>>
>>> On 6/1/10 11:24 AM, Ron Wheeler wrote:
>>>
>>>
>>>> The documentation is a bit light.
>>>>
>>>> Are there any particular things to watch out for in the release plug-in?
>>>>
>>>>
>>> 1) Know how to back out of a failed release.
>>>
>>>
>> Any hints about how we get to know this?
>>
> Know what your release process does and know how to reverse it. For
> example, the release plugin will create a tag in SCM. Some organizations
> disallow the removal of tags by regular users, so if a release fails, an
> admin may need to remove the tag OR a new tag name must be used.
>
Ok.
>
>>> 2) Try not to have failed releases.
>>>
>>>
>>>
>> We do what we can!
>>
>>
>>>> Is it smart enough to fix the version of the parent pom in the
>>>> project pom?
>>>>
>>>>
>>> If fix == update, then no, the release plugin won't do this by default.
>>> You can, however, add this by setting the preparation goals to include
>>> versions:update-parent and scm:checkin"
>>>
>>>
>>>
>> OK. Will look up how to do this.
>>
>>>> What about authentication to the SCM?
>>>>
>>>>
>>> Not sure what you mean here.
>>>
>>>
>>>
>> Our subversion requires usernames and passwords for each person.
>>
> If the credentials in the Subversion credentials cache are wrong, then
> the release preparation will fail.
>
>
We always use Eclipse to access our svn so I guess that I will have to
do some digging here to see where Maven expects to find the credentials..
>>>> We have 60+ modules in a portlet application and it would be nice to
>>>> have a batch job that produced a release from a SNAPSHOT.
>>>>
>>>>
>>> The release plugin can be used in multi-module scenarios.
>>>
>>>
>>>
>> Sounds like a real time-saver.
>>
> It is, but as someone else noted, it does require testing. Your first
> release should NOT be 60 projects.
>
>
You mean we can't apply our "No guts - no glory" guidelines.
Thanks for your help Ron
> Justin
>
>
>
>> Thanks
>> Ron
>>
>>> Justin
>>>
>>>
>>>
>>>> Ron
>>>>
>>>>
>>>> On 01/06/2010 10:15 AM, Shan Syed wrote:
>>>>
>>>>
>>>>> I don't fully understand your scenario, but do you use the "release"
>>>>> plugin?
>>>>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>>>>
>>>>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>>>>> plugin
>>>>> will help you make a release version out of it without having to edit
>>>>> POMs
>>>>> manually
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> the organization that i currently work at is in the process of
>>>>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>>>>> which everyone will inherit from as opposed to the handful of
>>>>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>>>>> that are downstream of this architecture and we'll be rolling this
>>>>>> model out in phases since it would be very difficult to schedule a
>>>>>> release with all of our artifacts at once. we're hoping to take
>>>>>> advantage of the common plugin management and dependency management to
>>>>>> keep our third party dependencies more manageable. this sounds good,
>>>>>> but i'm guessing we'll get halfway through the rollout and realize
>>>>>> that we need to make some changes to the SuperPOM, which entails a new
>>>>>> version, which means updating all the downstream artifacts so they
>>>>>> inherit from the new parent. this could become a very vicious cycle.
>>>>>>
>>>>>> so, the question i have is how do other large organizations with this
>>>>>> model handle versioning their SuperPOMs? do you actually update the
>>>>>> version and then go through all the artifacts and update their parent
>>>>>> block? or do you keep the SuperPOM at a static version (probably not
>>>>>> a very good idea) so all updates are handled dynamically?
>>>>>> is there a way to enforce which version of the SuperPOM should be
>>>>>> used? or at least warn the developer that there is a newer version of
>>>>>> the SuperPOM that they should be inheriting from?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Andrew Close
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Versioning of company SuperPOM
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/06/2010 1:01 PM, Benson Margulies wrote:
> I would suggest that it is unlikely that all of your projects will, at
> all times, consume the same version of the super-pom. If a project is
> stable and not being changed, do you really want to force it to take a
> new version of a dependency? Or would it be better to leave it alone
> until the next development iteration, and move to a new super-pom
> version at that point.
>
Our super pom does not include any dependency information but it does
provide
1) the basic plug-in versions
2) the project version number
3) the Nexus repositories for deployment.
> This is, in a sense, an illustration of something that Maven doesn't
> help you with. There are two reasons to put a versioned dependency
> into a super pom. 1: To enforce consistency across all the children:
> 2: to set the baseline default from which some things may diverge for
> various reasons. If you are confident that your dependencies are all
> maintained by people who are good at backward compatibility, to can
> stick with option 2 most of the time. If not, and you have a mixture,
> you may find yourself spending a lot of time moving to new super-pom
> versions.
>
>
We build libraries of dependencies that either
1) group third party libraries into families such as the
spring-hibernate-mysql-tomcat library or the CXF library or the JSF
library that makes sure that everyone uses the right versions of the
framework
or
2) groups our own shared dependency code into manageable chunks
These master libraries are versioned with the "project version" which is
propagated to the individual webapp projects from the parent pom.
This means that individual webapps get a "project version" from their
parent and have only 3-5 dependencies which are on the "project version"
of the shared libraries.
The individual webapps POMs have only 2 things to change to go from one
version to another - the parent version and their own version (which
should be the same as the parent)
This is true unless their code radically changes and they need to add a
dependency on a library that they did not need earlier.
The library poms carry the versions of dependencies of their components
so that we only have to change 1 place to upgrade the version of Spring
even though it is used in all the applications.
The library poms also produce a jar with dependencies so that we only
have 10 or so files to deploy to get 60-80 individual libraries into play.
Upgrading or adding a new dependency to a library does not affect the
parent pom or any of the application poms.
This makes us be a bit disciplined about versions of dependent libraries.
> As for the release plugin, we're using it, but I endorse the message
> from the p4 user. It automates a particular release workflow. If you
> use svn, and if your desired workflow matches it, it's great. If
> either is not so true, not so much. However, it's important to keep in
> mind that it is *just* automation of a series of well-documented
> steps, and it's not all that painful to take disaggregate them. In my
> personal experience, the entire SCM integration is on the weak side
> for P4, so if you use that, you might feel inclined to do what I did
> and write your own maven plugin for P4 tasks outside the SCM
> framework.
>
>
We will watch for this. Thanks.
Ron
> On Tue, Jun 1, 2010 at 12:37 PM, Justin Edelson<ju...@gmail.com> wrote:
>
>> On 6/1/10 12:02 PM, Ron Wheeler wrote:
>>
>>> On 01/06/2010 11:30 AM, Justin Edelson wrote:
>>>
>>>> On 6/1/10 11:24 AM, Ron Wheeler wrote:
>>>>
>>>>
>>>>> The documentation is a bit light.
>>>>>
>>>>> Are there any particular things to watch out for in the release plug-in?
>>>>>
>>>>>
>>>> 1) Know how to back out of a failed release.
>>>>
>>>>
>>> Any hints about how we get to know this?
>>>
>> Know what your release process does and know how to reverse it. For
>> example, the release plugin will create a tag in SCM. Some organizations
>> disallow the removal of tags by regular users, so if a release fails, an
>> admin may need to remove the tag OR a new tag name must be used.
>>
>>
>>>> 2) Try not to have failed releases.
>>>>
>>>>
>>>>
>>> We do what we can!
>>>
>>>
>>>>> Is it smart enough to fix the version of the parent pom in the
>>>>> project pom?
>>>>>
>>>>>
>>>> If fix == update, then no, the release plugin won't do this by default.
>>>> You can, however, add this by setting the preparation goals to include
>>>> versions:update-parent and scm:checkin"
>>>>
>>>>
>>>>
>>> OK. Will look up how to do this.
>>>
>>>>> What about authentication to the SCM?
>>>>>
>>>>>
>>>> Not sure what you mean here.
>>>>
>>>>
>>>>
>>> Our subversion requires usernames and passwords for each person.
>>>
>> If the credentials in the Subversion credentials cache are wrong, then
>> the release preparation will fail.
>>
>>
>>>>> We have 60+ modules in a portlet application and it would be nice to
>>>>> have a batch job that produced a release from a SNAPSHOT.
>>>>>
>>>>>
>>>> The release plugin can be used in multi-module scenarios.
>>>>
>>>>
>>>>
>>> Sounds like a real time-saver.
>>>
>> It is, but as someone else noted, it does require testing. Your first
>> release should NOT be 60 projects.
>>
>> Justin
>>
>>
>>
>>> Thanks
>>> Ron
>>>
>>>> Justin
>>>>
>>>>
>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> On 01/06/2010 10:15 AM, Shan Syed wrote:
>>>>>
>>>>>
>>>>>> I don't fully understand your scenario, but do you use the "release"
>>>>>> plugin?
>>>>>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>>>>>
>>>>>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>>>>>> plugin
>>>>>> will help you make a release version out of it without having to edit
>>>>>> POMs
>>>>>> manually
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> the organization that i currently work at is in the process of
>>>>>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>>>>>> which everyone will inherit from as opposed to the handful of
>>>>>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>>>>>> that are downstream of this architecture and we'll be rolling this
>>>>>>> model out in phases since it would be very difficult to schedule a
>>>>>>> release with all of our artifacts at once. we're hoping to take
>>>>>>> advantage of the common plugin management and dependency management to
>>>>>>> keep our third party dependencies more manageable. this sounds good,
>>>>>>> but i'm guessing we'll get halfway through the rollout and realize
>>>>>>> that we need to make some changes to the SuperPOM, which entails a new
>>>>>>> version, which means updating all the downstream artifacts so they
>>>>>>> inherit from the new parent. this could become a very vicious cycle.
>>>>>>>
>>>>>>> so, the question i have is how do other large organizations with this
>>>>>>> model handle versioning their SuperPOMs? do you actually update the
>>>>>>> version and then go through all the artifacts and update their parent
>>>>>>> block? or do you keep the SuperPOM at a static version (probably not
>>>>>>> a very good idea) so all updates are handled dynamically?
>>>>>>> is there a way to enforce which version of the SuperPOM should be
>>>>>>> used? or at least warn the developer that there is a newer version of
>>>>>>> the SuperPOM that they should be inheriting from?
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Andrew Close
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>
>>
>>
> ---------------------------------------------------------------------
> 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: Versioning of company SuperPOM
Posted by Benson Margulies <bi...@gmail.com>.
I would suggest that it is unlikely that all of your projects will, at
all times, consume the same version of the super-pom. If a project is
stable and not being changed, do you really want to force it to take a
new version of a dependency? Or would it be better to leave it alone
until the next development iteration, and move to a new super-pom
version at that point.
This is, in a sense, an illustration of something that Maven doesn't
help you with. There are two reasons to put a versioned dependency
into a super pom. 1: To enforce consistency across all the children:
2: to set the baseline default from which some things may diverge for
various reasons. If you are confident that your dependencies are all
maintained by people who are good at backward compatibility, to can
stick with option 2 most of the time. If not, and you have a mixture,
you may find yourself spending a lot of time moving to new super-pom
versions.
As for the release plugin, we're using it, but I endorse the message
from the p4 user. It automates a particular release workflow. If you
use svn, and if your desired workflow matches it, it's great. If
either is not so true, not so much. However, it's important to keep in
mind that it is *just* automation of a series of well-documented
steps, and it's not all that painful to take disaggregate them. In my
personal experience, the entire SCM integration is on the weak side
for P4, so if you use that, you might feel inclined to do what I did
and write your own maven plugin for P4 tasks outside the SCM
framework.
On Tue, Jun 1, 2010 at 12:37 PM, Justin Edelson <ju...@gmail.com> wrote:
> On 6/1/10 12:02 PM, Ron Wheeler wrote:
>> On 01/06/2010 11:30 AM, Justin Edelson wrote:
>>> On 6/1/10 11:24 AM, Ron Wheeler wrote:
>>>
>>>> The documentation is a bit light.
>>>>
>>>> Are there any particular things to watch out for in the release plug-in?
>>>>
>>> 1) Know how to back out of a failed release.
>>>
>> Any hints about how we get to know this?
> Know what your release process does and know how to reverse it. For
> example, the release plugin will create a tag in SCM. Some organizations
> disallow the removal of tags by regular users, so if a release fails, an
> admin may need to remove the tag OR a new tag name must be used.
>
>>> 2) Try not to have failed releases.
>>>
>>>
>> We do what we can!
>>
>>>> Is it smart enough to fix the version of the parent pom in the
>>>> project pom?
>>>>
>>> If fix == update, then no, the release plugin won't do this by default.
>>> You can, however, add this by setting the preparation goals to include
>>> versions:update-parent and scm:checkin"
>>>
>>>
>> OK. Will look up how to do this.
>>>> What about authentication to the SCM?
>>>>
>>> Not sure what you mean here.
>>>
>>>
>> Our subversion requires usernames and passwords for each person.
> If the credentials in the Subversion credentials cache are wrong, then
> the release preparation will fail.
>
>>>>
>>>> We have 60+ modules in a portlet application and it would be nice to
>>>> have a batch job that produced a release from a SNAPSHOT.
>>>>
>>> The release plugin can be used in multi-module scenarios.
>>>
>>>
>> Sounds like a real time-saver.
> It is, but as someone else noted, it does require testing. Your first
> release should NOT be 60 projects.
>
> Justin
>
>
>>
>> Thanks
>> Ron
>>> Justin
>>>
>>>
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 01/06/2010 10:15 AM, Shan Syed wrote:
>>>>
>>>>> I don't fully understand your scenario, but do you use the "release"
>>>>> plugin?
>>>>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>>>>
>>>>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>>>>> plugin
>>>>> will help you make a release version out of it without having to edit
>>>>> POMs
>>>>> manually
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> the organization that i currently work at is in the process of
>>>>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>>>>> which everyone will inherit from as opposed to the handful of
>>>>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>>>>> that are downstream of this architecture and we'll be rolling this
>>>>>> model out in phases since it would be very difficult to schedule a
>>>>>> release with all of our artifacts at once. we're hoping to take
>>>>>> advantage of the common plugin management and dependency management to
>>>>>> keep our third party dependencies more manageable. this sounds good,
>>>>>> but i'm guessing we'll get halfway through the rollout and realize
>>>>>> that we need to make some changes to the SuperPOM, which entails a new
>>>>>> version, which means updating all the downstream artifacts so they
>>>>>> inherit from the new parent. this could become a very vicious cycle.
>>>>>>
>>>>>> so, the question i have is how do other large organizations with this
>>>>>> model handle versioning their SuperPOMs? do you actually update the
>>>>>> version and then go through all the artifacts and update their parent
>>>>>> block? or do you keep the SuperPOM at a static version (probably not
>>>>>> a very good idea) so all updates are handled dynamically?
>>>>>> is there a way to enforce which version of the SuperPOM should be
>>>>>> used? or at least warn the developer that there is a newer version of
>>>>>> the SuperPOM that they should be inheriting from?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Andrew Close
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Versioning of company SuperPOM
Posted by Justin Edelson <ju...@gmail.com>.
On 6/1/10 12:02 PM, Ron Wheeler wrote:
> On 01/06/2010 11:30 AM, Justin Edelson wrote:
>> On 6/1/10 11:24 AM, Ron Wheeler wrote:
>>
>>> The documentation is a bit light.
>>>
>>> Are there any particular things to watch out for in the release plug-in?
>>>
>> 1) Know how to back out of a failed release.
>>
> Any hints about how we get to know this?
Know what your release process does and know how to reverse it. For
example, the release plugin will create a tag in SCM. Some organizations
disallow the removal of tags by regular users, so if a release fails, an
admin may need to remove the tag OR a new tag name must be used.
>> 2) Try not to have failed releases.
>>
>>
> We do what we can!
>
>>> Is it smart enough to fix the version of the parent pom in the
>>> project pom?
>>>
>> If fix == update, then no, the release plugin won't do this by default.
>> You can, however, add this by setting the preparation goals to include
>> versions:update-parent and scm:checkin"
>>
>>
> OK. Will look up how to do this.
>>> What about authentication to the SCM?
>>>
>> Not sure what you mean here.
>>
>>
> Our subversion requires usernames and passwords for each person.
If the credentials in the Subversion credentials cache are wrong, then
the release preparation will fail.
>>>
>>> We have 60+ modules in a portlet application and it would be nice to
>>> have a batch job that produced a release from a SNAPSHOT.
>>>
>> The release plugin can be used in multi-module scenarios.
>>
>>
> Sounds like a real time-saver.
It is, but as someone else noted, it does require testing. Your first
release should NOT be 60 projects.
Justin
>
> Thanks
> Ron
>> Justin
>>
>>
>>>
>>> Ron
>>>
>>>
>>> On 01/06/2010 10:15 AM, Shan Syed wrote:
>>>
>>>> I don't fully understand your scenario, but do you use the "release"
>>>> plugin?
>>>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>>>
>>>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>>>> plugin
>>>> will help you make a release version out of it without having to edit
>>>> POMs
>>>> manually
>>>>
>>>>
>>>>
>>>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> the organization that i currently work at is in the process of
>>>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>>>> which everyone will inherit from as opposed to the handful of
>>>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>>>> that are downstream of this architecture and we'll be rolling this
>>>>> model out in phases since it would be very difficult to schedule a
>>>>> release with all of our artifacts at once. we're hoping to take
>>>>> advantage of the common plugin management and dependency management to
>>>>> keep our third party dependencies more manageable. this sounds good,
>>>>> but i'm guessing we'll get halfway through the rollout and realize
>>>>> that we need to make some changes to the SuperPOM, which entails a new
>>>>> version, which means updating all the downstream artifacts so they
>>>>> inherit from the new parent. this could become a very vicious cycle.
>>>>>
>>>>> so, the question i have is how do other large organizations with this
>>>>> model handle versioning their SuperPOMs? do you actually update the
>>>>> version and then go through all the artifacts and update their parent
>>>>> block? or do you keep the SuperPOM at a static version (probably not
>>>>> a very good idea) so all updates are handled dynamically?
>>>>> is there a way to enforce which version of the SuperPOM should be
>>>>> used? or at least warn the developer that there is a newer version of
>>>>> the SuperPOM that they should be inheriting from?
>>>>>
>>>>>
>>>>> --
>>>>> Andrew Close
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
Re: Versioning of company SuperPOM
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 01/06/2010 11:30 AM, Justin Edelson wrote:
> On 6/1/10 11:24 AM, Ron Wheeler wrote:
>
>> The documentation is a bit light.
>>
>> Are there any particular things to watch out for in the release plug-in?
>>
> 1) Know how to back out of a failed release.
>
Any hints about how we get to know this?
> 2) Try not to have failed releases.
>
>
We do what we can!
>> Is it smart enough to fix the version of the parent pom in the project pom?
>>
> If fix == update, then no, the release plugin won't do this by default.
> You can, however, add this by setting the preparation goals to include
> versions:update-parent and scm:checkin"
>
>
OK. Will look up how to do this.
>> What about authentication to the SCM?
>>
> Not sure what you mean here.
>
>
Our subversion requires usernames and passwords for each person.
>>
>> We have 60+ modules in a portlet application and it would be nice to
>> have a batch job that produced a release from a SNAPSHOT.
>>
> The release plugin can be used in multi-module scenarios.
>
>
Sounds like a real time-saver.
Thanks
Ron
> Justin
>
>
>>
>> Ron
>>
>>
>> On 01/06/2010 10:15 AM, Shan Syed wrote:
>>
>>> I don't fully understand your scenario, but do you use the "release"
>>> plugin?
>>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>>
>>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>>> plugin
>>> will help you make a release version out of it without having to edit
>>> POMs
>>> manually
>>>
>>>
>>>
>>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com> wrote:
>>>
>>>
>>>
>>>> the organization that i currently work at is in the process of
>>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>>> which everyone will inherit from as opposed to the handful of
>>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>>> that are downstream of this architecture and we'll be rolling this
>>>> model out in phases since it would be very difficult to schedule a
>>>> release with all of our artifacts at once. we're hoping to take
>>>> advantage of the common plugin management and dependency management to
>>>> keep our third party dependencies more manageable. this sounds good,
>>>> but i'm guessing we'll get halfway through the rollout and realize
>>>> that we need to make some changes to the SuperPOM, which entails a new
>>>> version, which means updating all the downstream artifacts so they
>>>> inherit from the new parent. this could become a very vicious cycle.
>>>>
>>>> so, the question i have is how do other large organizations with this
>>>> model handle versioning their SuperPOMs? do you actually update the
>>>> version and then go through all the artifacts and update their parent
>>>> block? or do you keep the SuperPOM at a static version (probably not
>>>> a very good idea) so all updates are handled dynamically?
>>>> is there a way to enforce which version of the SuperPOM should be
>>>> used? or at least warn the developer that there is a newer version of
>>>> the SuperPOM that they should be inheriting from?
>>>>
>>>>
>>>> --
>>>> Andrew Close
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: Versioning of company SuperPOM
Posted by Justin Edelson <ju...@gmail.com>.
On 6/1/10 11:24 AM, Ron Wheeler wrote:
> The documentation is a bit light.
>
> Are there any particular things to watch out for in the release plug-in?
1) Know how to back out of a failed release.
2) Try not to have failed releases.
> Is it smart enough to fix the version of the parent pom in the project pom?
If fix == update, then no, the release plugin won't do this by default.
You can, however, add this by setting the preparation goals to include
versions:update-parent and scm:checkin"
> What about authentication to the SCM?
Not sure what you mean here.
>
>
> We have 60+ modules in a portlet application and it would be nice to
> have a batch job that produced a release from a SNAPSHOT.
The release plugin can be used in multi-module scenarios.
Justin
>
>
> Ron
>
>
> On 01/06/2010 10:15 AM, Shan Syed wrote:
>> I don't fully understand your scenario, but do you use the "release"
>> plugin?
>> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>>
>> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
>> plugin
>> will help you make a release version out of it without having to edit
>> POMs
>> manually
>>
>>
>>
>> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com> wrote:
>>
>>
>>> the organization that i currently work at is in the process of
>>> updating our POM hierarchy. we're moving to a common company SuperPOM
>>> which everyone will inherit from as opposed to the handful of
>>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>>> that are downstream of this architecture and we'll be rolling this
>>> model out in phases since it would be very difficult to schedule a
>>> release with all of our artifacts at once. we're hoping to take
>>> advantage of the common plugin management and dependency management to
>>> keep our third party dependencies more manageable. this sounds good,
>>> but i'm guessing we'll get halfway through the rollout and realize
>>> that we need to make some changes to the SuperPOM, which entails a new
>>> version, which means updating all the downstream artifacts so they
>>> inherit from the new parent. this could become a very vicious cycle.
>>>
>>> so, the question i have is how do other large organizations with this
>>> model handle versioning their SuperPOMs? do you actually update the
>>> version and then go through all the artifacts and update their parent
>>> block? or do you keep the SuperPOM at a static version (probably not
>>> a very good idea) so all updates are handled dynamically?
>>> is there a way to enforce which version of the SuperPOM should be
>>> used? or at least warn the developer that there is a newer version of
>>> the SuperPOM that they should be inheriting from?
>>>
>>>
>>> --
>>> Andrew Close
>>>
>>> ---------------------------------------------------------------------
>>> 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
RE: Versioning of company SuperPOM
Posted by Chris Helck <Ch...@us.icap.com>.
The release plugin has never meshed well with our organization, how we
release software, and our SCM system. So I suggest you try it out on a
couple of use cases. Particular problems for us is that we have separate
groups doing development and release so the release:prep and
release:perform are done on different machines. We also have separate
dev and release branches in Perforce and this seems to cause friction
with release plugin -- not that the plugin is wrong, just has different
expectations. Kinda hard to explain. Last problem is plugin does not
have deep understanding of Perforce labels (I understand why it does
not), but it wants to create labels differently from what we do.
Anyway, basic message is that release plugin is kinda cool, but you to
test if it meshes with your release process.
-Chris
-----Original Message-----
From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
Sent: Tuesday, June 01, 2010 11:24 AM
To: Maven Users List
Subject: Re: Versioning of company SuperPOM
The documentation is a bit light.
Are there any particular things to watch out for in the release plug-in?
Is it smart enough to fix the version of the parent pom in the project
pom?
What about authentication to the SCM?
We have 60+ modules in a portlet application and it would be nice to
have a batch job that produced a release from a SNAPSHOT.
Ron
On 01/06/2010 10:15 AM, Shan Syed wrote:
> I don't fully understand your scenario, but do you use the "release"
plugin?
> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>
> if you maintain your pre-release code as "SNAPSHOT so-and-so", this
plugin
> will help you make a release version out of it without having to edit
POMs
> manually
>
>
>
> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com>
wrote:
>
>
>> the organization that i currently work at is in the process of
>> updating our POM hierarchy. we're moving to a common company
SuperPOM
>> which everyone will inherit from as opposed to the handful of
>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>> that are downstream of this architecture and we'll be rolling this
>> model out in phases since it would be very difficult to schedule a
>> release with all of our artifacts at once. we're hoping to take
>> advantage of the common plugin management and dependency management
to
>> keep our third party dependencies more manageable. this sounds good,
>> but i'm guessing we'll get halfway through the rollout and realize
>> that we need to make some changes to the SuperPOM, which entails a
new
>> version, which means updating all the downstream artifacts so they
>> inherit from the new parent. this could become a very vicious cycle.
>>
>> so, the question i have is how do other large organizations with this
>> model handle versioning their SuperPOMs? do you actually update the
>> version and then go through all the artifacts and update their parent
>> block? or do you keep the SuperPOM at a static version (probably not
>> a very good idea) so all updates are handled dynamically?
>> is there a way to enforce which version of the SuperPOM should be
>> used? or at least warn the developer that there is a newer version
of
>> the SuperPOM that they should be inheriting from?
>>
>>
>> --
>> Andrew Close
>>
>> ---------------------------------------------------------------------
>> 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
**********************************************************************
This communication and all information (including, but not limited to,
market prices/levels and data) contained therein (the "Information") is
for informational purposes only, is confidential, may be legally
privileged and is the intellectual property of ICAP plc and its affiliates
("ICAP") or third parties. No confidentiality or privilege is waived or
lost by any mistransmission. The Information is not, and should not
be construed as, an offer, bid or solicitation in relation to any
financial instrument or as an official confirmation of any transaction.
The Information is not warranted, including, but not limited, as to
completeness, timeliness or accuracy and is subject to change
without notice. ICAP assumes no liability for use or misuse of the
Information. All representations and warranties are expressly
disclaimed. The Information does not necessarily reflect the views of
ICAP. Access to the Information by anyone else other than the
recipient is unauthorized and any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it is prohibited. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and
notify the sender.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Versioning of company SuperPOM
Posted by Ron Wheeler <rw...@artifact-software.com>.
The documentation is a bit light.
Are there any particular things to watch out for in the release plug-in?
Is it smart enough to fix the version of the parent pom in the project pom?
What about authentication to the SCM?
We have 60+ modules in a portlet application and it would be nice to
have a batch job that produced a release from a SNAPSHOT.
Ron
On 01/06/2010 10:15 AM, Shan Syed wrote:
> I don't fully understand your scenario, but do you use the "release" plugin?
> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>
> if you maintain your pre-release code as "SNAPSHOT so-and-so", this plugin
> will help you make a release version out of it without having to edit POMs
> manually
>
>
>
> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<ac...@gmail.com> wrote:
>
>
>> the organization that i currently work at is in the process of
>> updating our POM hierarchy. we're moving to a common company SuperPOM
>> which everyone will inherit from as opposed to the handful of
>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
>> that are downstream of this architecture and we'll be rolling this
>> model out in phases since it would be very difficult to schedule a
>> release with all of our artifacts at once. we're hoping to take
>> advantage of the common plugin management and dependency management to
>> keep our third party dependencies more manageable. this sounds good,
>> but i'm guessing we'll get halfway through the rollout and realize
>> that we need to make some changes to the SuperPOM, which entails a new
>> version, which means updating all the downstream artifacts so they
>> inherit from the new parent. this could become a very vicious cycle.
>>
>> so, the question i have is how do other large organizations with this
>> model handle versioning their SuperPOMs? do you actually update the
>> version and then go through all the artifacts and update their parent
>> block? or do you keep the SuperPOM at a static version (probably not
>> a very good idea) so all updates are handled dynamically?
>> is there a way to enforce which version of the SuperPOM should be
>> used? or at least warn the developer that there is a newer version of
>> the SuperPOM that they should be inheriting from?
>>
>>
>> --
>> Andrew Close
>>
>> ---------------------------------------------------------------------
>> 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: Versioning of company SuperPOM
Posted by Shan Syed <sh...@gmail.com>.
I don't fully understand your scenario, but do you use the "release" plugin?
http://maven.apache.org/plugins/maven-release-plugin/introduction.html
if you maintain your pre-release code as "SNAPSHOT so-and-so", this plugin
will help you make a release version out of it without having to edit POMs
manually
On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close <ac...@gmail.com> wrote:
> the organization that i currently work at is in the process of
> updating our POM hierarchy. we're moving to a common company SuperPOM
> which everyone will inherit from as opposed to the handful of
> semi-SuperPOMs we have now. :) we currently have over 300 artifacts
> that are downstream of this architecture and we'll be rolling this
> model out in phases since it would be very difficult to schedule a
> release with all of our artifacts at once. we're hoping to take
> advantage of the common plugin management and dependency management to
> keep our third party dependencies more manageable. this sounds good,
> but i'm guessing we'll get halfway through the rollout and realize
> that we need to make some changes to the SuperPOM, which entails a new
> version, which means updating all the downstream artifacts so they
> inherit from the new parent. this could become a very vicious cycle.
>
> so, the question i have is how do other large organizations with this
> model handle versioning their SuperPOMs? do you actually update the
> version and then go through all the artifacts and update their parent
> block? or do you keep the SuperPOM at a static version (probably not
> a very good idea) so all updates are handled dynamically?
> is there a way to enforce which version of the SuperPOM should be
> used? or at least warn the developer that there is a newer version of
> the SuperPOM that they should be inheriting from?
>
>
> --
> Andrew Close
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>