David Jencks ha scritto:
On Jun 17, 2008, at 4:18 PM, Stefano Bagnara wrote:
David Jencks ha scritto:
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.
Sorry David, I didn't want to mean that if it is an opinion of you it is
not important :-)
I just wanted to be sure there was no new directives I wasn't aware of,
so we can give this issue (and I agree this is an issue) the right priority.
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 would like maven to address this issue someway: are we the only maven
based project creating the jar, source-jar, javadoc-jar,
bin-zip-with-runtime-dependencies, src-zip-with-all-dependencies ? I
don't this so.
The LICENSE/NOTICE for the binary jar is the most simple to do: most
time it does not include 3rd party code, so maven should IMHO address
the most complex ones (the LICENSE/NOTICE for big packages including
some scope of dependencies)
I don't like what you propose (to manually create SOME license/notice
files for the other packages): IMHO it is worse than creating a single
NOTICE/LICENSE including the largest set with right references about
what is an internal dependency, what is a runtime dependency and what is
needed to build the sources. People reading it will have the option to
understand that the binary-jar does not really include the build time
dependencies and we would have a single tuple to review.
Maybe the assembly plugin should support NOTICE/LICENSE
compilation/aggregation.
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 :-)
David, your feedback is really appreciated and I'm very happy to learn
new ways to do things. Even if we won't probably delay this jsieve-0.2
release for this issue I think I will give a try to the multimodule
approach.
What scare me is that maven is an ASF project and after so many years it
still does not accomplish ASF requirements out of the box. People keep
finding naive poms and plugin mixtures in order to have the right stuff
in the right place. E.g: my understanding from the board is that
LICENSES for every artifact redistributed should be aggregated at the
bottom of the LICENSE file, instead m-r-r-p puts license references in
the NOTICE file. I also tried to tell this to maven-dev at the first
releases of m-r-r-p and the apache bundle but I've been ignored :-(
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
