On 5/15/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
<snip>
>> If you add a dependency in maven MAYBE maven will automatically take >> care of the NOTICE changes, otherwise you can do it manually. If you >> don't use that generated license then you are SURE that you have to do >> it manually for sure. > > this algorithm is not sufficient to create a compliant NOTICE (it > would be possible to do it properly but it will take a while to write > the software and instrument the code bases with the required > meta-data) AFAIK the NOTICE we are generating in MIME4J is compliant, and it is generated. What's the problem, then?
there is no problem if they are compliant i haven't checked the NOTICE and i know of weaknesses in the current plugin. so it needs to be checked rather than just assumed to be correct. in particular, check that there are no documents without ALv2 headers in the source.
>> >> IMHO they are not compressed for delivery, but packaged in a >> >> redistributable artifact. >> > >> > just use a compression application >> >> <provoking>Why do you use ant? you could just execute a sequence of the >> command you need, instead..</provoking> > > creating and using any script is a trade-off > > creating source releases is quick and easy. few ever need to create > releases. i prefer to use the traditional way of creating releases. i > don't trust maven to accurately create source releases. > > - robert I don't share your missing trust for the maven-assembly-plugin: I don't see why I should trust svn/zip and not the maven-assembly-plugin. Either way, I checked the resulting package with a compare tool, and it worked fine.
good
As you wrote "I prefer" I think you are only telling your own preference and you're perfectly fine with what differently I do.
yes
Otherwise if you'll take the responsibility to release mime4j here is my +1 to use whatever build tool you like and whatever NOTICE generator and svn implementation ;-). "I don't trust maven to accurately create source releases" IMHO is not an acceptable justification to prevent us from working out a release.
i agree
IMHO you should simply check the generated result independently on how we generated it: IMHO the tools should be a choice of the worker.
i agree
That said I think I just completed my duties on mime4j. IMHO everything is ready for a release and our generated artifacts seems to be compliant with any policy I heard of. If anyone wants a release just ask Norman to take care of this (I don't have a signed gpg key so even if I wanted I could not do the last missing step).
a key with a strong web of trust is not required by policy: just a signature it's best practice to use a key with a strong web of trust but it's more important that the release is signed by the release manager who cut the release. the signature is primarily to allow infrastructure and the release manager to verify that an artifact was create by the release manager. all that requires is that the private key is kept safe and secure. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
