Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.180 as permitted sender)
MIME-Version: 1.0
Date: Sun, 23 Jun 2013 13:46:06 +0100
Message-ID: 
 <CAOGo0VayQjjpx9-E6rE8hJr8hN4zbxYjS0D=+PFvgXrOzrmROg@mail.gmail.com>
Subject: Why is Commons different from Tomcat? (was [ALL] Strategy for
 developer tools)
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 22 June 2013 15:26, Mark Thomas <markt@apache.org> wrote:
> On 22/06/2013 14:45, Gary Gregory wrote:
>> I'm for whatever does the RM process easier and less error prone. If
>> that means maven plugins, so be it.
>
> This is written as someone who has never released a commons component
> and is very grateful for the folks that have done the release work for
> the components he has been involved in.
>
> I see various messages indicating how hard / complex / tricky / easy to
> get wrong doing a release is. The frequency of the messages does not
> appear to have changed significantly over time and they have been sent
> but both newcomers to the project and folks that were here long before I
> was.

I think that's partly that until fairly recently the site
documentation was seriously out of date.
It's a lot better now, but there are still various different versions
of the procedures around on the Wiki.

> I can't help but think that we must be doing something wrong. The Tomcat
> release process is a breeze. It takes me about 2 minutes actual work. It
> takes longer to upload the release artifacts for voting. And I spend
> even longer making sure I am happy with what I am about to tag.

Same for JMeter, which is Ant-based too.
However it took quite a while to update the Ant build file initially
and document how to use it.

> The obvious difference is that Tomcat is primarily an Ant based release
> process with a little bit of Maven to talk to Nexus whereas the Commons
> releases are primarily (wholly?) Maven based.

There's another differerence which is that both Tomcat and JMeter are
basically single products.
Any addons to the build file can be made once and are then carried
around with the product.
So once a developer has checked out the source, they have everything they need.
There's no need for a separate shared repository.

But of course Tomcat and JMeter both had to develop the addons independently.
That does not scale in Commons.

> However, I can't believe
> that this is a tools issue. If everyone found Maven this hard to release
> software with, no-one would be using it and it is clearly popular. That
> begs the question: what are we doing wrong? Why do releases appear to be
> much more difficult than they should be?

Maven + Nexus  works very well for staging and releasing jars to the
Maven repository.

Maven can also easily assemble tarballs, but AFAIK it does not have
any tools to upload them anywhere except Nexus or the local repo. Nor
does it have tools for signing or hashing files that are not part of
the project.

Which is where the Commons issue lies and why it's not an issue for Tomcat.

As I see it we need to add tools + configuration to do one of the following:
- extract tarballs from Nexus after voting and copy/move to dist/release
- extract tarballs from Nexus before voting and stage to dist/dev
- handle tarballs separately so they don't end up in Nexus; add
sigs+hashes and stage to dist/dev

In the last two cases there's also a need for a tool to move tarballs
from dist/dev to dist/release

The last approach is basically what Tomcat and JMeter do, and what the
plugins were intended to facilitate.

> I don't have answers neither do I have the Maven knowledge I suspect is
> necessary to figure the answers out. I encourage those that do have the
> Maven skills to put on their thinking caps.

If there are existing Maven tools that allow full automation of any of
the above approaches it would be good to know. I looked but did not
find.

I suspect something new will need to be written whichever approach is taken.

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

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