On May 12, 2009, at 6:17 PM, Christian Schulte wrote:
Ralph Goers schrieb:
On May 12, 2009, at 2:43 PM, Brian Fox wrote:
As I already said, I talked about release-plugin and my view of the
world
and it seems NOT to fit together. My POM-tree follows strict
logical
aspects that is motivated by the architecture of the project and
NOT by
the philosophy of some plugin.
I'm trying to understand your structure and motivations behind it,
so if you
would care to elaborate, we can be sure to consider these aspects
down the
road.
Well, you've seen mine. Imagine Apache commons where you wanted to
run
a build from the root of commons. Not everything changes with each
release so it is silly to deploy new jar versions that haven't
changed.
Why not just remove the modules which haven't changed from the
parent ?
The updated parent can still be imported afterwards just as you
describe
and the release plugin could be updated to do this automatically as
well. Instead of failing whenever a non-snapshot version is
encountered,
it could just remove that non-snapshot module element from the
corresponding parent and not touch that artifact's version anywhere
during release preparation. That's changing aggregation rules with
every
release somehow, I admit.
Imagine that you could get a pom.xml for all of Apache Commons that
contained the dependency management for it. Every time a commons
project released a new Commons "bill of materials" would go with it.
a) You want all the projects to be part of the build to be sure that
they all work together. Even though some projects didn't change,
running the unit tests will help identify any compatibility problems.
b) You don't want each release's bill of materials to only contain
what changed, it should reflect the whole library.
A release consists of converting all subprojects marked as snapshots
to non-snapshots and leaving the other subprojects alone, tagging
everything, building everything and then deploying only the artifacts
that were modified to Nexus, along with the bom pom. Note - it does
not end with changing everything to snapshots. We only do that when we
actually change something.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
