commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)
Date Sat, 22 Jun 2013 10:20:09 GMT

sebb wrote:

> On 22 June 2013 00:15, Phil Steitz <> 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.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message