Jeremy, Thanks for this. Im in butterfly mode at the moment, flitting from work to non-work items, so I haven't had time to address all your comments. However, re the svn external experiment. I played for a while trying to get it to work but didn't quite manage it. It did seem that the svn free book was talking about links to folders only, which could be an issue. I'll play some more later.
Regards, Kelvin. On 21/09/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
