Jukka Zitting ha scritto:
Hi,
On Wed, Jun 18, 2008 at 11:25 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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.
We just had a good discussion about this issue in the Sling/Jackrabbit
land. Our conclusion was that if the build script (Maven in this case)
puts external stuff (i.e. not contained in the svn checkout/source
release) in the resulting build artifact, then it should also take
care of attaching proper LICENSE and NOTICE files to that artifact.
However, it looks like the <dependencies/> configuration (and related
m-r-r-p stuff) is not flexible enough to cover that, so we ended up
maintaining the "binary" LICENSE and NOTICE files manually in
src/main/resources/META-INF and other similar locations. It's
straightforward to configure for example the assembly plugin to pick
up appropriate LICENSE and NOTICE files to be included in the
assembled artifact.
In our case the dependencies ARE included in the source distribution, in
maven we use the assembly plugin to make sure they are all copied in the
source distribution, the runtime dependencies are copied in the the
binary zip.
I would simply need maven to generate the NOTICE/LICENSE for
dependencies I'm including with the "assembly" plugin and its
dependencySets feature! With this plugin maven is really aware of what
dependencies I am including in the resulting package. I tell maven to
include <scope>runtime</scope> in the lib folder: this is enough to
create an appropriate NOTICE/LICENSE.
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.
Similarly Ant has been an ASF project for ages and it doesn't do
anything about LICENSE and NOTICE files.
I don't consider Ant: it is a much more limited build tool and I don't
expect anything more than a set of batch commands from it ;-)
Maven in fact approached the LICENSE/NOTICE issue and provide us a
solution: the remote resources plugin and the apache resource bundle.
The fact that this plugin does not provide correct outputs for most
projects is a big issue.
This simply give a false sense of completeness/compliance to maven
users: they still have to manually take care of their license.
The collection and
maintenance of proper license and copyright information is a project
issue not a tool issue, so I wouldn't put blame on Maven about this.
assembly and the remote resources plugin should collaborate in order to
create NOTICE/LICENSE depending on the dependencySets specified in
assembly descriptor.
I already work on multiple OS projects I cannot afford studying maven
internals, but I don't understand why this issue has not been solved yet.
My opinion is that there is enough chaos around the LICENSE/NOTICE issue
that they gave up trying to find a good solution: they would simply need
good guidelines about what to do and they would fix it soon!
We're still learning how to best work with the central repository and
automatically downloaded dependencies and perhaps Maven one day will
contain proper tools to automate some of the related legal work, but
even today it doesn't prevent us from doing the right thing.
Please let me be clear: I love maven compared to ant. Here in the JAMES
project I'm the "promoter" for maven. Most of other committers simply
hate it.
BUT, even if I prefer maven, I think it is good to discuss weaknesses
and try to understand why they cannot be fixed.
In the mean time I'm fine with the LICENSE/NOTICE generated by the old
1.2 apache-jar-resource-bundle: it will declare much more than needed in
NOTICE for jar distribution but at least it is complete also for our src
with dependencies distribution. I'm fine with this solution until maven
will provide a more powerful solution. This is what we did for years
with ant and copying the LICENSE/NOTICE files from our src root to every
package (identical for each package regardless from the included
dependencies)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
