commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [ALL] Strategy for developer tools (was: [VOTE] Commons Staging Plugin - move to proper from sandbox)
Date Sat, 22 Jun 2013 13:45:16 GMT
I'm for whatever does the RM process easier and less error prone. If
that means maven plugins, so be it.


On Jun 22, 2013, at 8:53, sebb <> wrote:

> On 22 June 2013 12:50, Benedikt Ritter <> wrote:
>> 2013/6/22 Jörg Schaible <>
>>> Hi,
>>> 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.
>> 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:
>>> For additional commands, e-mail:
>> --
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message