On 9/21/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.
that's brave :-)
i'm not surprised you have questions since they are only half done as yet...
> 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.
+1
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.
+1
good explanation: create an issue in JIRA, patch those words in and
i'll apply the patch :-)
IOW a source distro is a prereq - an binary distros are nice to haves.
+1
users like binary distros but they are not necessary. source only
releases are sometimes useful in the early stages of a project (to
encourages active developers) or when users general received binaries
from downstream packagers
> 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.
yes: sub-standard is more accurate
the original, basic specification is pretty liberal but there are a
number of other specifications which (arguable) mandate information. a
fully standards compliant jar should IMHO comply with all these
various standards.
there is a consensus (based on 5 years of feedback cutting jars in
jakarta) about which fields are required to prevent criticism of the
MANIFEST for non-compliance with some Sun specification or other. need
to dig out the references.
The
default behaviour of Maven's archiver is not to add much but you can
address that using <manifest> configuration entries in the pom.
recommend setting the following:
Extension-Name: org.apache.XXX
Specification-Title: YYY
Specification-Vendor: The Apache Software Foundation
Specification-Version: nnn
Implementation-Vendor-Id: org.apache
Implementation-Title: YYY
Implementation-Vendor: The Apache Software Foundation
Implementation-Version: nnn
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?
don't worry too much if it turns out to be a PITA
the TODO note is that i'm not sure whether there's consensus on this
point or not. need to check on the general list.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
