Hi,

I have a Maven question which seems appropriate for this list.

I'm having some trouble understanding how precisely Maven is used in the release process. I think CreatingReleases doesn't really describe it, except in the bottom section "Procedure for creating a release using M2 (outdated by above)". The article it links to, Releasing A Maven Project <http://maven.apache.org/developers/release/releasing.html>, seems to talk about releases components /for/ Maven, as opposed to those that simply use Maven as the build system.

Basically, I think the first subtask involved in setting up a a Maven build for my project is to determine what are the precise tasks and goals that are called in the Maven build in the release lifecycle (I'm attempting to use Maven terminology here; if I'm getting this wrong, please correct me).

The next subtask would then be to delegate these Maven goals, where needed, to the ant build script. This may involve overriding Maven's default behaviour.

The second subtask is one that I will ask about on the Maven mailing list, but the first subtask (what tasks and goals are called in a Commons release lifecycle) is better for this list.

Let me know what you think about this. Thanks,

Jake

On 10-08-24 12:14 PM, Rahul Akolkar wrote:
On Tue, Aug 24, 2010 at 11:39 AM, Jacob Beard<jbea...@cs.mcgill.ca>  wrote:
Hi Rahul,

I read through all of the materials you linked to. I have technical
questions about how to integrate maven with ant for the purposes of creating
releases, but I'll save those for the maven user's list. I do have a few
other process-oriented questions.

First, http://wiki.apache.org/commons/CommonsEtiquette says this about
voting on promotion from sandbox:

/"The health of the development community. Fellow committers need to be
persuaded that users will be supported and the code pushed forward by the
listed committers. This is a major issue since there's only a limited amount
of energy amongst the commons committers and no one wants to have to support
a component whose committers have gone AWOL."/

Given that I am the only developer of this project, I'd like to know if
there have there been other single-developer Commons projects that have been
successfully promoted. I'd rather not put it out for a vote if it is likely
to be refused for this reason.

<snip/>

There certainly are such examples, Commons SCXML itself is one (and
had to try twice before the promotion passed muster). Majority of
components at Commons do not have the luxury of having more than one
active developer at any given time. As the above wiki page mentions,
in terms of community aspects (so code quality etc. kept aside) the
key is:

(a) the developer(s) are excited about the code and committed to
supporting the code
(b) the rest of the community is convinced of (a) -- everyone
understands life can get in the way, but the intention to support in
the long run is what folks look for IMO
(c) enough of the community thinks the code is a useful addition to proper


Second, the page on creating releases links to this document on versioning:
http://commons.apache.org/releases/versioning.html

It mentions beta releases, but not alpha releases. Given that scxml-js has
only had one user, which is me, I expect it to be buggy and would rate it as
alpha-quality software. However, I still think it's worth releasing, as it's
already proven robust enough for me to use in implementing a non-trivial
demo, and I believe there will be other people interested in using it. Are
alpha releases condoned by Commons?

<snap/>

I think thats what the release versioning document refers to as
milestone releases for wider testing purposes. The version identifier
and download page etc. will have to make it clear its a
milestone/alpha release. I personally think its OK to have clearly
marked alpha releases.

-Rahul


Let me know what you think. Thanks,

Jake

On 10-08-23 11:49 PM, Rahul Akolkar wrote:
On Mon, Aug 23, 2010 at 10:14 PM, Jacob Beard<jbea...@cs.mcgill.ca>
  wrote:

Hi,

I've been working to overhaul the build system to phase out the custom
JavaScript build script in favor of Ant. I'm currently writing a blog
post
about the full process leading up to this, but suffice it to say that I
now
have an Ant script working that has most of the functionality of the
original build script. A big advantage to using Ant instead of the custom
build script is that it is now possible to create two important release
artifacts:

1. A minimized JavaScript file which contains all of the JavaScript
modules
in scxml-js
2. A class file and JAR version of scxml-js that can be run standalone on
the JVM

The first artifact means that only one JavaScript file will need to be
downloaded to a web page for scxml-js to compile SCXML documents on the
fly,
while the second artifact means that the user will only need to download
a
single JAR file in order to run scxml-js from the command line.

Using ant also means that it will be possible to integrate the building
of
these artifacts with the test code that is already in place, so the built
artifacts will be tested to ensure their robustness.

Once this is complete, I think it should be technically feasible to roll
out
a (super pre-alpha) release suitable for end users, comprised of these
two
artifacts.

What I'm wondering is whether there is anything I need to do (in terms of
licensing, etc.) in order to publish a release?


<snip/>

Getting to a first release has some process overhead (subsequent
releases are relatively easier). At Commons, there can be no releases
of code in the Commons Sandbox. Code that is ready for release first
needs to be promoted to Commons Proper. This is done by a vote so the
promotion proposal needs enough support in the Commons PMC to pass a
vote.

Please read the following wiki page which mentions this in details
(particularly the promotion section):

   http://wiki.apache.org/commons/CommonsEtiquette

Having an Ant build is definitely quite an improvement, though if you
can add a Maven build (that uses the Commons Parent POM) you'll save
yourself a lot of effort in terms of getting the release artifacts
pass inspection here at Commons. Here is some information on the usual
process for creating releases at Commons (lets ignore the Nexus bits
for now):

   http://wiki.apache.org/commons/CreatingReleases

Releases must have a source distribution (at Commons, this is usually
a tagged copy of whats in SVN) and it must be possible to recreate the
release artifacts from that source.

My suggestion would be to get the build in shape such that its easily
possible to create the artifacts you mention and then move to the
proposal for promoting [scxml-js] out of the Commons Sandbox.

-Rahul



Let me know what you think. Thanks,

Jake


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

Reply via email to