On 8 October 2013 19:44, Christian Grobmeier <grobme...@gmail.com> 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
Or equally using the package / deploy manual version. > 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? If you are referring to staging for the release vote, then I agree, it's not necessary to use another area. But for formal ASF releases, these must be done via www.apache.org/dist/commons > One could see at as: we release source code, as we create a tag. For > convenience we put it on Nexus. Nothing else. No - Nexus is the only way to release components to Maven Central; it's not possible to publish jars to MC independently. (With good reason - there were several accidental 'releases' before Nexus was introduced). > 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. OK by me, so long as the ASF branding etc. requirements are met. > 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
