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. Ralph 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: > http://wiki.apache.org/logging/Log4j2ReleaseGuide > > In fact we have an ASF maven pom: > http://svn.apache.org/viewvc/maven/pom/tags/apache-13/pom.xml > 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: > http://logging.apache.org > …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 <garydgreg...@gmail.com>: >>> >>> 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 <brit...@apache.org> >>>> wrote: >>>> >>>> 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 >>>> >>>> >>>> -- >>>> http://people.apache.org/~britter/ >>>> http://www.systemoutprintln.de/ >>>> http://twitter.com/BenediktRitter >>>> http://github.com/britter >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second >>> Edition<http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --- > http://www.grobmeier.de > @grobmeier > GPG: 0xA5CC90DB > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
