On Jun 17, 2008, at 4:18 PM, Stefano Bagnara wrote:
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?
I don't think there's total consensus except that what the m-r-r-p
used to generate was wrong :-) To me it's unacceptable to distribute a
jar with a NOTICE file that any user has to display somewhere claiming
that there's say junit included when it is not included, likewise for
license files. They are supposed to be the users guidance as to what
is legally going on with the jar they are working with.
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?
I don't know how to produce these different legal files in one module
except by hardcoding them in each case, so I'm suggesting separating
into more than one module: the regular java module can just use the m-
r-r-p with the latest resource bundle and no (AFAIK) additions, and
the external jars can go in a stage bundle with a hardcoded LICENSE/
NOTICE file suitable to the contents. Maybe I've drunk too much maven
kool-aid but I find the mixing of repositories and code rather bizarre.
I may well be pushing in an inappropriate direction for the project
here, so feel free to ignore me or tell me to shut up :-)
thanks
david jencks
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
