On Sep 21, 2006, at 6:57 AM, kelvin goodson wrote:

In trying to follow the release management draft guidelines at
http://incubator.apache.org/guides/releasemanagement.html I have a few
questions.

1) for a source distribution the guidelines say "Check for version
control<http://incubator.apache.org/guides/ releasemanagement.html#best-practice-source>files",
but the linked info currently only says ...  "TODO: describe what a
source distribution is; version control for distributions; add content to
release documents; export not checkout"

so can anyone elaborate what's required here?

IMO a source distribution is an archive with all the source needed to rebuild the project. Conceptually, I would define that as being a signed tarball of an export of the svn URL pointing to the tag. An export not a checkout because the export does not contain the hidden .svn directories used to manage the changes.

When cutting the final release IMO it should be built from such an export rather than out of a normal working tree. That way you know for sure that the source distro will actually build and that, given the same conditions (like platform), anyone should be able to reproduce a binary distro.

IOW a source distro is a prereq - an binary distros are nice to haves.


2) Guidelines say ---  Jars -- should include a standards compliant
manifest, and goes on to say ...

"TODO Lots of projects get this wrong and (by default) most tools produce substandard manifests. Offer some guidance on values TODO: Add how to create
a specification complient MANIFEST
http://jakarta.apache.org/commons/releases/ prepare.html#checkjarmanifest" the jakarta link just talks about how maven builds a standard file and adds non standard (jakarta specific?) elements to the manifest file. So I don't know whether (a) letting maven do its stuff will make us compliant and (b) whether the inclusion of non standard elements in a manifest file makes the
file non compliant.
Can anyone point to a definition of a standard manifest file?

I think Robert means "substandard" rather than "non-standard" as the JAR spec is fairly minimalist about what *must* be in there. The default behaviour of Maven's archiver is not to add much but you can address that using <manifest> configuration entries in the pom.

An alternative is to add a full OSGi header - we've experimented with the plugin from Felix to do this but 1) there is no released version yet, and 2) I have not found a way of preventing it from adding all project dependencies into the generated bundle.



3) ASF doc says ... "incubating projects should contain the STATUS document describing. TODO: check this" I've looked at our STATUS doc that went out with M1 and it contains general project info which would be the same for SDO as for SCA I think. I'm having trouble knowing where maven might look for a STATUS file or how to configure it to pick one up. Can anyone help with how I should do this please? I tried placing a STATUS file alongside the NOTICE file etc in distribution/sdo but that didn't get picked up, so I guess maven already knows about NOTICE files somehow and needs to be taught
about STATUS files.

We chatted about this earlier on IRC and ...
* Tuscany's STATUS file lies here https://svn.apache.org/repos/asf/ incubator/tuscany/STATUS
* you can reference that from the assembly plugin's config file
* doing so can be a problem as it is a reference to a resource outside the maven project

We'd mentioned possibly using an svn external to symlink from the distro project to the root - did that work out?

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to