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.
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.
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.
My impression is that what you are fighting is the scm system, not
maven.
As far as project setup, what I've done in this situation is have a
parent pom that isn't "root" but parallel to the projects: all the
projects use this parent as their parent and obviously dont specify
its location as "..". I then construct a pom that builds whatever I'm
interested in working on in root, but don't check it into svn. I've
never had to release more than 2 projects at once in such a setup, so
just releasing modules individually hasn't been a problem for me. I
can see that it would be a problem if I had 10 projects to release at
once. I'd think this is additional new functionality for e.g. the
release plugin rather than something that can be created by modifying
existing functionality.
I was really confused by this kind of situation until I realized that
the problems with releasing complicated partial subtrees were caused
by scm, not maven. After I arranged the source so tagging would
correspond to the independent versions I wanted the layout became much
easier for me to understand.
Does this correspond at all to what you guys are talking about?
thanks
david jencks
Ralph
---------------------------------------------------------------------
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
