David Jencks ha scritto:
On Jun 17, 2008, at 12:50 AM, Stefano Bagnara wrote:
David Jencks ha scritto:
<unsolicited build advice>
I glanced over the pom and have a couple comments:
Thank you David, we need this kind of hints like gold, so next time
feel free to use the <solicited> tag ;-)
1. After a lot of discussion on legal discuss the appropriate
contents of LICENSE and NOTICE files is to include only wording that
applies to what is actually in the jars. This is encoded in
apache-jar-resource-bundle-1.4.jar (you use 1.2). In particular
unless you are including the junit jar in one of the generated jars
the extra comment is unnecessary and wrong. The 1.4 resource bundle
also generates a DEPENDENCIES file that lists all the jar's
dependencies: this is purely for user's possible convenience.
shame on me: I checked for updates but I only updated the
maven-remote-resources-plugin and not the resource bundle version!! :-(
I tested it now but it break our assembly because this way the "simple
NOTICE" without references to junit and commons-logging references is
included also in the bin with dependencies zip and in src with
dependenciez zip.
I also don't understand why it is completely ignoring our
src\main\appended-resources\supplemental-models.xml file, but I'll
investigate a bit more on this, ASAP.
I looked at the build a little bit more and, there may be problems
producing correct LICENSE/NOTICE files for all the artifact being
built. I think this shows up one of the problems with the current stage
repo location.
It's not a problem with the stage repo location: how do you make maven
to create different LICENSE/NOTICE files depending on the real content?
We create jar, source-jar, javadoc-jar, bin(with runtime dependencies),
src(with runtime, compile, test dependencies) packages: each one would
require a different NOTICE/LICENSE. I thought that using the most
complete NOTICE/LICENSE (the one for the src with dependencies) was not
the best, but acceptable.
The source and binary jars do not include junit so their LICENSE and
NOTICE files must not include them. The distro assemblies do include
them so require a different LICENSE/NOTICE file. So do the required
LICENSE/NOTICE files in svn at the checkout root.
You say "MUST NOT" include them: I thought it was a "SHOULD NOT", but
maybe the board had different directives?
For me this would be enough to put the stage repo in a different module
with separate legal goo files, so that the build requirements don't get
mixed up so much with the actual apache code in the module. However
opinions may differ on this.
Anyway I'm not sure what is breaking and what problems you are seeing.
I'm not sure I understand how to place it in a different module, still
create all of our artifacts and have different license/notice files in
each artifact: can you drive me there?
2. I recommend listing the plugins in a pluginManagement section and
leaving out the versions in the build and report sections.
What is the advantage in a single module product? Most plugins are
used only once: wouldn't this simply duplicate the size of the pom?
I suggested this because I thought I saw several versions are repeated
in the build and reports section. Speaking for myself I can't keep 2
copies of a version in sync.
Ok, if it is about duplication maybe I should do this only for plugins
used in build and report (javadoc and rat, IIRC).
3. I strongly recommend setting up a release profile and using the
release plugin. I did this in geronimo and a couple other projects.
The latest is the activemq release profile
https://svn.apache.org/repos/asf/activemq/trunk/pom.xml
This profile does the build, including source and javadoc jars, signs
everything, and uploads to a staging area typically on
people.apache.org. It requires some settings in your settings.xml
file, see intstructions at
http://cwiki.apache.org/GMOxPMGT/geronimo-release-process.html
I used the resources you link many months ago when we made our first
maven based release! Without that resourcs I could have never been
success in accomplish the release process.
All of this stuff should be in our parent pom:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/james/james-parent/1.1/james-parent-1.1.pom
We used automatic sign/deploy/stage process for our mime4j and jspf
releases and after few initial problems it worked very fine! I think I
configured jSieve the same way, so it should work. Please let me know
if I missed something!
I missed the contents of the parent pom. In the next version of the
parent pom you might want to consider using the apache pom as a parent
as it includes a lot of the same info.
We considered this at the time of our first maven release, but the main
apache pom had some bad content for us and introduced issues.
But maybe newer apache parent poms are much better and we will consider
this when releasing the next parent pom :-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
