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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
