On May 12, 2009, at 7:02 PM, Ralph Goers wrote:
On May 12, 2009, at 6:20 PM, David Jencks wrote:
On May 12, 2009, at 3:43 PM, Ralph Goers wrote:
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. So you create a "bill of materials" (bom) pom
that has the versions of all the subprojects and anything wanting
to use a commons project can just import that and then specify
dependencies on the various commons subprojects without specifying
a version. But to build this all the subprojects need to have the
bom pom as their parent or grandparent. Thus, any time you change
the bom pom version every subproject has to change even if nothing
changed in it. PITA.
Granted, my "library" isn't as big as commons, put it still
currently contains 22 pom.xml files that have to be modified each
time the bom pom changes.
I'm fairly mystified how what you and Jorg appear to want could
work with any of the scm systems I know about, that tag an entire
file system subtree at once. Maybe I don't understand what you
guys are talking about at all..... here's what I think you want:
file system structure showing projects
+root
+A
+B
+C
...
+D
Probably Jorg has further nesting, but I don't think that actually
affects the argument.
Projects A, C, E, G,... need to be released right now, whereas
projects B, D, F... are just fine and don't need releases.
IIUC you guys are supposing a parent pom for all these projects in
"root" and want to be able to run a release on root and have the
effect be to release just A, C, E, G and the root pom.
No. The root represents the library. The release is of the library,
not the individual subprojects. I just don't want new versions
created for subprojects that didn't change.
So if you run a release on root the entire tree will get tagged
including B, D, F etc that you didn't want tagged.
Actually, I do want them tagged. The "bill of materials" represents
a release of the whole library. It is just that some of the
artifacts in the library didn't change. But they should all be part
of the release tag.
So I think what you want to do is have a quick way to run releases
on A,C,E,G,... and have each of those tagged individually and not
tag the whole tree at once.
No. See above.
My impression is that what you are fighting is the scm system, not
maven.
No. The SCM isn't a problem. However, mvn deploy will try to deploy
artifacts that haven't changed since the last release. That is bad.
Nexus should be able to silently ignore those or the deployer should
somehow be able to detect that the artifact shouldn't be deployed.
I'm even more mystified and understand how you want to use scm even
less. One of the basic principles I have for scm is that stuff
shouldn't be duplicated, in the sense that if some artifact is
released at version 1.2.3.4 say, the scm location for that release can
be found in only one, unique, place in the scm tree, such as an svn tag.
Now if I understand what you are proposing, its to have
+root(1.2-SNAPSHOT)
+A(1.1-SNAPSHOT)
+B(1.3-SNAPSHOT)
Only B has changed since the last release, which was of root (1.1),
A(1.1) and B(1.2); these are the version in the release tag.
So you tag this after arranging the new release versions. You new tag
has root(1.2), A(1.1) and B(1.3), and trunk has root(1.3-SNAPSHOT),
A(1.1-SNAPSHOT) and B(1.4-SNAPSHOT)
The problem I have with this is that A(1.1) is present in two
different tags, violating the uniqueness principle I hold to.
Have I yet again misunderstood the actions you want to take during
release or do you think the uniqueness principle is not worth
following? If I've misunderstood again, could you provide a more
concrete example with versions and contents of tags to help me
understand?
thanks
david jencks
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
