On 19/05/2010 00:41, Brian Fox wrote:
The MAVENUPLOAD issue you refer to was processed by hand. This is
something we've worked to stop and automate, so it's not really
relevant what happened it was 2 years ago.
That said, I don't know if LICENSE.txt inside the new bundle format
would be handled any differently because LICENSE.txt is not a proper
maven artifact. foo-1.0-licence.txt is another story. Put that inside
a bundle and it will be preserved. Any solution that includes the
license as a file inside the m2 namespace will have to follow the m2
namespace conventions.
Maven Central gets all of its artifacts via rsync connections to
various repos. If developers put stuff without the license in their
sync source, well then it won't have it when we sync it. The rsyncs as
I mentioned before is something we are actively working on winding
down, but we can't just flip the switch overnite, projects need time
to update to a forge and to update their process.
This is an iterative process, I'd love to flip a switch tomorrow and
have all artifacts subject to a new standard but it's not practical.
I understand it's not easy. That's great work and I appreciate the effort.
It's been an ongoing battle just getting basic validation and gpg
signatures.
Indeed, trust management and validation are always problematic.
All that said, I don't know how beneficial the addition of a license
as a file in the repo really is. Instead the license inside the pom
should be validated, and if appropriate included inside the jars. We
_do not_ modify artifacts that are uploaded, and I'll make sure our
automated approach rejects jars that have files with non-conforming
files in them. Unfortunately this means a bundle with LICENSE inside
it will be rejected, but then you would at least know to use
foo-xx-license.txt instead if you want it to be included with your
artifacts.
Ah great, so sorry, that's what I didn't really understand and was
asking clarifications about in the first place.
I guess that's mainly a documentation issue then, considering the blog
entry you sent wasn't clearly linked from the maven.apache.org site (as
far as I could tell) and that I couldn't work out how "Sonatype [would]
perform some due diligence to make sure that the artifact has a license
compatible with unrestricted distribution."
For my next release which I'm planning to bundle over the next few days,
I've put the licence within the comments element:
http://jsslutils.googlecode.com/svn/trunk/jsslutils/pom.xml
Does that follow more or less the new guidelines? Are you saying that I
should have jsslutils-1.0-licence.txt next to the other jars in the
bundle instead (sorry, I can't see licence files in the screenshots on
that blog entry).
Best wishes,
Bruno.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
