commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: [general] MANIFEST files...
Date Mon, 17 May 2004 18:46:46 GMT

Hi,

>What you are telling, it seems, is that there is a key practice at
>Apaache, amazing!

Yup, and there has been for a long time ;)  I think we're decent at
keeping KEYS files and documenting the signing of a release as part of
the SOP for cutting a new release.  Keep in mind I'm speaking for the
tomcat, log4j, and commons projects only.  I don't experience releasing
some of our other key components, but I trust my fellow committers to
follow good practices ;)

>Signing jars is automated in many tools, including Maven (simply using
>Ant's signjar, see your .maven/plugins/maven-jnlp-plugin/plugin.jelly,
>having run the jnlp target once, for an example.

I'm familiar with Ant's signjar, which is more applicable than Maven in
the logging and tomcat release management worlds.  I just wanted to make
the point that this signing must be automated, as release management can
already be a sufficient headache ;)

>Tomcat jars are a good example of something we'd like to have signed
>because many people merge it with others (our tomcat.jar contains soooo
>many other stuffs!).

Tomcat jars are kept separate for good reasons.  Combine them at your
own risk.

>But be careful with the dozens, you only want to sign what you are
>producing and expect the things you depend on to be signed by their
>makers! That shouldn't make dozens, I think. Maybe half a dozen ?

No, dozens: 28 to be precise for tomcat 5.0.24, not counting the servlet
and JSP API jars (which I don't know who should sign, but the tomcat
build produces them) and jakarta commons jars (which as you mentioned
the tomcat build shouldn't sign, they should already be signed by their
release managers).  But 28 is OK because this is automated ;)

Yoav




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message