2013/6/22 Jörg Schaible <joerg.schai...@gmx.de> > Hi, > > sebb wrote: > > > On 22 June 2013 00:15, Phil Steitz <phil.ste...@gmail.com> wrote: > >> -0 > >> > >> I don't think this sort of things belongs in Commons proper as a > >> component. What we advertise, release and support from commons > >> proper are general purpose libraries that developers can use in > >> their own applications. This is what Commons was created for. > > > > Agreed. > > > >> While the staging plugin looks like a useful thing for internal > >> commons use, I don't see it as a general purpose component. I see > >> it like the download plugin > > > > Yes. > > > > In fact that was where I started - I wanted to see if it could be > > extended to support the extra Commons/ASF-specific requirements. > > > >> or commons parent. > > > > CP is somewhat different, because it's needed by Maven to build our > > software. > > > >> Perhaps what we > >> should do is formalize our policy to allow release of internal tools > >> so they can be grabbed from maven repos without actually promoting > >> them on the main commons web page or committing to support them for > >> external use. > > > > In the case of the existing commons build plugin, it is currently > > available from Maven Central. > > However the source is not published via the ASF mirror system - which > > is a requirement for ASF releases. > > I don't suppose it was ever announced outside Commons, so perhaps it > > does not count a s formal ASF release... > > > > Effectively we are using Maven Central as a shared Maven repo for > > Commons Developers, just a convenience in this case. > > > > Given that the existing commons build plugin and the proposed new > > staging plugin are only really useful for Commons (maybe other ASF) > > developers, is there is a need to release them to Maven Central at > > all? They are only needed occasionally, and generally only by RMs. > > > > I'm thinking maybe the plugins could just stay in a separate part of > > the Commons SVN tree. > > > > If an RM wanted to use the tool, they would need to check out that > > part of SVN and use "mvn install" to make the tool available from > > their local repository. [To avoid accidental deployment to Nexus, the > > release repo could be disabled for them] > > > > How does that sound? > > Bad. At least to me. Especially since we always claim that we actually > release the source and not necessarily the binaries. So every user that > downloads our source can no longer simply build it out of the box. This is > more than inconvenient. >
As far as I understand, the build plugins are only needed for release preparation. Building from source is possible without them. But I agree, having to build plugins required for a release from sources does seem to be cumbersome. > > Since we also claim that Maven central is *not* our primary area for > releases (we deploy there officially also just for user convenience), why > do > something different for our internally used plugins? > > > As to the website: > > > > The commons-build-plugin website is not currently linked from the main > > commons website (I don't think it ever was), but it would be useful to > > have it more easily available for developers (in particular those > > planning to RM!) > > Had I gone with extending the build plugin instead, obviously the new > > goals would have been documented there. > > But the site could be extended to cover any other developer tools. > > > > It could then be linked in to the main Commons website via a landing > > page that makes clear that these are developer tools only intended for > > supporting the specifc needs of Commons. The fact that the tools were > > only available by checking out SVN and installing locally would help > > reinforce this. > > I don't see a problem, if we make it clear, that we have no intent to > address other requirements for these plugins than our own special needs. > > > I realise that this would be slightly more work for developers. > > But a big advantage would be that new versions would be much simpler to > > prepare. At most a lazy vote would be needed. > > We should still use some form of version control - e.g. tags for > > different versions - otherwise things could get confusing. > > You have to use tagged versions, simply because you cannot release > something > with the release plugin, if snapshots are involved. This is also the case > for plugins. So to repeat an old release, everyone would have to check out > the proper version of our internal plugins and install it into hi slocal > repo? Sorry, but this does not make any sense. > > - Jörg > > I like the idea of treating build plugins in a special way. As Phil has pointed out, those plugins are not really part of our official portfolio. They are intended to be used for our release process only. Separating them from the proper components makes sense to me, because it communicates this intend very clearly. It's a good idea to allow plugins to be released by lazy consensus. This will speed things up. If a build plugin release is messed up, this should be noticed when it is sued for a proper release the first time. Having documentation for the plugins online also makes sense. I'm not sure if the website is the right place for this. I see the website primary as source of information for users. So maybe we can link build plugin sites in the wiki?! The wiki is the source of information about releasing components. As I've stated before, Jörg has a point. We want to ease the release process with those plugins. Having to check them out and install them the local repo may not be the best solution. Benedikt > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
