commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
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.

Gary

On Jun 22, 2013, at 8:53, sebb <sebbaz@gmail.com> wrote:

> On 22 June 2013 12:50, Benedikt Ritter <britter@apache.org> wrote:
>> 2013/6/22 Jörg Schaible <joerg.schaible@gmx.de>
>>
>>> Hi,
>>>
>>> sebb wrote:
>>>
>>>> On 22 June 2013 00:15, Phil Steitz <phil.steitz@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message