Martijn Dashorst wrote:
How does the nested projects work with Eclipse? afaiu eclipse's
workspace needs to be a flat structure...
You just run mvn eclipse:eclipse at the top level and import only the
bottom-level projects (use File | Import and uncheck three boxes, I
guess). This isn't a big deal.
You don't need to have the <packaging>pom</packaging> projects imported
into Eclipse as Maven 2 builds. If you want the top-level project in
there for convenience of editing the site stuff, add the src folder from
it instead of the root.
afair the release plugin tags/branches each project separately. This
is not good imo. We don't release each project separate, but the
whole branch in one go. I've used the release plugin in the maven 1
days and it was nothing but a big pain in the rectum.
So, I've just tried to fake out a release in this branch. If it weren't
for the failing unit tests I'd have some tags to show you, but the long
and the short of it is that we will end up with two tags - one for the
JDK 1.4 directory and one for the JDK 1.5 directory.
This is the result of having to run two releases because you want to use
two different JDKs, and there's not much we can do about it.
The alternative is to write a little script which goes and updates
<version> elements in the POMs, tags everything in SVN, then does a
fresh checkout and then a "mvn -DperformRelease=true deploy" in each of
the jdk-1.* directories. This would actually be pretty simple. If it's
the preferred approach, I'll have a go at that. It'd be nice to be able
to do it with just Maven, though.
I've used the release plugin in the maven 1 days and it was nothing
but a big pain in the rectum.
The Maven 2 version is a ground-up rewrite, so I don't think that's
relevant.
Last thing for the moment: inherit the top parent from
org.apache/apache/4.0, this way you get the organization and some
other things for free.
Last time I tried this it bought almost nothing because the various
plug-ins it pulled in were alpha versions that didn't even work. :)
But yes, we should probably do that.
Why is the root pom version 1-SNAPSHOT and the jdk* poms
1-3-incubating-SNAPSHOT? Can't we just put the version in the root
pom and be done with that?
Depends. If we need to use two different JDKs, we need to release the
jdk-1.4 and jdk-1.5 trees separately. At this point, you'll need to have
released the parent already. The thinking was that this is easily done
by just having a static version number, so effectively you can release
the parent independent of the rest of it. It's not going to change much,
after all (especially if we remove the contributor list).
Another thing I want to remove from the pom's are the contributor,
developer list. These are rather dynamic and don't add much. The poms
don't need to change and be released when these things are modified.
Fine. This is in the root pom only in the new branch, so would be an
easy fix. I thought we originally put stuff in there to keep the Apache
folk happy. If not, let's ditch it. It gets out of sync and bloats
things annoyingly. You can probably auto-generate something similar from
JIRA, anyway.
Al