I'm for whatever does the RM process easier and less error prone. If that means maven plugins, so be it.
Gary On Jun 22, 2013, at 8:53, sebb <seb...@gmail.com> wrote: > On 22 June 2013 12:50, Benedikt Ritter <brit...@apache.org> wrote: >> 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. > > Of course, otherwise I would not have suggested using local repos. > >> But I agree, having to build plugins required for a release from sources >> does seem to be cumbersome. > > Only the RM has to do so, and they would only have to do so if they > want to use the features. > And they only have install the plugins once (per version). > > An RM can carry on publishing using the existing process if they wish. > Which is even more cumbersome. > > I agree it's not ideal, but I suggested using a local repo because it > seemed like a good compromise. > > AFAIK, there is no shared ASF repo (apart from snapshots, which is > obviously not suitable) that is not also published to Maven Central. > If there were, then it would be a better solution as RMs would just > need to add it to their repo list. > > But in the meantime, the plan does offer the potential to make releasing > easier. > > The alternative is to wait until Nexus supports dist/release publication. > But I cannot see that happening for a long time otherwise I would not > have started on this. > >>> >>> 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. > > Agreed. > >> 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 > > Freudian slip: sued => used! > >> first time. > > Yes. > >> >> 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. > > Yes, Wiki is another possibility. > >> >> 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. > > I agree, it's not the best solution. > > The ASF has particular requirements for source releases, however > these aren't currently supported by Maven tooling, nor by Nexus. > I tried very hard a year os so ago to get Nexus to support publishing > tarballs to dist/ as well as jars to Maven repo, but nothing came of > it. > > So I came up with an alternate solution using some new plugins. > >> >> 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 > > --------------------------------------------------------------------- > 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
