David Jencks wrote:
On Mar 17, 2009, at 11:37 AM, David Sean Taylor wrote:
On Mar 17, 2009, at 11:28 AM, David Jencks wrote:
On Mar 17, 2009, at 10:39 AM, David Sean Taylor wrote:
On Mar 17, 2009, at 9:59 AM, Carsten Ziegeler wrote:
I'm -1 as well and agree with David J.
The proper release process (even for a pom) is to first cut the
candidate on which is voted. Instead of first voting and then cutting
the candidate.
May I suggest that we work as a community here... what I mean is
instead of statements like "the proper release process is...."
without pointing anyone at the process, could we simply try to help
Vivek? This is the first release he is trying to cut. Perhaps
sending some links to release procedure documentation for creating a
"proper release" would be more constructive, or even volunteering to
help.
Both Carsten and DJ are experienced, respected and knowledgeable
Apache members. I believe its your role to help the less experienced
of us out with the "Apache way"
Could someone point us at a document where these procedures are
written out?
DJ suggested using a Nexus repository. DJ, could you help Vivek and
I with the pom and the nexus staging procedures?
OK, although asking on maven irc will get you advice from people who
have actually used it :-) There's nexus staging info here:
http://www.sonatype.com/books/nexus-book/reference/staging.html
I think it would be a good idea to also include a release profile
that makes sure the source, javadoc, gpg and ianal plugins are run
(the last checks all artifacts for apache required legal files).
Should I just edit the poms or supply suggestions or patches?
Yes, please do. It would be great to see an example... thanks!
Well, "yes" to a multiple choice is a little ambiguous... I went ahead
and updated the poms.
portals-pom in rev 755415. I changed the scm urls, added a release
profile, added the plugins needed, and changed tabs to spaces.
applications-pom in rev 755416. I fixed the scm urls, tied down the
plugin versions, removed a couple redundant bits inherited from the
parent, and changed tabs to spaces.
IIUC the decision to use the apache pom version 5 means that all portals
snapshot and releases should get pushed to the apache nexus repo instead
of the file based repos everyone has previously been using. This is a
Really Good Thing but may require all portals projects to base off the
new portals-pom. I think we need to ask the nexus/maven guys to move
the existing releases and snapshots onto nexus.
I think I'm to blame for this :)
I suggested to Vivek just to take the latest apache pom as that seemed like a
good idea...
While I completely trust your opinion on this, I really didn't expect this would force us to switch from the file based repos, which I am
familiar with, to this new nexus thing of which I don't know anything about yet, and AFAIK neither does Vivek.
I just hope we're not going to get into a lot of extra procedure or work which
hasn't been fully straighted out or documented for the ASF...
If so, and even if this is a Really Good Thing as you say, maybe it would be
advisable to switch (for now) back to the apache pom 4?
Remaining questions/comments:
1. Note that a lot of plugins are now tied down in the portals-pom
project to support the release profile. I think this is a good idea but
it is a big change.
2. I would not include the clean plugin configuration, eclipse plugin at
all, the resource changes, and the website profile in the
applications-pom at all.
+1 on all this.
Since I don't know why they are there I didn't
change them.
These are left-over configurations from "promoting" a standalone pom to a master pom, I think these configurations can be removed without
problem.
3. It might be good to move the other plugin versions to the portals-pom
pom. Not sure what a good policy would be here.
Will think a bit more on it but seems fine by me too.
4. including the rat plugin might be handy
+1
5. The release profile I added uses the ianal plugin. This checks that
every artifact including java, source, and javadoc jars has LICENSE and
NOTICE files inside. I find it a lot better than trying to do this by
hand before a release
Great, I wasn't aware of that plugin. Seems like a good idea.
6. I recommend using the maven-remote-resources plugin to install these
legal files. I included the config in the root pom pluginManagement but
project poms still need to run the plugin.
Are there projects that are using these poms already?
The first project to use (and thereby test) the new master poms as well as the release procedure for them is the
portals/applications/webapp-logging project.
That project (producing just one very small jar artifact) was copied/promoted
from Jetspeed as its a simple but generic and useful component
and seemed ideal to test drive this.
I think (now) its project configuration might not yet be complete or correct
however.
Regards,
Ate
thanks
david jencks
Are you trying to get this out before apachecon eu?
its in one of those as soon as possible states. but yes, it would be
good to have it in so we can base other releases off of it
