HI Graham,
well I took the code, changed the version and did a little experimenting. It
seems that there is only one place, where I would need a modification and I
would have a perfectly working release:prepare.
In AbstractRewritePomsPhase the method transformDocument currently builds the
"originalVersions" by fetching the versions for all projects in the reactor
from the configuration:
Map<String, String> originalVersions = getOriginalVersionMap(
releaseDescriptor, reactorProjects, simulate );
If I change this that instead of "reactorProjects", "allProjects" is used, I
get all the versions for all the artifacts I wanted and the plugin works like a
charm. The cool thing is that this way, I can really build the tag and get the
exact same result as when initially releasing.
I don't even need modifying anything else ... the deploy phase triggered by the
release:perform plugin automatically deploys all artifacts, but it deploys the
release versions to the release destination and the snapshot versions to the
snapshot destination.
This small patch does all the magic (I bet there is a better way to get
"allProjects" in contrast to the "reactorProjects", this was just the POC that
actually made my day ;-) )
Index:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
---
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
(revision 0b43d66b25f5fef81ba7f426c67aedc77858dbc8)
+++
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
(revision )
@@ -257,14 +257,26 @@
}
}
+ @SuppressWarnings("unchecked")
private void transformDocument( MavenProject project, Element rootElement,
ReleaseDescriptor releaseDescriptor,
List<MavenProject> reactorProjects,
ScmRepository scmRepository, ReleaseResult result,
boolean simulate )
throws ReleaseExecutionException, ReleaseFailureException
{
+ // Get the project root.
+ MavenProject projectRoot = project;
+ while(projectRoot.getParent() != null) {
+ projectRoot = projectRoot.getParent();
+ }
+
+ // Create a list of all projects.
+ final List<MavenProject> allProjects = new ArrayList<MavenProject>();
+ allProjects.add(projectRoot);
+ allProjects.addAll(projectRoot.getCollectedProjects());
+
Namespace namespace = rootElement.getNamespace();
Map<String, String> mappedVersions = getNextVersionMap(
releaseDescriptor );
- Map<String, String> originalVersions = getOriginalVersionMap(
releaseDescriptor, reactorProjects, simulate );
+ Map<String, String> originalVersions = getOriginalVersionMap(
releaseDescriptor, allProjects, simulate );
@SuppressWarnings("unchecked")
Map<String, Map<String, String>> resolvedSnapshotDependencies =
releaseDescriptor.getResolvedSnapshotDependencies();
Model model = project.getModel();
-----Ursprüngliche Nachricht-----
Von: Chris Graham [mailto:chrisgw...@gmail.com]
Gesendet: Samstag, 16. Februar 2013 02:11
An: Maven Developers List
Betreff: Re: AW: Update release plugin to allow more fine-grained releases
I can see your issue :-) and this is where you'll run into the opinionated
nature of maven. :-)
I work to the adage of work with the tools, not against them.
In this case, I would change your distribution and update mechanism.
Simply put, add another module that contains a manifest of the _actual_ changes
(this process will need to stringently controlled). Then have your app pull
down the manifest (I'd do it in XML) and then download the actual changes.
Ultimately, I think you'll that less work for you in reworking the release
plugin (it keeps the well known and well understood processes in tact) and
provides a better solution for your customers.
Just a thought.
-Chris
Sent from my iPhone
On 15/02/2013, at 7:24 PM, "christofer.d...@c-ware.de"
<christofer.d...@c-ware.de> wrote:
> Hi Chris,
>
> Well the project consists of about 80 modules. The main reason for this is
> that the application is a big Swing application distributed via some
> web-start similar technology. The reason for releasing only parts is that the
> application is used all over the world and some locations have a really
> limited internet connection. So being able to release only changed modules
> reduces the time needed of the update from several hours to minutes. Hours
> during which people can't work. So I do agree ... releasing fragments is
> generally a bad idea and it does come with quite a price to pay. But my
> customer is willing to pay that "price" in order to be able to not pay the
> price of stalling business all over the world every one or two weeks.
>
> The way the release plugin currently works, indeed this would create
> inconsistent tags. That's why I would like to provide dev and release
> versions for all modules of the project and then limit the release plugin to
> process only selected modules (Of course ... if you have a dependency
> management section in your root and you release that with the others, things
> will break, but if you reference each internal module with it's version
> directly). The tag would contain poms with released versions for each module
> that was part of the sub-release and would contain SNAPSHOT versions for all
> others. So if you did a full build of the tag, the exact same output should
> be produced.
>
> Hopefully this explains the reasons a little more.
>
> Chris
>
> ________________________________________
> Von: Chris Graham [chrisgw...@gmail.com]
> Gesendet: Donnerstag, 14. Februar 2013 22:45
> An: Maven Developers List
> Betreff: Re: Update release plugin to allow more fine-grained releases
>
> If I understand what you've written correctly, you wish to
> build/release only parts of your project.
>
> If that is the case, then I a'd advise you to split the projects to in
> two separate ones, each with their own trunk etc.
>
> That way when you check out from a tag, you'll be building everything
> correctly, the maven way.
>
> -Chris
>
>
> On Thu, Feb 14, 2013 at 10:12 PM, christofer.d...@c-ware.de <
> christofer.d...@c-ware.de> wrote:
>
>> But thanks for that hint to check 2.3.2 ... I'll have a look at that
>> this weekend :-)
>>
>> ________________________________________
>> Von: Robert Scholte [rfscho...@apache.org]
>> Gesendet: Donnerstag, 14. Februar 2013 11:59
>> An: Maven Developers List
>> Betreff: Re: Update release plugin to allow more fine-grained
>> releases
>>
>> Be aware that you can't determine with which arguments the deploy was done.
>> So if you check out the sources from tag, how should you re-install
>> these projects?
>> It should be as simple as 'mvn install'.
>> This means that the projects you don't want to release should keep
>> their -SNAPSHOT version.
>> There's a good chance that this has changed with m-release-p 2.4,
>> since it checks the value of the release and development versions.
>> Until now nobody had problems with it and that's a good thing.
>> So maybe 2.3.2 is a better version for you, so you can keep the
>> unreleasable projects on their old SNAPSHOT version.
>>
>> Robert
>>
>> Op Wed, 13 Feb 2013 20:30:39 +0100 schreef christofer.d...@c-ware.de
>> <christofer.d...@c-ware.de>:
>>
>>> Hi,
>>>
>>> I was experimenting a little with the release plugin.
>>>
>>> In one of my experiments I gave it a really long list of dev- and
>>> release-versions for a lot of artifacts using the "-Dproject.rel."
>>> and "-Dproject.dev." properties. Then I limited my maven build to
>>> only process a hand full of modules.
>>>
>>> What I was expecting, was that in the modules in the reactor the
>>> versions I provided would have been used to update the versions of
>>> all the artifacts I provided the plugin with. But I had to realize
>>> that the artifact versions of only the artifacts in the reactor were
>>> updated, but also for the modules that were not included.
>>>
>>> I find this way of processing quite problematic.
>>>
>>> I would volunteer to have a look at the plugin and whip up a patch.
>>> But I guess this only makes sense, if there is a chance of my work
>>> actually being accepted.
>>>
>>> What do you think about this?
>>>
>>> Chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
>> additional commands, e-mail: dev-h...@maven.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
>> additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For
> additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
