How to readl with maintenance branches?

[Markus KARG <ma...@headcrashing.eu>]

What is Maven 3's best practice to deal with "Maintenance Branches"
(non-feature, bug-fix-only line of development)?

 

Our company needs to maintain a second development line besides "trunk",
which we call " The Maintenance Branch", for those customers having signed a
maintenance contract for one particular version (e. g. when signed for
"1.1.0" he will receive bug fixes "1.1.*" but not features "1.2.*"). This
means, besides "trunk" (which always contains the latest features), we have
"branches/1.1-maintenance" (with "1.1" being the version number that this
branch was forked from to further get bug fixed but not feature-extended).
Due to the rules of the contracts, in that branches, all bug fixes must go
in, but no new features. Before using maven this was simple, as it was
completely manual work. But now we start using Maven, and get into some CI
and dependency trouble.

 

In "trunk" we always have SNAPSHOT versions, obviously, as we add features
daily til we reach the release day. Just when we do a release (1.0, 2.0,
etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT).
>From those tagged branches, we copy our maintenance branches (using "svn cp"
directly as we do not know how to tell maven to do so, BTW -- we expect that
release:branch could do this in future but we have not checked it so far).
So, the maintenance branch is NOT a SNAPSHOT version, as the release
obviously is never a SNAPSHOT version.

 

Now we like to use CruiseControl to do CI. We expect no problems in "trunk"
as all are SNAPSHOT versions, so a change to a dependency will trigger
"<maven2snapshotdependency>" to effectively compile and test the dependent
project each time the dependency changes (as the name says: it detects
snapshot changes of dependencies). Great!

 

But what to do with the "Maintenance Branch"? As soon as we merge a fix for
a dependency into that svn branch, we want CruiseControl to do CI. But we do
not expect that "<maven2snapshotdependency>" will recognize the modified
dependency -- as the maintenance branch is not SNAPSHOT (as it was created
by copying the release tag in svn).

 

We need a solution for THAT and have NO CLUE!

 

We had the idea that we could just manually increase the version's "z" (from
"x.y.z") of the product with each merged fix to express that this is a bug
fix, and add "-SNAPSHOT" to all projects in the "Maintenance Branch" to
activate the "<maven2snapshotdependency>" again. I assume that would work.
But, besides a LOT of manual work (we have nearly one hundred projects), we
would break the possibility to replace a JAR inside a customer's
installation (i. e. to actually provide the fix to the requesting customer):
As Maven's best practice is to add the version to the name, increasing the
minor version to express the bug fix level would result in dependencies
getting not found by the JVM's classloader anymore, as Java's "META-INF"
dependency resolution technology cannot deal with "partially changed names"
but insists on the exact same JAR name (and such the version number) of the
last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR).

 

We could provide a custom artifact name to the pom enforcing "abc-x.y.0.jar"
always, but as it seems, this is not Maven's best practice (otherwise maven
would do it automatically), so we assume there is a totally different
solution we just do no see.

 

So please, Maven Experts in this forum, enlight us! What is "The Maven Way"
of dealing with "Maintenance Branches"? What is the big trick that we just
do not see to get CI and dependency JAR loading running on bug-fix-only
branches?

 

Many, many thanks in advance. We know this is a very specific question, but
everything else is solved and this one blocks us. :-)

 

Regards

Markus

 

Re: How to readl with maintenance branches?

[Ron Wheeler <rw...@artifact-software.com>]

We would work SNAPSHOTS until the patch was ready for release and then 
release a full 1.1.1 release with all components included in the release.

Our portals do not have a single release for all the components. We 
treat our own modules like 3rd party modules and are no more bothered by 
a version 1.1.1 calling a version 1.1 component any more that we are 
bothered by out 1.1.1 version of our code calling a 1.1.12 version of 
log4j from Apache.

This takes a bit of organization when planning a new maintenance release 
but the 15 minutes is not a big deal for us if it means not having to 
rebuild about 60 modules that did not change in a typical maintenance 
release.

This may not be a "best practice" but it served us well for several 
years of intense development and maintenance.

Ron

On 11/02/2012 4:36 PM, Benson Margulies wrote:
> On Sat, Feb 11, 2012 at 1:47 PM, Markus KARG<ma...@headcrashing.eu>  wrote:
>> Thank you for opening the discussion. :-)
>>
>> I see two problems with the idea of lib-1.1.1-SNAPSHOT in the maintenance
>> branch of what was previously released as lib-1.1:
>>
>> (1) The original app-1.1.0.jar was delivered to the customer with
>> META-INF/MANIFEST.MF containing "Class-Path:" entries for dependency loading
>> of lib-1.1.0.jar. If we now provide lib-1.1.1.jar, the JVM's original
>> classloader is unable to find the new jar, obviously. As a solution we could
>> deliver JARs that have version-free artifact names (so any bug fix JAR would
>> match), but we noticed that mvn deploy ignores this setting (while mvn
>> install respects it). So it simply does not work. Another idea would be to
>> provide virtually unchanged app-1.1.1.jar in turn containing a different
>> Class-Path entry for the renamed dependency, but I doubt that CruiseControl
>> is able to provide such logic so it will end up in lots of manual version
>> upgrading work, which we do not want to perfom manually (but certainly we
>> expect this to be the most "pure and clean" way to deal with it, as it
>> clearly expresses that a change in the lib results in a change of the app).
>>
>> (2) As we have to provide a tested "hot fix" jar ASAP after fixing a bug,
>> actually EACH commit to the SCM in the maintenance branch has to force a mvn
>> deploy on the CI server -- to the RELEASE (!) repository, as it will get
>> sent away to the customer and is not just "waiting" in the SNAPSHOT
>> repository for some fine day when we think it is time to assemble and ship a
>> completely updated maintenance installer bundle. As the project is in
>> SNAPSHOT state, it will publish to the SNAPSHOT directory. See, ALL commits
>> to the maintenance branch actually are completed fixes and there are no
>> commits for "half-done" things. So to make the artifact end up in the
>> "right" (public, RELEASE) repository, it simply must not be declared as
>> being a SNAPSHOT (while actually you are right, it in fact IS a SNAPSHOT,
>> but one that in turn is to be RELEASEd immediately). A workaround would be
>> to run "mvn scm:checkin release:prepare mvn:perform" by the developer of the
>> fix (instead of simple svn commit) but this looks a bit scary as we have to
>> do it for each single fix. In a large company with a second QA contact
>> having to test first this wouldn't be an issue I think, but as we simply
>> rely on the CI server to do the tests we in fact do not have a two-step
>> release approach but the CI server MUST release the fix if the tests are OK.
>>
>> So you see, we in fact have ideas for solutions, but we like to know what
>> the real "Maven Way" is to deal with this questions. :-)
> The truth of the matter is that there's isn't aways exactly 'a maven
> way' for handling the transition of materials from the maven universe
> to the not-so-maven universe.
>
> However, in the case at hand, putting the version number in the name
> of the file that goes into the MANIFEST.MF classpath seems to pose a
> dilemma with or without maven. Redistributing a new jar with the old
> version number seems evil, no matter how you produce it. You might
> consider not putting version numbers in these jar file names -- or,
> alternative, distributing the patch via a 'patcher' that modifies that
> (those?) manifests.
>
>> Regards
>> Markus
>>
>>> -----Original Message-----
>>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>>> Sent: Samstag, 11. Februar 2012 15:53
>>> To: Maven Users List
>>> Subject: Re: How to readl with maintenance branches?
>>>
>>> There are better experts in the forum who know more about CI but I can
>>> make at least 1 contribution that might help.
>>>
>>> I am not sure that your situation is that uncommon.
>>> I am not sure why you would not have SNAPSHOTs on the maintenance
>>> branch.
>>>
>>> We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT
>>> all in existence at the same time if we had a 1.1 in production and
>>> were simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0
>>> version to be delivered to the 1.1 clients.
>>>
>>> We do not use CI so we would probably have a test environment where
>>> many of the modules would be quickly moved to 1.1.1 since they are not
>>> affected by the bug fix while some of the modules would be a 1.1.0-
>>> SNAPSHOT until they had passed the testing.
>>>
>>> I hope that this moves the conversation forward.
>>>
>>> Ron
>>>
>>>
>>>
>>>
>>> On 11/02/2012 7:11 AM, Markus KARG wrote:
>>>> What is Maven 3's best practice to deal with "Maintenance Branches"
>>>> (non-feature, bug-fix-only line of development)?
>>>>
>>>>
>>>>
>>>> Our company needs to maintain a second development line besides
>>>> "trunk", which we call " The Maintenance Branch", for those customers
>>>> having signed a maintenance contract for one particular version (e.
>>> g.
>>>> when signed for "1.1.0" he will receive bug fixes "1.1.*" but not
>>>> features "1.2.*"). This means, besides "trunk" (which always contains
>>>> the latest features), we have "branches/1.1-maintenance" (with "1.1"
>>>> being the version number that this branch was forked from to further
>>> get bug fixed but not feature-extended).
>>>> Due to the rules of the contracts, in that branches, all bug fixes
>>>> must go in, but no new features. Before using maven this was simple,
>>>> as it was completely manual work. But now we start using Maven, and
>>>> get into some CI and dependency trouble.
>>>>
>>>>
>>>>
>>>> In "trunk" we always have SNAPSHOT versions, obviously, as we add
>>>> features daily til we reach the release day. Just when we do a
>>> release
>>>> (1.0, 2.0,
>>>> etc.) we use the maven release plugin to get tagged branches (non-
>>> SNAPSHOT).
>>>>>  From those tagged branches, we copy our maintenance branches (using
>>> "svn cp"
>>>> directly as we do not know how to tell maven to do so, BTW -- we
>>>> expect that release:branch could do this in future but we have not
>>> checked it so far).
>>>> So, the maintenance branch is NOT a SNAPSHOT version, as the release
>>>> obviously is never a SNAPSHOT version.
>>>>
>>>>
>>>>
>>>> Now we like to use CruiseControl to do CI. We expect no problems in
>>> "trunk"
>>>> as all are SNAPSHOT versions, so a change to a dependency will
>>> trigger
>>>> "<maven2snapshotdependency>" to effectively compile and test the
>>>> dependent project each time the dependency changes (as the name says:
>>>> it detects snapshot changes of dependencies). Great!
>>>>
>>>>
>>>>
>>>> But what to do with the "Maintenance Branch"? As soon as we merge a
>>>> fix for a dependency into that svn branch, we want CruiseControl to
>>> do
>>>> CI. But we do not expect that "<maven2snapshotdependency>" will
>>>> recognize the modified dependency -- as the maintenance branch is not
>>>> SNAPSHOT (as it was created by copying the release tag in svn).
>>>>
>>>>
>>>>
>>>> We need a solution for THAT and have NO CLUE!
>>>>
>>>>
>>>>
>>>> We had the idea that we could just manually increase the version's
>>> "z"
>>>> (from
>>>> "x.y.z") of the product with each merged fix to express that this is
>>> a
>>>> bug fix, and add "-SNAPSHOT" to all projects in the "Maintenance
>>>> Branch" to activate the "<maven2snapshotdependency>" again. I assume
>>> that would work.
>>>> But, besides a LOT of manual work (we have nearly one hundred
>>>> projects), we would break the possibility to replace a JAR inside a
>>>> customer's installation (i. e. to actually provide the fix to the
>>> requesting customer):
>>>> As Maven's best practice is to add the version to the name,
>>> increasing
>>>> the minor version to express the bug fix level would result in
>>>> dependencies getting not found by the JVM's classloader anymore, as
>>> Java's "META-INF"
>>>> dependency resolution technology cannot deal with "partially changed
>>> names"
>>>> but insists on the exact same JAR name (and such the version number)
>>>> of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-
>>> JAR).
>>>>
>>>>
>>>> We could provide a custom artifact name to the pom enforcing "abc-
>>> x.y.0.jar"
>>>> always, but as it seems, this is not Maven's best practice (otherwise
>>>> maven would do it automatically), so we assume there is a totally
>>>> different solution we just do no see.
>>>>
>>>>
>>>>
>>>> So please, Maven Experts in this forum, enlight us! What is "The
>>> Maven Way"
>>>> of dealing with "Maintenance Branches"? What is the big trick that we
>>>> just do not see to get CI and dependency JAR loading running on
>>>> bug-fix-only branches?
>>>>
>>>>
>>>>
>>>> Many, many thanks in advance. We know this is a very specific
>>>> question, but everything else is solved and this one blocks us. :-)
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> Markus
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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
>>
> ---------------------------------------------------------------------
> 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: How to readl with maintenance branches?

[Benson Margulies <bi...@gmail.com>]

On Sat, Feb 11, 2012 at 1:47 PM, Markus KARG <ma...@headcrashing.eu> wrote:
> Thank you for opening the discussion. :-)
>
> I see two problems with the idea of lib-1.1.1-SNAPSHOT in the maintenance
> branch of what was previously released as lib-1.1:
>
> (1) The original app-1.1.0.jar was delivered to the customer with
> META-INF/MANIFEST.MF containing "Class-Path:" entries for dependency loading
> of lib-1.1.0.jar. If we now provide lib-1.1.1.jar, the JVM's original
> classloader is unable to find the new jar, obviously. As a solution we could
> deliver JARs that have version-free artifact names (so any bug fix JAR would
> match), but we noticed that mvn deploy ignores this setting (while mvn
> install respects it). So it simply does not work. Another idea would be to
> provide virtually unchanged app-1.1.1.jar in turn containing a different
> Class-Path entry for the renamed dependency, but I doubt that CruiseControl
> is able to provide such logic so it will end up in lots of manual version
> upgrading work, which we do not want to perfom manually (but certainly we
> expect this to be the most "pure and clean" way to deal with it, as it
> clearly expresses that a change in the lib results in a change of the app).
>
> (2) As we have to provide a tested "hot fix" jar ASAP after fixing a bug,
> actually EACH commit to the SCM in the maintenance branch has to force a mvn
> deploy on the CI server -- to the RELEASE (!) repository, as it will get
> sent away to the customer and is not just "waiting" in the SNAPSHOT
> repository for some fine day when we think it is time to assemble and ship a
> completely updated maintenance installer bundle. As the project is in
> SNAPSHOT state, it will publish to the SNAPSHOT directory. See, ALL commits
> to the maintenance branch actually are completed fixes and there are no
> commits for "half-done" things. So to make the artifact end up in the
> "right" (public, RELEASE) repository, it simply must not be declared as
> being a SNAPSHOT (while actually you are right, it in fact IS a SNAPSHOT,
> but one that in turn is to be RELEASEd immediately). A workaround would be
> to run "mvn scm:checkin release:prepare mvn:perform" by the developer of the
> fix (instead of simple svn commit) but this looks a bit scary as we have to
> do it for each single fix. In a large company with a second QA contact
> having to test first this wouldn't be an issue I think, but as we simply
> rely on the CI server to do the tests we in fact do not have a two-step
> release approach but the CI server MUST release the fix if the tests are OK.
>
> So you see, we in fact have ideas for solutions, but we like to know what
> the real "Maven Way" is to deal with this questions. :-)

The truth of the matter is that there's isn't aways exactly 'a maven
way' for handling the transition of materials from the maven universe
to the not-so-maven universe.

However, in the case at hand, putting the version number in the name
of the file that goes into the MANIFEST.MF classpath seems to pose a
dilemma with or without maven. Redistributing a new jar with the old
version number seems evil, no matter how you produce it. You might
consider not putting version numbers in these jar file names -- or,
alternative, distributing the patch via a 'patcher' that modifies that
(those?) manifests.

>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
>> Sent: Samstag, 11. Februar 2012 15:53
>> To: Maven Users List
>> Subject: Re: How to readl with maintenance branches?
>>
>> There are better experts in the forum who know more about CI but I can
>> make at least 1 contribution that might help.
>>
>> I am not sure that your situation is that uncommon.
>> I am not sure why you would not have SNAPSHOTs on the maintenance
>> branch.
>>
>> We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT
>> all in existence at the same time if we had a 1.1 in production and
>> were simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0
>> version to be delivered to the 1.1 clients.
>>
>> We do not use CI so we would probably have a test environment where
>> many of the modules would be quickly moved to 1.1.1 since they are not
>> affected by the bug fix while some of the modules would be a 1.1.0-
>> SNAPSHOT until they had passed the testing.
>>
>> I hope that this moves the conversation forward.
>>
>> Ron
>>
>>
>>
>>
>> On 11/02/2012 7:11 AM, Markus KARG wrote:
>> > What is Maven 3's best practice to deal with "Maintenance Branches"
>> > (non-feature, bug-fix-only line of development)?
>> >
>> >
>> >
>> > Our company needs to maintain a second development line besides
>> > "trunk", which we call " The Maintenance Branch", for those customers
>> > having signed a maintenance contract for one particular version (e.
>> g.
>> > when signed for "1.1.0" he will receive bug fixes "1.1.*" but not
>> > features "1.2.*"). This means, besides "trunk" (which always contains
>> > the latest features), we have "branches/1.1-maintenance" (with "1.1"
>> > being the version number that this branch was forked from to further
>> get bug fixed but not feature-extended).
>> > Due to the rules of the contracts, in that branches, all bug fixes
>> > must go in, but no new features. Before using maven this was simple,
>> > as it was completely manual work. But now we start using Maven, and
>> > get into some CI and dependency trouble.
>> >
>> >
>> >
>> > In "trunk" we always have SNAPSHOT versions, obviously, as we add
>> > features daily til we reach the release day. Just when we do a
>> release
>> > (1.0, 2.0,
>> > etc.) we use the maven release plugin to get tagged branches (non-
>> SNAPSHOT).
>> > > From those tagged branches, we copy our maintenance branches (using
>> "svn cp"
>> > directly as we do not know how to tell maven to do so, BTW -- we
>> > expect that release:branch could do this in future but we have not
>> checked it so far).
>> > So, the maintenance branch is NOT a SNAPSHOT version, as the release
>> > obviously is never a SNAPSHOT version.
>> >
>> >
>> >
>> > Now we like to use CruiseControl to do CI. We expect no problems in
>> "trunk"
>> > as all are SNAPSHOT versions, so a change to a dependency will
>> trigger
>> > "<maven2snapshotdependency>" to effectively compile and test the
>> > dependent project each time the dependency changes (as the name says:
>> > it detects snapshot changes of dependencies). Great!
>> >
>> >
>> >
>> > But what to do with the "Maintenance Branch"? As soon as we merge a
>> > fix for a dependency into that svn branch, we want CruiseControl to
>> do
>> > CI. But we do not expect that "<maven2snapshotdependency>" will
>> > recognize the modified dependency -- as the maintenance branch is not
>> > SNAPSHOT (as it was created by copying the release tag in svn).
>> >
>> >
>> >
>> > We need a solution for THAT and have NO CLUE!
>> >
>> >
>> >
>> > We had the idea that we could just manually increase the version's
>> "z"
>> > (from
>> > "x.y.z") of the product with each merged fix to express that this is
>> a
>> > bug fix, and add "-SNAPSHOT" to all projects in the "Maintenance
>> > Branch" to activate the "<maven2snapshotdependency>" again. I assume
>> that would work.
>> > But, besides a LOT of manual work (we have nearly one hundred
>> > projects), we would break the possibility to replace a JAR inside a
>> > customer's installation (i. e. to actually provide the fix to the
>> requesting customer):
>> > As Maven's best practice is to add the version to the name,
>> increasing
>> > the minor version to express the bug fix level would result in
>> > dependencies getting not found by the JVM's classloader anymore, as
>> Java's "META-INF"
>> > dependency resolution technology cannot deal with "partially changed
>> names"
>> > but insists on the exact same JAR name (and such the version number)
>> > of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-
>> JAR).
>> >
>> >
>> >
>> > We could provide a custom artifact name to the pom enforcing "abc-
>> x.y.0.jar"
>> > always, but as it seems, this is not Maven's best practice (otherwise
>> > maven would do it automatically), so we assume there is a totally
>> > different solution we just do no see.
>> >
>> >
>> >
>> > So please, Maven Experts in this forum, enlight us! What is "The
>> Maven Way"
>> > of dealing with "Maintenance Branches"? What is the big trick that we
>> > just do not see to get CI and dependency JAR loading running on
>> > bug-fix-only branches?
>> >
>> >
>> >
>> > Many, many thanks in advance. We know this is a very specific
>> > question, but everything else is solved and this one blocks us. :-)
>> >
>> >
>> >
>> > Regards
>> >
>> > Markus
>> >
>> >
>> >
>> >
>>
>>
>> --
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: How to readl with maintenance branches?

[Markus KARG <ma...@headcrashing.eu>]

Thank you for opening the discussion. :-)

I see two problems with the idea of lib-1.1.1-SNAPSHOT in the maintenance
branch of what was previously released as lib-1.1:

(1) The original app-1.1.0.jar was delivered to the customer with
META-INF/MANIFEST.MF containing "Class-Path:" entries for dependency loading
of lib-1.1.0.jar. If we now provide lib-1.1.1.jar, the JVM's original
classloader is unable to find the new jar, obviously. As a solution we could
deliver JARs that have version-free artifact names (so any bug fix JAR would
match), but we noticed that mvn deploy ignores this setting (while mvn
install respects it). So it simply does not work. Another idea would be to
provide virtually unchanged app-1.1.1.jar in turn containing a different
Class-Path entry for the renamed dependency, but I doubt that CruiseControl
is able to provide such logic so it will end up in lots of manual version
upgrading work, which we do not want to perfom manually (but certainly we
expect this to be the most "pure and clean" way to deal with it, as it
clearly expresses that a change in the lib results in a change of the app).

(2) As we have to provide a tested "hot fix" jar ASAP after fixing a bug,
actually EACH commit to the SCM in the maintenance branch has to force a mvn
deploy on the CI server -- to the RELEASE (!) repository, as it will get
sent away to the customer and is not just "waiting" in the SNAPSHOT
repository for some fine day when we think it is time to assemble and ship a
completely updated maintenance installer bundle. As the project is in
SNAPSHOT state, it will publish to the SNAPSHOT directory. See, ALL commits
to the maintenance branch actually are completed fixes and there are no
commits for "half-done" things. So to make the artifact end up in the
"right" (public, RELEASE) repository, it simply must not be declared as
being a SNAPSHOT (while actually you are right, it in fact IS a SNAPSHOT,
but one that in turn is to be RELEASEd immediately). A workaround would be
to run "mvn scm:checkin release:prepare mvn:perform" by the developer of the
fix (instead of simple svn commit) but this looks a bit scary as we have to
do it for each single fix. In a large company with a second QA contact
having to test first this wouldn't be an issue I think, but as we simply
rely on the CI server to do the tests we in fact do not have a two-step
release approach but the CI server MUST release the fix if the tests are OK.

So you see, we in fact have ideas for solutions, but we like to know what
the real "Maven Way" is to deal with this questions. :-)

Regards
Markus

> -----Original Message-----
> From: Ron Wheeler [mailto:rwheeler@artifact-software.com]
> Sent: Samstag, 11. Februar 2012 15:53
> To: Maven Users List
> Subject: Re: How to readl with maintenance branches?
> 
> There are better experts in the forum who know more about CI but I can
> make at least 1 contribution that might help.
> 
> I am not sure that your situation is that uncommon.
> I am not sure why you would not have SNAPSHOTs on the maintenance
> branch.
> 
> We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT
> all in existence at the same time if we had a 1.1 in production and
> were simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0
> version to be delivered to the 1.1 clients.
> 
> We do not use CI so we would probably have a test environment where
> many of the modules would be quickly moved to 1.1.1 since they are not
> affected by the bug fix while some of the modules would be a 1.1.0-
> SNAPSHOT until they had passed the testing.
> 
> I hope that this moves the conversation forward.
> 
> Ron
> 
> 
> 
> 
> On 11/02/2012 7:11 AM, Markus KARG wrote:
> > What is Maven 3's best practice to deal with "Maintenance Branches"
> > (non-feature, bug-fix-only line of development)?
> >
> >
> >
> > Our company needs to maintain a second development line besides
> > "trunk", which we call " The Maintenance Branch", for those customers
> > having signed a maintenance contract for one particular version (e.
> g.
> > when signed for "1.1.0" he will receive bug fixes "1.1.*" but not
> > features "1.2.*"). This means, besides "trunk" (which always contains
> > the latest features), we have "branches/1.1-maintenance" (with "1.1"
> > being the version number that this branch was forked from to further
> get bug fixed but not feature-extended).
> > Due to the rules of the contracts, in that branches, all bug fixes
> > must go in, but no new features. Before using maven this was simple,
> > as it was completely manual work. But now we start using Maven, and
> > get into some CI and dependency trouble.
> >
> >
> >
> > In "trunk" we always have SNAPSHOT versions, obviously, as we add
> > features daily til we reach the release day. Just when we do a
> release
> > (1.0, 2.0,
> > etc.) we use the maven release plugin to get tagged branches (non-
> SNAPSHOT).
> > > From those tagged branches, we copy our maintenance branches (using
> "svn cp"
> > directly as we do not know how to tell maven to do so, BTW -- we
> > expect that release:branch could do this in future but we have not
> checked it so far).
> > So, the maintenance branch is NOT a SNAPSHOT version, as the release
> > obviously is never a SNAPSHOT version.
> >
> >
> >
> > Now we like to use CruiseControl to do CI. We expect no problems in
> "trunk"
> > as all are SNAPSHOT versions, so a change to a dependency will
> trigger
> > "<maven2snapshotdependency>" to effectively compile and test the
> > dependent project each time the dependency changes (as the name says:
> > it detects snapshot changes of dependencies). Great!
> >
> >
> >
> > But what to do with the "Maintenance Branch"? As soon as we merge a
> > fix for a dependency into that svn branch, we want CruiseControl to
> do
> > CI. But we do not expect that "<maven2snapshotdependency>" will
> > recognize the modified dependency -- as the maintenance branch is not
> > SNAPSHOT (as it was created by copying the release tag in svn).
> >
> >
> >
> > We need a solution for THAT and have NO CLUE!
> >
> >
> >
> > We had the idea that we could just manually increase the version's
> "z"
> > (from
> > "x.y.z") of the product with each merged fix to express that this is
> a
> > bug fix, and add "-SNAPSHOT" to all projects in the "Maintenance
> > Branch" to activate the "<maven2snapshotdependency>" again. I assume
> that would work.
> > But, besides a LOT of manual work (we have nearly one hundred
> > projects), we would break the possibility to replace a JAR inside a
> > customer's installation (i. e. to actually provide the fix to the
> requesting customer):
> > As Maven's best practice is to add the version to the name,
> increasing
> > the minor version to express the bug fix level would result in
> > dependencies getting not found by the JVM's classloader anymore, as
> Java's "META-INF"
> > dependency resolution technology cannot deal with "partially changed
> names"
> > but insists on the exact same JAR name (and such the version number)
> > of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-
> JAR).
> >
> >
> >
> > We could provide a custom artifact name to the pom enforcing "abc-
> x.y.0.jar"
> > always, but as it seems, this is not Maven's best practice (otherwise
> > maven would do it automatically), so we assume there is a totally
> > different solution we just do no see.
> >
> >
> >
> > So please, Maven Experts in this forum, enlight us! What is "The
> Maven Way"
> > of dealing with "Maintenance Branches"? What is the big trick that we
> > just do not see to get CI and dependency JAR loading running on
> > bug-fix-only branches?
> >
> >
> >
> > Many, many thanks in advance. We know this is a very specific
> > question, but everything else is solved and this one blocks us. :-)
> >
> >
> >
> > Regards
> >
> > Markus
> >
> >
> >
> >
> 
> 
> --
> 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: How to readl with maintenance branches?

[Ron Wheeler <rw...@artifact-software.com>]

There are better experts in the forum who know more about CI but I can 
make at least 1 contribution that might help.

I am not sure that your situation is that uncommon.
I am not sure why you would not have SNAPSHOTs on the maintenance branch.

We would expect to have versions 1.1, 1.1.0-SNAPSHOT and 1.2-SNAPSHOT 
all in existence at the same time if we had a 1.1 in production and were 
simultaneously developing 1.2 while fixing 1.1 by creating a 1.1.0 
version to be delivered to the 1.1 clients.

We do not use CI so we would probably have a test environment where many 
of the modules would be quickly moved to 1.1.1 since they are not 
affected by the bug fix while some of the modules would be a 
1.1.0-SNAPSHOT until they had passed the testing.

I hope that this moves the conversation forward.

Ron




On 11/02/2012 7:11 AM, Markus KARG wrote:
> What is Maven 3's best practice to deal with "Maintenance Branches"
> (non-feature, bug-fix-only line of development)?
>
>
>
> Our company needs to maintain a second development line besides "trunk",
> which we call " The Maintenance Branch", for those customers having signed a
> maintenance contract for one particular version (e. g. when signed for
> "1.1.0" he will receive bug fixes "1.1.*" but not features "1.2.*"). This
> means, besides "trunk" (which always contains the latest features), we have
> "branches/1.1-maintenance" (with "1.1" being the version number that this
> branch was forked from to further get bug fixed but not feature-extended).
> Due to the rules of the contracts, in that branches, all bug fixes must go
> in, but no new features. Before using maven this was simple, as it was
> completely manual work. But now we start using Maven, and get into some CI
> and dependency trouble.
>
>
>
> In "trunk" we always have SNAPSHOT versions, obviously, as we add features
> daily til we reach the release day. Just when we do a release (1.0, 2.0,
> etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT).
> > From those tagged branches, we copy our maintenance branches (using "svn cp"
> directly as we do not know how to tell maven to do so, BTW -- we expect that
> release:branch could do this in future but we have not checked it so far).
> So, the maintenance branch is NOT a SNAPSHOT version, as the release
> obviously is never a SNAPSHOT version.
>
>
>
> Now we like to use CruiseControl to do CI. We expect no problems in "trunk"
> as all are SNAPSHOT versions, so a change to a dependency will trigger
> "<maven2snapshotdependency>" to effectively compile and test the dependent
> project each time the dependency changes (as the name says: it detects
> snapshot changes of dependencies). Great!
>
>
>
> But what to do with the "Maintenance Branch"? As soon as we merge a fix for
> a dependency into that svn branch, we want CruiseControl to do CI. But we do
> not expect that "<maven2snapshotdependency>" will recognize the modified
> dependency -- as the maintenance branch is not SNAPSHOT (as it was created
> by copying the release tag in svn).
>
>
>
> We need a solution for THAT and have NO CLUE!
>
>
>
> We had the idea that we could just manually increase the version's "z" (from
> "x.y.z") of the product with each merged fix to express that this is a bug
> fix, and add "-SNAPSHOT" to all projects in the "Maintenance Branch" to
> activate the "<maven2snapshotdependency>" again. I assume that would work.
> But, besides a LOT of manual work (we have nearly one hundred projects), we
> would break the possibility to replace a JAR inside a customer's
> installation (i. e. to actually provide the fix to the requesting customer):
> As Maven's best practice is to add the version to the name, increasing the
> minor version to express the bug fix level would result in dependencies
> getting not found by the JVM's classloader anymore, as Java's "META-INF"
> dependency resolution technology cannot deal with "partially changed names"
> but insists on the exact same JAR name (and such the version number) of the
> last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR).
>
>
>
> We could provide a custom artifact name to the pom enforcing "abc-x.y.0.jar"
> always, but as it seems, this is not Maven's best practice (otherwise maven
> would do it automatically), so we assume there is a totally different
> solution we just do no see.
>
>
>
> So please, Maven Experts in this forum, enlight us! What is "The Maven Way"
> of dealing with "Maintenance Branches"? What is the big trick that we just
> do not see to get CI and dependency JAR loading running on bug-fix-only
> branches?
>
>
>
> Many, many thanks in advance. We know this is a very specific question, but
> everything else is solved and this one blocks us. :-)
>
>
>
> Regards
>
> Markus
>
>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102