commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [DISCUSS] Why is releasing such a pain and what can we do to make it easier?
Date Wed, 09 Oct 2013 03:35:01 GMT
I wrote the Log4j2 wiki page just so I could remember and repeat the few manual steps I have
to do for each release. The difficulty is getting the bugs out of the first release.  Log4j
2 still has some difficulties though around its build process primarily because none of us
are OSGi experts and we know that what we are building isn't correct for that.  When you factor
in trying to build stuff so that it works in Google App Engine, Android, various JDK versions
and vendors then things start to become more difficult.  On that though, my attitude has always
been to build and test for the environments I use and let people who work in other environments
test and provide fixes for theirs, at least as much as possible. 

However, the primary goal of a release is to have a source distribution that meets the legal
obligations as stated by the ASF.  There is no requirement to build and ship binaries - we
do that as a convenience for our users and because we know we will get lots of complaints
if we don't.


On Oct 8, 2013, at 11:44 AM, Christian Grobmeier wrote:

> On 8 Oct 2013, at 20:07, Benedikt Ritter wrote:
>> Hey Gary,
>> you are involved in other projects (like log4j2) how do they do it? Is it easier
to release log4j2 than it is to release for example [lang]?
> Check this guide:
> In fact we have an ASF maven pom:
> This is extended by tons of plugins and other things and called "commons parent pom".
The commons parent pom does a lot of things, and all components are more or less required
to run the same way.
> The question is, why should a component not be independent from commons-parent-pom and
decide on it's on? With having the ASF-parent only releasing could be:
> mvn release:prepare release:perform
> Then everything should be on Nexus.
> I know this is a controverse question. But as people can download the artifacts directly
from nexus if they wish - including source, LICENSE, NOTICE and all that… why are we bothering
to put on any other place?
> One could see at as: we release source code, as we create a tag. For convenience we put
it on Nexus. Nothing else.
> For site: I think components should be free to chose on their own. I was thinking different
in the past. But now I believe we should just have a front page listing our components like
we have here:
> …and that site should link to the appropriate sub component site. How it looks or works
or how it is build should be decided by the component maintainers independently.
> Cheers
> Christian
>> Benedikt
>> Send from my mobile device
>>> Am 08.10.2013 um 19:52 schrieb Gary Gregory <>:
>>> IMO the problems are dealing with Nexus, a web site, and a 'dist'
>>> directory; that THREE things to get just right, none are 100% automated.
>>> With Nexus you have to do some manual steps. If you look at all the
>>> instructions for any commons component, it is long, a combo of manual and
>>> Maven+Nexus magic and error prone. It is not fun and a barrier.
>>> Gary
>>>> On Tue, Oct 8, 2013 at 12:46 PM, Benedikt Ritter <>
>>>> Hi,
>>>> one of the points that seem to always come up once in a while is the
>>>> process of releasing components. I've never done it myself so I'm asking
>>>> people who have done it:
>>>> What are the problems and how can we make releasing easier?
>>>> Is the complexity of the parent pom a problem? (Do we really need all the
>>>> stuff that is declared there?)
>>>> Is there a way to automate all the stuff that needs to be done in a
>>>> portable way?
>>>> Would it be possible to automate release for example on a Jenkins instance?
>>>> Benedikt
>>>> --
>>> --
>>> E-Mail: |
>>> Java Persistence with Hibernate, Second Edition<>
>>> JUnit in Action, Second Edition <>
>>> Spring Batch in Action <>
>>> Blog:
>>> Home:
>>> Tweet!
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---
> @grobmeier
> GPG: 0xA5CC90DB
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message