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. It's been an ongoing battle just getting basic validation and gpg signatures. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
