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? 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 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
