maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

The jars in the incubator repository are official incubator releases.
Therefore distributing them from people.apache.org is against apache
policy. The move to distribute other forms of release from
www.apache.org/dist/ seems go have gone well. So I think we need to
consider the future of the maven repository.

It would be possible to create an incubator only repository in a
subdirectory www.apache.org/dist/incubator/maven, say. Or we could
just simplify everything by allowing incubator projects to use the
standard repository.Opinions?

Robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Thilo Goetz wrote:

> One might argue that incubator releases go through a very
> thorough release screening process

So what?  The issue isn't code quality.  Incubator projects are not part of
the ASF, yet.  It is due to arguments like yours that some people have
proposed removing the Incubator from the ASF, and having it as a separate
entity.  We do not give the ASF imprimatur to projects still in the
Incubator.  If they were ready to be official ASF projects, they'd not still
be here.

> and there's no reason to make them so hard to get afterwards

Yes there is.  I wish we could make it a bit harder, actually, and force the
individual maven end user to explicitly accept that they are willing to use
an Incubator artifact.  As it is, the best we can do appears to use a
separate repository.

> certainly not from the point of view of the incubating projects who're
> trying to build community around their code.

We care about a growing developer community, and developers ought to be able
to handle the extra step of adding a new repository to Maven.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Thilo Goetz <tw...@gmx.de>]

Craig L Russell wrote:
> 
> On May 15, 2008, at 4:34 AM, Robert Burrell Donkin wrote:
> 
>> On Thu, May 15, 2008 at 8:04 AM, Brett Porter <br...@gmail.com> 
>> wrote:
>>> 2008/5/15 Robert Burrell Donkin <ro...@gmail.com>:
>>>> It would be possible to create an incubator only repository in a
>>>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>>>> just simplify everything by allowing incubator projects to use the
>>>> standard repository.Opinions?
>>>
>>> http://people.apache.org/repo/m2-incubating-repository/
> 
> IIUC, there are two differences between an incubating project depositing 
> its artifacts into a special incubating repository versus the standard:
> 
> 1. The incubating repository is not mirrored to the world, so incubating 
> artifacts don't pollute the maven-o-sphere.
> 
> 2. The incubating repository needs to be added to the maven remote repo 
> definition of each project that wants to depend on an incubating artifact.
> 
> I think both of these have minor positive effects. So I'm really +0.3 on 
> using a special incubating repository.

That's where opinions differ on whether this is a positive
effect.  One might argue that incubator releases go through
a very thorough release screening process, and there's no
reason to make them so hard to get afterwards; certainly
not from the point of view of the incubating projects who're
trying to build community around their code.

--Thilo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[sebb <se...@gmail.com>]

On 02/06/2008, Henri Yandell <fl...@gmail.com> wrote:
> On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <no...@devtech.com> wrote:
>  > Henri Yandell wrote:
>  >
>  >> Noel J. Bergman wrote:
>  >> > I really do not know why we have to revisit this same topic year after
>  > year
>  >> > after year.  We do not want people to be using any Incubator artifact
>  >> > without explicit knowledge and action, so we do not want them polluting
>  > the
>  >> > standard repository.
>  >
>  >> And as with every year I'll call "BS" :)
>  >
>  >> We do want people to use them, and we do want them on the standard
>  >> repository. They are releases.
>  >
>  > They are *Incubator* releases.  And we do care that people are aware of that
>  > status.  You are free to try to convince the Board and/or Membership to
>  > change the Incubator's mandate, but until then that is the issue.
>
>
> Where is that mandate defined? I see nothing in the original
>  resolution to imply this. To my understanding, treating Incubator
>  podlings differently from Apache subprojects is an invention of the
>  Incubator PMC.
>
>
>  > We want awareness and consent by the end-user, not "hinderance."  This is
>  > analogous to the multiverse repository (or even a PPA repository), vs main
>  > and security in Ubuntu-land.  A user must explicitly choose to allow
>  > artifacts found in repositories other than main and security.  There are
>  > disclaimers associated with the repositories.
>
>
> Not a great analogy though.
>
>  Main = central.
>
>  Project A is in central. It goes to Apache. It can no longer be in
>  central because it is no longer a trusted project until Apache bless
>  it. It's a nuts policy.

It's no longer the same project.

The original project can stay in central.

Once the project has been rebranded as ASF and passed through the
other changes required by the incubation process it can go back into
central as the new project.

>  Project B does not exist and is being created. Anywhere else, it goes
>  into central. At Apache, it has to sit it out in its own sandbox
>  waiting to be considered acceptable.

Which is one reason why the ASF brand is more trusted than some.

>  That's if it is created in the
>  Incubator (or a previously private project that is going public via
>  the Incubator), or if it is in Labs where any releases have to happen
>  outside of Apache as they can't happen inside, but not if it is a new
>  subproject to an existing Apache project.
>
>  We cut off our nose to spite our face.

I don't see it that way.

I see it as protecting the ASF name.

>
>  > FWIW, I agree with James that we would use signing to be more fine-grained,
>  > but didn't want to go into that degree of detail in the earlier discussion.
>  >
>  >> If the nays get their way though - the solution is easy. Release your
>  >> incubating release outside the ASF and get it sync'd from there to the
>  >> central repository.
>  >
>  > Before suggesting that projects intentionally circumvent ASF procedure, you
>  > might want to discuss that with Justin and/or Dave Johnson, since they spent
>  > a lot of time dealing with it for Roller.
>
>
> I seem to remember spending a lot of time on it too - it had nothing
>  to do with this issue but with the fact that it wanted to include an
>  LGPL dependency. The solution was the same, release outside the ASF
>  until it passes the ASF bar - the difference is that this thread
>  claims there is a bar on ASF releases beyond the legal policies and
>  the 3 +1s.
>
>  Hen
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Henri Yandell <fl...@gmail.com>]

On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Henri Yandell wrote:
>
>> Noel J. Bergman wrote:
>> > I really do not know why we have to revisit this same topic year after
> year
>> > after year.  We do not want people to be using any Incubator artifact
>> > without explicit knowledge and action, so we do not want them polluting
> the
>> > standard repository.
>
>> And as with every year I'll call "BS" :)
>
>> We do want people to use them, and we do want them on the standard
>> repository. They are releases.
>
> They are *Incubator* releases.  And we do care that people are aware of that
> status.  You are free to try to convince the Board and/or Membership to
> change the Incubator's mandate, but until then that is the issue.

Where is that mandate defined? I see nothing in the original
resolution to imply this. To my understanding, treating Incubator
podlings differently from Apache subprojects is an invention of the
Incubator PMC.

> We want awareness and consent by the end-user, not "hinderance."  This is
> analogous to the multiverse repository (or even a PPA repository), vs main
> and security in Ubuntu-land.  A user must explicitly choose to allow
> artifacts found in repositories other than main and security.  There are
> disclaimers associated with the repositories.

Not a great analogy though.

Main = central.

Project A is in central. It goes to Apache. It can no longer be in
central because it is no longer a trusted project until Apache bless
it. It's a nuts policy.

Project B does not exist and is being created. Anywhere else, it goes
into central. At Apache, it has to sit it out in its own sandbox
waiting to be considered acceptable. That's if it is created in the
Incubator (or a previously private project that is going public via
the Incubator), or if it is in Labs where any releases have to happen
outside of Apache as they can't happen inside, but not if it is a new
subproject to an existing Apache project.

We cut off our nose to spite our face.

> FWIW, I agree with James that we would use signing to be more fine-grained,
> but didn't want to go into that degree of detail in the earlier discussion.
>
>> If the nays get their way though - the solution is easy. Release your
>> incubating release outside the ASF and get it sync'd from there to the
>> central repository.
>
> Before suggesting that projects intentionally circumvent ASF procedure, you
> might want to discuss that with Justin and/or Dave Johnson, since they spent
> a lot of time dealing with it for Roller.

I seem to remember spending a lot of time on it too - it had nothing
to do with this issue but with the fact that it wanted to include an
LGPL dependency. The solution was the same, release outside the ASF
until it passes the ASF bar - the difference is that this thread
claims there is a bar on ASF releases beyond the legal policies and
the 3 +1s.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

James Carman wrote:

> Noel J. Bergman wrote:
> > FWIW, I agree with James that we would use signing to be more
fine-grained,
> > but didn't want to go into that degree of detail in the earlier
discussion.
> I apologize for being so verbose.  This is probably not the correct
> forum to discuss those changes at that level of detail.

No need to apologize.  As I said, I agree with you.  I just didn't want to
delve into details when we don't even have support from Maven, yet.  :-)

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Sun, Jun 1, 2008 at 11:59 AM, Noel J. Bergman <no...@devtech.com> wrote:

> FWIW, I agree with James that we would use signing to be more fine-grained,
> but didn't want to go into that degree of detail in the earlier discussion.
>

I apologize for being so verbose.  This is probably not the correct
forum to discuss those changes at that level of detail.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 10:20 PM, Henri Yandell <fl...@gmail.com> wrote:

<snip>

> To Robert's comment of:
>
> "it has now been clearly established that we need to move
> therepository. we're now just asking: where?"
>
> I question that. We voted at the last time, and it was very clear
> there was no consensus to hinder incubator releases. Generally the
> difference was that those committing to Incubator projects didn't want
> to hinder, while those not committing did.

the incubator needs to comply with infrastructure rules: the maven
repository used by the incubator is in the wrong place

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Henri Yandell wrote:

> Noel J. Bergman wrote:
> > I really do not know why we have to revisit this same topic year after
year
> > after year.  We do not want people to be using any Incubator artifact
> > without explicit knowledge and action, so we do not want them polluting
the
> > standard repository.

> And as with every year I'll call "BS" :)

> We do want people to use them, and we do want them on the standard
> repository. They are releases.

They are *Incubator* releases.  And we do care that people are aware of that
status.  You are free to try to convince the Board and/or Membership to
change the Incubator's mandate, but until then that is the issue.

We want awareness and consent by the end-user, not "hinderance."  This is
analogous to the multiverse repository (or even a PPA repository), vs main
and security in Ubuntu-land.  A user must explicitly choose to allow
artifacts found in repositories other than main and security.  There are
disclaimers associated with the repositories.

FWIW, I agree with James that we would use signing to be more fine-grained,
but didn't want to go into that degree of detail in the earlier discussion.

> If the nays get their way though - the solution is easy. Release your
> incubating release outside the ASF and get it sync'd from there to the
> central repository.

Before suggesting that projects intentionally circumvent ASF procedure, you
might want to discuss that with Justin and/or Dave Johnson, since they spent
a lot of time dealing with it for Roller.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Henri Yandell <fl...@gmail.com>]

On Thu, May 29, 2008 at 4:53 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Jukka Zitting wrote:
>> Craig L Russell wrote:
>> > 1. The incubating repository is not mirrored to the world, so incubating
>> > artifacts don't pollute the maven-o-sphere.
>
>> What's so bad about incubating artifacts that would "pollute" things?
>> We are perfectly happy distributing them on www.apache.org and all our
>> mirrors, so why not repo1.maven.org?
>
> I really do not know why we have to revisit this same topic year after year
> after year.  We do not want people to be using any Incubator artifact
> without explicit knowledge and action, so we do not want them polluting the
> standard repository.

And as with every year I'll call "BS" :)

We do want people to use them, and we do want them on the standard
repository. They are releases.


To Robert's comment of:

"it has now been clearly established that we need to move
therepository. we're now just asking: where?"

I question that. We voted at the last time, and it was very clear
there was no consensus to hinder incubator releases. Generally the
difference was that those committing to Incubator projects didn't want
to hinder, while those not committing did.

If the nays get their way though - the solution is easy. Release your
incubating release outside the ASF and get it sync'd from there to the
central repository. There is nothing to stop that, the license allows
you to redistribute and there is a very strong history of
redistributors not having to rename the packages/products unless they
strongly fork.

While it's just one vote, you have my -1 to adding unnecessary crap to
releasing from the incubator.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <no...@devtech.com> wrote:

> End users don't read the POM.  They just use it.  So that is no solution at
> all.  The signing approach would be, IMO, a reasonable solution.  It would
> solve Les' issue -- users would simply have to agree to install the
> Incubator-signed artifact(s), and thereafter they'd be fine.
>

Users do use the code, though.  Putting the code in an "incubating"
package (for Java-based projects) does make them aware that they're
using an incubating library.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Robert Burrell Donkin <ro...@gmail.com>]

On 6/3/08, Gilles Scokart <gs...@gmail.com> wrote:
> I thought this thread started with the idea : if maven would be able
> to validate signature, we could use this feature to inform someone
> that he is using incubator artefacts.
> I thought the idea that launched this thread was to have a unique key
> for the incubator that the user has as to trust if he want to use
> incubator artefacts.

Stated like that then the artifact would need to be encrypted
> My question was in that context.

AIUI maven decided against enforcing download verification. So
requires the maven team developing this feature first.

Robert
>
> 2008/6/2 Noel J. Bergman <no...@devtech.com>:
>> Gilles Scokart wrote:
>>
>>> Noel J. Bergman:
>>> > Implement that, and we're fine.  We will
>>> > require Incubator artifacts to be signed by a designated key available
>> to
>>> > the PMC, and once a user has acknowledged that they accept such
>> Incubator
>>> > signed artifacts, maven can do what it wants with them.
>>>
>>>        --- Noel
>>
>>> Is that really possible?
>>
>> Very.
>>
>>> I remember some discussion on the infra list about an ASF wide signature.
>>> And the conclusion was always the same: how to secure a key that can be
>>> used by so many people.  If I remember well, some solution were proposed,
>>> but they were quiet heavy.  Do we have a solution for that?
>>
>> There are various things that can be done with respect to key management.
>> Personally, I would not go with a single key.  But maven ought to maintain
>> a
>> trust file, with options to accept files that are signed with a trusted
>> key,
>> or signed by a key that is signed by a trusted key, etc.  The first thing
>> that has to happen is for the Maven PMC to make security a priority.
>>
>>        --- Noel
>>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Gilles Scokart <gs...@gmail.com>]

I thought this thread started with the idea : if maven would be able
to validate signature, we could use this feature to inform someone
that he is using incubator artefacts.
I thought the idea that launched this thread was to have a unique key
for the incubator that the user has as to trust if he want to use
incubator artefacts.

My question was in that context.



2008/6/2 Noel J. Bergman <no...@devtech.com>:
> Gilles Scokart wrote:
>
>> Noel J. Bergman:
>> > Implement that, and we're fine.  We will
>> > require Incubator artifacts to be signed by a designated key available
> to
>> > the PMC, and once a user has acknowledged that they accept such
> Incubator
>> > signed artifacts, maven can do what it wants with them.
>>
>>        --- Noel
>
>> Is that really possible?
>
> Very.
>
>> I remember some discussion on the infra list about an ASF wide signature.
>> And the conclusion was always the same: how to secure a key that can be
>> used by so many people.  If I remember well, some solution were proposed,
>> but they were quiet heavy.  Do we have a solution for that?
>
> There are various things that can be done with respect to key management.
> Personally, I would not go with a single key.  But maven ought to maintain a
> trust file, with options to accept files that are signed with a trusted key,
> or signed by a key that is signed by a trusted key, etc.  The first thing
> that has to happen is for the Maven PMC to make security a priority.
>
>        --- Noel
>

-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Robert Burrell Donkin <ro...@gmail.com>]

On 6/2/08, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> my conclusion was that meta-data signed by [keys in the] WoT would be good
> enough.
>
>> there's no need to distribute a master key
>
> +1
>
>> key management is tricky
>
> Not that tricky.  Let's not make as if this isn't done routinely elsewhere.

>> this is where the complexity lies. IIRC it was quite tough to come up
>> with a user friendly trust model that worked correctly.
>
> Not so much, seeing as how you just agreed with CLR:
>
>> For example, "trust all unsigned", "trust all signed", "trust all signed
> in
>> Apache WOT" might be reasonable policies declared by the user.
IMHO these are all reasonable policies. But users are used to thinking
in black and white. They want software just to work.

>> we don't actually require that the artifacts are signed: just
>> meta-data about the artifacts
>
> What do you think a signature is in the first place?  It is a digitally
> encrypted hash, i.e., meta-data.
The idea is that you sign finely grained domain specific meta-data.
For example, I would not be willing to sign a key unless I've met the
owner F2F but I would be willing to sign meta-data linking a key to an
incubator project.

Robert

>
> 	--- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Noel J. Bergman" <no...@devtech.com>]

Robert Burrell Donkin wrote:

> my conclusion was that meta-data signed by [keys in the] WoT would be good
enough.

> there's no need to distribute a master key

+1

> key management is tricky

Not that tricky.  Let's not make as if this isn't done routinely elsewhere.

> this is where the complexity lies. IIRC it was quite tough to come up
> with a user friendly trust model that worked correctly.

Not so much, seeing as how you just agreed with CLR:

> For example, "trust all unsigned", "trust all signed", "trust all signed
in
> Apache WOT" might be reasonable policies declared by the user.

> we don't actually require that the artifacts are signed: just
> meta-data about the artifacts

What do you think a signature is in the first place?  It is a digitally
encrypted hash, i.e., meta-data.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Jun 2, 2008 at 7:29 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> Noel J. Bergman wrote:
>>
>> Gilles Scokart wrote:
>>
>>> Noel J. Bergman:
>>>>
>>>> Implement that, and we're fine.  We will
>>>> require Incubator artifacts to be signed by a designated key available
>>
>> to
>>>>
>>>> the PMC, and once a user has acknowledged that they accept such
>>
>> Incubator
>>>>
>>>> signed artifacts, maven can do what it wants with them.
>>>
>>>       --- Noel
>>
>>> Is that really possible?
>>
>> Very.
>
> Why is it not equally possible to validate against a short list of keys
> (e.g. infra PMC members) and their immediate trust.  This is what gpg is
> good at.

the short answer is not quite (trust models are too different). my
conclusion was that meta-data signed by a short list of keys in the
WoT would be good enough.

>>> I remember some discussion on the infra list about an ASF wide signature.
>>> And the conclusion was always the same: how to secure a key that can be
>>> used by so many people.  If I remember well, some solution were proposed,
>>> but they were quiet heavy.  Do we have a solution for that?

there's no need to distribute a master key

>> There are various things that can be done with respect to key management.

key management is tricky

>> Personally, I would not go with a single key.  But maven ought to maintain
>> a
>> trust file, with options to accept files that are signed with a trusted
>> key,
>> or signed by a key that is signed by a trusted key, etc.

this is where the complexity lies. IIRC it was quite tough to come up
with a user friendly trust model that worked correctly.

>>  The first thing
>> that has to happen is for the Maven PMC to make security a priority.
>
> As far as signing jars, microsoft authenticode etc, Noel and I planned to
> create such a service (although we've both been really busy in the past few
> months).  But it will always require that the artifacts are already signed
> by someone in the ASF's web-of-trust via pgp.

we don't actually require that the artifacts are signed: just
meta-data about the artifacts

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Noel J. Bergman" <no...@devtech.com>]

William A. Rowe, Jr. wrote:

> Why is it not equally possible to validate against a short list of keys
> (e.g. infra PMC members) and their immediate trust.  This is what gpg is
> good at.

First get the code built into Maven for actually checking the signatures and we're golden, with multiple options.

> As far as signing jars, microsoft authenticode etc, Noel and I planned to
> create such a service (although we've both been really busy in the past few
> months).  But it will always require that the artifacts are already signed
> by someone in the ASF's web-of-trust via pgp.

I've been wondering when you'd come back to life, but you may have been waiting for me.  I actually had time the past week.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Noel J. Bergman wrote:
> Gilles Scokart wrote:
> 
>> Noel J. Bergman:
>>> Implement that, and we're fine.  We will
>>> require Incubator artifacts to be signed by a designated key available
> to
>>> the PMC, and once a user has acknowledged that they accept such
> Incubator
>>> signed artifacts, maven can do what it wants with them.
>>        --- Noel
> 
>> Is that really possible?
> 
> Very.

Why is it not equally possible to validate against a short list of keys
(e.g. infra PMC members) and their immediate trust.  This is what gpg is
good at.

>> I remember some discussion on the infra list about an ASF wide signature.
>> And the conclusion was always the same: how to secure a key that can be
>> used by so many people.  If I remember well, some solution were proposed,
>> but they were quiet heavy.  Do we have a solution for that?
> 
> There are various things that can be done with respect to key management.
> Personally, I would not go with a single key.  But maven ought to maintain a
> trust file, with options to accept files that are signed with a trusted key,
> or signed by a key that is signed by a trusted key, etc.  The first thing
> that has to happen is for the Maven PMC to make security a priority.

As far as signing jars, microsoft authenticode etc, Noel and I planned to
create such a service (although we've both been really busy in the past few
months).  But it will always require that the artifacts are already signed
by someone in the ASF's web-of-trust via pgp.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Noel J. Bergman" <no...@devtech.com>]

Gilles Scokart wrote:

> Noel J. Bergman:
> > Implement that, and we're fine.  We will
> > require Incubator artifacts to be signed by a designated key available
to
> > the PMC, and once a user has acknowledged that they accept such
Incubator
> > signed artifacts, maven can do what it wants with them.
>
>        --- Noel

> Is that really possible?

Very.

> I remember some discussion on the infra list about an ASF wide signature.
> And the conclusion was always the same: how to secure a key that can be
> used by so many people.  If I remember well, some solution were proposed,
> but they were quiet heavy.  Do we have a solution for that?

There are various things that can be done with respect to key management.
Personally, I would not go with a single key.  But maven ought to maintain a
trust file, with options to accept files that are signed with a trusted key,
or signed by a key that is signed by a trusted key, etc.  The first thing
that has to happen is for the Maven PMC to make security a priority.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Gilles Scokart <gs...@gmail.com>]

2008/5/31 Noel J. Bergman <no...@devtech.com>:

> Implement that, and we're fine.  We will
> require Incubator artifacts to be signed by a designated key available to
> the PMC, and once a user has acknowledged that they accept such Incubator
> signed artifacts, maven can do what it wants with them.
>
>        --- Noel
>

Is that really possible?  I remember some discussion on the infra list
about an ASF wide signature.  And the conclusion was always the same :
how to secure a key that can be used by so many people.  If I remember
well, some solution were proposed, but they were quiet heavy.
Do we have a solution for that?



-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Noel J. Bergman" <no...@devtech.com>]

Brian E. Fox wrote:

> I think this thread belongs on the Maven lists as it's is only
> tangential to the decision about the incubator repository.

Well, that's not entirely true.  It is rather key to a satisfactory
resolution, with the possible exception of some interim measure.

> The process for getting new features included is to write a proposal and
> put it on the wiki [1]

> [1] https://docs.codehaus.org/display/MAVENUSER/User+Proposals

Important project content is being maintained on non-ASF infrastructure?

> and then email the dev list to begin a discussion. There are some good
ideas here
> but they need to be flushed out by the Maven community as a whole.

Feel free.  Personally, I'll be pleasantly surprised if anything comes of
it, because no one in Maven-land seems to consider security seriously --- or
even at all.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Brian E. Fox" <br...@reply.infinity.nu>]

I think this thread belongs on the Maven lists as it's is only
tangential to the decision about the incubator repository. 

The process for getting new features included is to write a proposal and
put it on the wiki [1] and then email the dev list to begin a
discussion. There are some good ideas here but they need to be flushed
out by the Maven community as a whole.


[1] https://docs.codehaus.org/display/MAVENUSER/User+Proposals

-----Original Message-----
From: Robert Burrell Donkin [mailto:robertburrelldonkin@gmail.com] 
Sent: Monday, June 02, 2008 2:40 PM
To: general@incubator.apache.org
Subject: Re: enforced signing of artifacts, [was maven repository]

On Sat, May 31, 2008 at 8:11 PM, Craig L Russell <Cr...@sun.com>
wrote:
>
> On May 30, 2008, at 10:33 PM, Robert Burrell Donkin wrote:
>
>> On Sat, May 31, 2008 at 3:42 AM, Brett Porter
<br...@gmail.com>
>> wrote:
>>>
>>> 2008/5/31 Brian E. Fox <br...@reply.infinity.nu>:
>>>>
>>>> Can you elaborate more on what you mean here? I've been on the
Maven PMC
>>>> for over a year now and this is the first I've heard of it.
>>>>
>>>> We do support signing of artifacts and all the maven releases are
>>>> signed. We obviously don't control all the other Apache projects in
a
>>>> way to enforce that they sign their artifacts.
>>>
>>> Noel is referring to enforcing checking signatures, not signing
them.
>>> I've had a proposal out there for some time which anyone is free to
>>> comment on:
http://docs.codehaus.org/display/MAVEN/Repository+Security
>>>
>>> There hasn't been a lot of traction behind it so far. Ease of use,
>>> especially OOTB, is probably one of the main concerns.
>>
>> IMO this isn't really a maven issue: basic checks should be performed
>> on all releases. i favour a private subversion repository with custom
>> hooks for release publishing.
>
> I think that maven basically changes the equation, since it is
responsible
> for automatically downloading artifacts, and this feature is a huge
> usability win. I think that currently, usability trumps security.
>
> Since maven automatically downloads artifacts, it's technically
feasible for
> maven to verify the signatures of those artifacts and allow for
control by
> the user over whether or not to trust the artifacts.
>
> For example, "trust all unsigned", "trust all signed", "trust all
signed in
> Apache WOT" might be reasonable policies declared by the user.

+1

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 8:11 PM, Craig L Russell <Cr...@sun.com> wrote:
>
> On May 30, 2008, at 10:33 PM, Robert Burrell Donkin wrote:
>
>> On Sat, May 31, 2008 at 3:42 AM, Brett Porter <br...@gmail.com>
>> wrote:
>>>
>>> 2008/5/31 Brian E. Fox <br...@reply.infinity.nu>:
>>>>
>>>> Can you elaborate more on what you mean here? I've been on the Maven PMC
>>>> for over a year now and this is the first I've heard of it.
>>>>
>>>> We do support signing of artifacts and all the maven releases are
>>>> signed. We obviously don't control all the other Apache projects in a
>>>> way to enforce that they sign their artifacts.
>>>
>>> Noel is referring to enforcing checking signatures, not signing them.
>>> I've had a proposal out there for some time which anyone is free to
>>> comment on: http://docs.codehaus.org/display/MAVEN/Repository+Security
>>>
>>> There hasn't been a lot of traction behind it so far. Ease of use,
>>> especially OOTB, is probably one of the main concerns.
>>
>> IMO this isn't really a maven issue: basic checks should be performed
>> on all releases. i favour a private subversion repository with custom
>> hooks for release publishing.
>
> I think that maven basically changes the equation, since it is responsible
> for automatically downloading artifacts, and this feature is a huge
> usability win. I think that currently, usability trumps security.
>
> Since maven automatically downloads artifacts, it's technically feasible for
> maven to verify the signatures of those artifacts and allow for control by
> the user over whether or not to trust the artifacts.
>
> For example, "trust all unsigned", "trust all signed", "trust all signed in
> Apache WOT" might be reasonable policies declared by the user.

+1

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Craig L Russell <Cr...@Sun.COM>]

On May 30, 2008, at 10:33 PM, Robert Burrell Donkin wrote:

> On Sat, May 31, 2008 at 3:42 AM, Brett Porter  
> <br...@gmail.com> wrote:
>> 2008/5/31 Brian E. Fox <br...@reply.infinity.nu>:
>>> Can you elaborate more on what you mean here? I've been on the  
>>> Maven PMC
>>> for over a year now and this is the first I've heard of it.
>>>
>>> We do support signing of artifacts and all the maven releases are
>>> signed. We obviously don't control all the other Apache projects  
>>> in a
>>> way to enforce that they sign their artifacts.
>>
>> Noel is referring to enforcing checking signatures, not signing them.
>> I've had a proposal out there for some time which anyone is free to
>> comment on: http://docs.codehaus.org/display/MAVEN/Repository 
>> +Security
>>
>> There hasn't been a lot of traction behind it so far. Ease of use,
>> especially OOTB, is probably one of the main concerns.
>
> IMO this isn't really a maven issue: basic checks should be performed
> on all releases. i favour a private subversion repository with custom
> hooks for release publishing.

I think that maven basically changes the equation, since it is  
responsible for automatically downloading artifacts, and this feature  
is a huge usability win. I think that currently, usability trumps  
security.

Since maven automatically downloads artifacts, it's technically  
feasible for maven to verify the signatures of those artifacts and  
allow for control by the user over whether or not to trust the  
artifacts.

For example, "trust all unsigned", "trust all signed", "trust all  
signed in Apache WOT" might be reasonable policies declared by the user.

Craig
>
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: enforced signing of artifacts, [was maven repository]

[James Carman <ja...@carmanconsulting.com>]

On Sat, May 31, 2008 at 9:05 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Sat, May 31, 2008 at 1:33 AM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>
>> IMO this isn't really a maven issue: basic checks should be performed
>> on all releases. i favour a private subversion repository with custom
>> hooks for release publishing.
>
> I think it very much is a maven issue.  Maven is the tool that
> automatically downloads jar files from the public repository
> automagically (I love that by the way).  If there were a setting in
> maven that I could set that says "don't add anything to my local maven
> repository that isn't signed by someone that I trust", then I think we
> would be good here.  I don't know if I'd make it a required feature,
> though.  I think making it optional would be okay.  Maven should also
> ask you if you want to trust a signer if it hasn't seen it before
> (kind of like how webstart does).  Perhaps it could be a three-choice
> setting:
>
> 1.  Allow any jars from the central repository.
> 2.  Ask me before allowing jars from someone I haven't specifically
> trusted before.
> 3.  Don't allow any jars signed by people I do not trust.
>
> This, of course, would mean that we should probably set up a release
> signing committee so that we only use one signing key from the ASF
> (users shouldn't have to say that they trust jars signed by me, and
> Robert, and Brett, and Noel).  The members of the committee would be
> the only ones with write access to the maven rsync directory.  The
> requests could be set up in JIRA or something (hopefully there would
> be a committee member on each PMC).

I guess we would probably want to set up a signing key for each PMC.
Since saying that I approve of using releases from one podling doesn't
necessarily mean I approve of using releases from another podling.
For example, I may trust JSecurity if I am a long-time user of it, but
I don't trust Imperius, because I don't know what the heck it is.
Once a podling graduates, would we need to generate a new signing key
for it (without the "incubating")?

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[James Carman <ja...@carmanconsulting.com>]

On Sat, May 31, 2008 at 1:33 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:

> IMO this isn't really a maven issue: basic checks should be performed
> on all releases. i favour a private subversion repository with custom
> hooks for release publishing.

I think it very much is a maven issue.  Maven is the tool that
automatically downloads jar files from the public repository
automagically (I love that by the way).  If there were a setting in
maven that I could set that says "don't add anything to my local maven
repository that isn't signed by someone that I trust", then I think we
would be good here.  I don't know if I'd make it a required feature,
though.  I think making it optional would be okay.  Maven should also
ask you if you want to trust a signer if it hasn't seen it before
(kind of like how webstart does).  Perhaps it could be a three-choice
setting:

1.  Allow any jars from the central repository.
2.  Ask me before allowing jars from someone I haven't specifically
trusted before.
3.  Don't allow any jars signed by people I do not trust.

This, of course, would mean that we should probably set up a release
signing committee so that we only use one signing key from the ASF
(users shouldn't have to say that they trust jars signed by me, and
Robert, and Brett, and Noel).  The members of the committee would be
the only ones with write access to the maven rsync directory.  The
requests could be set up in JIRA or something (hopefully there would
be a committee member on each PMC).

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 3:42 AM, Brett Porter <br...@gmail.com> wrote:
> 2008/5/31 Brian E. Fox <br...@reply.infinity.nu>:
>> Can you elaborate more on what you mean here? I've been on the Maven PMC
>> for over a year now and this is the first I've heard of it.
>>
>> We do support signing of artifacts and all the maven releases are
>> signed. We obviously don't control all the other Apache projects in a
>> way to enforce that they sign their artifacts.
>
> Noel is referring to enforcing checking signatures, not signing them.
> I've had a proposal out there for some time which anyone is free to
> comment on: http://docs.codehaus.org/display/MAVEN/Repository+Security
>
> There hasn't been a lot of traction behind it so far. Ease of use,
> especially OOTB, is probably one of the main concerns.

IMO this isn't really a maven issue: basic checks should be performed
on all releases. i favour a private subversion repository with custom
hooks for release publishing.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: enforced signing of artifacts, [was maven repository]

[Brett Porter <br...@gmail.com>]

2008/5/31 Brian E. Fox <br...@reply.infinity.nu>:
> Can you elaborate more on what you mean here? I've been on the Maven PMC
> for over a year now and this is the first I've heard of it.
>
> We do support signing of artifacts and all the maven releases are
> signed. We obviously don't control all the other Apache projects in a
> way to enforce that they sign their artifacts.

Noel is referring to enforcing checking signatures, not signing them.
I've had a proposal out there for some time which anyone is free to
comment on: http://docs.codehaus.org/display/MAVEN/Repository+Security

There hasn't been a lot of traction behind it so far. Ease of use,
especially OOTB, is probably one of the main concerns.

- Brett

-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: enforced signing of artifacts, [was maven repository]

["Noel J. Bergman" <no...@devtech.com>]

Brian E. Fox wrote:

> > I really don't care what cuts across the grain of Maven.  I do care
> > about the established principle that people must make a deliberate
> > decision to use Incubator artifacts.  If Maven would finally support
> > enforcing signing of artifacts, as they have been asked to do for
> > years, we could use an Incubator-specific signing key, forcing
> > people to approve the use of Incubator artifacts, regardless of
> > download location.

> Can you elaborate more on what you mean here? I've been on the
>  Maven PMC for over a year now and this is the first I've heard of it.

Ask some of the old(er)-timers on the PMC.  They have heard this from
multiple channels over a period of years, both because of the Incubator's
needs and the security aspect.  On the latter, there have been instances of
supposedly ASF released code being put into the repositories by effectively
rogue developers.  Responsible users of Maven don't use unsecured, unvetted,
public repositories; they manually vet and approve artifacts, and maintain
their own local repositories.

> We do support signing of artifacts and all the maven releases are
> signed.  We obviously don't control all the other Apache projects
> in a way to enforce that they sign their artifacts.

The ASF can enforce that policy for all published artifacts.  But Maven does
not require that artifacts be signed *AND* require that the user running the
maven build APPROVE the signer.  Implement that, and we're fine.  We will
require Incubator artifacts to be signed by a designated key available to
the PMC, and once a user has acknowledged that they accept such Incubator
signed artifacts, maven can do what it wants with them.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

enforced signing of artifacts, [was maven repository]

["Brian E. Fox" <br...@reply.infinity.nu>]

>I really don't care what cuts across the grain of Maven.  I do care
about
>the established principle that people must make a deliberate decision
to use
>Incubator artifacts.  If Maven would finally support enforcing signing
of
>artifacts, as they have been asked to do for years, we could use an
>Incubator-specific signing key, forcing people to approve the use of
>Incubator artifacts, regardless of download location.

Can you elaborate more on what you mean here? I've been on the Maven PMC
for over a year now and this is the first I've heard of it.

We do support signing of artifacts and all the maven releases are
signed. We obviously don't control all the other Apache projects in a
way to enforce that they sign their artifacts. 




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 3:30 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Brett Porter wrote:
>
>> Noel J. Bergman:
>> > I really don't care what cuts across the grain of Maven.  I do care
> about
>> > the established principle that people must make a deliberate decision to
> use
>> > Incubator artifacts.  If Maven would finally support enforcing signing
> of
>> > artifacts, as they have been asked to do for years, we could use an
>> > Incubator-specific signing key, forcing people to approve the use of
>> > Incubator artifacts, regardless of download location.
>
>> You're asking for it to enforce the use of signed artifacts out of the
>> box, not enforce signing.
>
> Yes.  As noted in my reply to Brian E. Fox in his renamed thread "enforced
> signing of artifacts".

i've talked at length about this before (IIRC with brett and others)
and done quite a bit of thinking. it is a much more general issue than
just maven. one signature isn't good enough. it would be good for
maven to lead the way but IMO we need a comprehensive solution for all
apache releases.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 4:41 AM, Brett Porter <br...@gmail.com> wrote:
> 2008/5/31 Brett Porter <br...@gmail.com>:
>> 2008/5/31 Noel J. Bergman <no...@devtech.com>:
>>>> I'm more than happy to throw an enforcer rule into the next Maven
>>>> release that warns users if they are:
>>>> - using the incubator repository
>>>> - using an artifact from org.apache.* with version *-incubating.
>>>>   and point them to a URL to learn more.
>>>
>>>> Will that do?
>>>
>>> Wearing my Incubator PMC hat?  Possibly.  Please elaborate.
>>
>> I'd need to look into it (Brian wrote the enforcer so might offer his
>> thoughts), but I think we can add a rule that will fail at the start
>> of a build using such artifact(s). It can also display a message for
>> how to configure the project such that it will disable the message and
>> failure. It's per project, not per user. It's not transitive, so any
>> project that uses something that uses an incubating artifact would
>> need to do the same.
>
> Just some more considerations on this though. I would need to check
> the impact on build performance - I imagine it's pretty quick, but
> it's possibly an obnoxious thing to add for every build whether they
> care about incubated apache projects or not.

does seems a little extreme to me

IHMO printing the DISCLAIMER at the start of the build would be good enough

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Brett Porter <br...@gmail.com>]

2008/5/31 Brett Porter <br...@gmail.com>:
> 2008/5/31 Noel J. Bergman <no...@devtech.com>:
>>> I'm more than happy to throw an enforcer rule into the next Maven
>>> release that warns users if they are:
>>> - using the incubator repository
>>> - using an artifact from org.apache.* with version *-incubating.
>>>   and point them to a URL to learn more.
>>
>>> Will that do?
>>
>> Wearing my Incubator PMC hat?  Possibly.  Please elaborate.
>
> I'd need to look into it (Brian wrote the enforcer so might offer his
> thoughts), but I think we can add a rule that will fail at the start
> of a build using such artifact(s). It can also display a message for
> how to configure the project such that it will disable the message and
> failure. It's per project, not per user. It's not transitive, so any
> project that uses something that uses an incubating artifact would
> need to do the same.

Just some more considerations on this though. I would need to check
the impact on build performance - I imagine it's pretty quick, but
it's possibly an obnoxious thing to add for every build whether they
care about incubated apache projects or not.

>
>> Obviously, this won't solve the problem of people using older versions of
>> Maven, but I'm not sure if there is a good solution to that, is there?
>
> Not really.

That said, it could be added to the apache parent pom so hopefully all
the ASF projects can use it regardless of Maven version. That seems to
be less your concern though.

- Brett

>
> - Brett
>
> --
> Brett Porter
> Blog: http://blogs.exist.com/bporter/
>



-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Brett Porter <br...@gmail.com>]

2008/5/31 Noel J. Bergman <no...@devtech.com>:
>> I'm more than happy to throw an enforcer rule into the next Maven
>> release that warns users if they are:
>> - using the incubator repository
>> - using an artifact from org.apache.* with version *-incubating.
>>   and point them to a URL to learn more.
>
>> Will that do?
>
> Wearing my Incubator PMC hat?  Possibly.  Please elaborate.

I'd need to look into it (Brian wrote the enforcer so might offer his
thoughts), but I think we can add a rule that will fail at the start
of a build using such artifact(s). It can also display a message for
how to configure the project such that it will disable the message and
failure. It's per project, not per user. It's not transitive, so any
project that uses something that uses an incubating artifact would
need to do the same.

> Obviously, this won't solve the problem of people using older versions of
> Maven, but I'm not sure if there is a good solution to that, is there?

Not really.

- Brett

-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Brett Porter wrote:

> Noel J. Bergman:
> > I really don't care what cuts across the grain of Maven.  I do care
about
> > the established principle that people must make a deliberate decision to
use
> > Incubator artifacts.  If Maven would finally support enforcing signing
of
> > artifacts, as they have been asked to do for years, we could use an
> > Incubator-specific signing key, forcing people to approve the use of
> > Incubator artifacts, regardless of download location.

> You're asking for it to enforce the use of signed artifacts out of the
> box, not enforce signing.

Yes.  As noted in my reply to Brian E. Fox in his renamed thread "enforced
signing of artifacts".

> I still think that's some time off from happening

Well, you know how I feel about that ...

> I'm more than happy to throw an enforcer rule into the next Maven
> release that warns users if they are:
> - using the incubator repository
> - using an artifact from org.apache.* with version *-incubating.
>   and point them to a URL to learn more.

> Will that do?

Wearing my Incubator PMC hat?  Possibly.  Please elaborate.  Wearing my
security hat?  Not in the slightest, but I'm willing to focus on the
Incubator's issues here.

Obviously, this won't solve the problem of people using older versions of
Maven, but I'm not sure if there is a good solution to that, is there?

> > By the way, there has been some talk in Infrastructure about shutting
down
> > the ASF's repository entirely if Maven does not provide enforcement of
> > signed artifacts, due to security concerns.

> Can you point me to the message ID and list? I don't recall it.

Would have been on infra@ a time or few over the years.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Brett Porter <br...@gmail.com>]

2008/5/31 Noel J. Bergman <no...@devtech.com>:
> Robert Burrell Donkin wrote:
>
>> it has now been clearly established that we need to move the
>> repository. we're now just asking: where?
>
> As I said, Brett Porter's proposal, made early on in the thread, seemed
> satisfactory.

That wasn't a proposal, it's how things are today.

My understanding is the following:
- releases are published to that repository, not to the rsync repository
- "incubating" is in the version, not in any other identifier (since
the version is the only thing attached to the release, the rest
continue after incubating).
- there is no automated rsync to the central repository
- the maven repository maintainers don't ban the upload of incubating
artifacts to the central repository.

> I really don't care what cuts across the grain of Maven.  I do care about
> the established principle that people must make a deliberate decision to use
> Incubator artifacts.  If Maven would finally support enforcing signing of
> artifacts, as they have been asked to do for years, we could use an
> Incubator-specific signing key, forcing people to approve the use of
> Incubator artifacts, regardless of download location.

You're asking for it to enforce the use of signed artifacts out of the
box, not enforce signing. I still think that's some time off from
happening, but hey - volunteers are always welcome.

I'm more than happy to throw an enforcer rule into the next Maven
release that warns users if they are:
- using the incubator repository
- using an artifact from org.apache.* with version *-incubating.
and point them to a URL to learn more.

Will that do?

>
> By the way, there has been some talk in Infrastructure about shutting down
> the ASF's repository entirely if Maven does not provide enforcement of
> signed artifacts, due to security concerns.

Can you point me to the message ID and list? I don't recall it.

Thanks,
Brett

-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

Of course we could do that, and we may have to in order to appease our
community.  But we'd prefer not to for simplicity's sake.

On Mon, Jun 2, 2008 at 4:25 AM, Gilles Scokart <gs...@gmail.com> wrote:

> 2008/5/30 Jeremy Haile <jh...@fastmail.fm>:
> > Currently JSecurity has a community, is published to Maven, and does
> regular
> > releases.  If joining the incubator meant that we were no longer approved
> to
> > do releases to our community, that seems like a hindrance to adoption.
>  If
> > people can no longer download releases via Maven without going through
> > annoying steps that make it seem immature and unreliable, then that's a
> > hindrance to adoption.
> >
>
> Hint : You could maybe still release JSecurity under the groupid /
> artefactid that you were using before.
> Tha
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: maven repository

[Gilles Scokart <gs...@gmail.com>]

2008/5/30 Jeremy Haile <jh...@fastmail.fm>:
> Currently JSecurity has a community, is published to Maven, and does regular
> releases.  If joining the incubator meant that we were no longer approved to
> do releases to our community, that seems like a hindrance to adoption.  If
> people can no longer download releases via Maven without going through
> annoying steps that make it seem immature and unreliable, then that's a
> hindrance to adoption.
>

Hint : You could maybe still release JSecurity under the groupid /
artefactid that you were using before.
Tha


-- 
Gilles Scokart

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jeremy Haile <jh...@fastmail.fm>]

Yeah - coming from the point of view of a project working on entering  
the incubator, I'd rather have tough IP restrictions on entering the  
incubator, but once I'm in the incubator have an environment that most  
effectively promotes growth and adoption of the project.  Rather than  
feeling like we are taking a step backwards in adoption by joining the  
incubator.

Currently JSecurity has a community, is published to Maven, and does  
regular releases.  If joining the incubator meant that we were no  
longer approved to do releases to our community, that seems like a  
hindrance to adoption.  If people can no longer download releases via  
Maven without going through annoying steps that make it seem immature  
and unreliable, then that's a hindrance to adoption.

I'd much rather have a strict process up front that get it IP  
clearance and then make it easy for people to adopt, than to enter the  
incubation process and have hindrances put in place.

Perhaps one idea is to not treat all projects or incubation proposals  
the same.  Some projects could choose to enter the incubator now, have  
access to Apache's infrastructure, etc. and gain IP clearance at some  
later date where they can then do releases.  Other more established  
projects could choose to front-load the IP clearance and have that  
occur before they are even accepted.  In those cases, once they are  
accepted, they can immediately continue to do releases and foster the  
community growth.

Just throwing out my 2 cents...

On May 30, 2008, at 11:43 AM, Les Hazlewood wrote:

> Hrm - I thought you had to have IP clearance before you even were
> accepted as a podling.  Or maybe its just that Alan is such a great
> Champion for us, that he helped us along that path before we even
> submitted our proposal ;)
>
> Under this assumption (that IP clearance exists already), it makes
> much more sense to allow the podling to publish approved releases to
> the central repository, but still under an
> org.apache.incubator.projectname group id to maintain
> convention/simplicity.
>
> On Fri, May 30, 2008 at 11:38 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm>  
>> wrote:
>>> So it seems that a valid question is whether or not publishing to  
>>> one
>>> repository or another indicates an endorsement.
>>
>> Yes, that's certainly a valid question.  Again, that's just my
>> personal point of view.
>>
>> The biggest problem with incubator projects (again my opinion) having
>> releases is the IP clearance.  Perhaps there should be multiple  
>> stages
>> of incubation.  The first stage should be where you verify the IP
>> clearance and projects in that stage shouldn't be allowed to do
>> releases at all.  Then they might graduate to the next stage and that
>> would be a "community building" stage where we make sure the project
>> has enough community around it.  These projects should be able to
>> provide incubating releases.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, May 30, 2008 at 5:32 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 12:27 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>> My proposed solution:
>>
>> 1.  A podling could not issue a release until after IP issues have
>> been cleared by the IPMC.
>> 2.  Once a podling's release has been approved (which includes IP
>> approval), they would release to the central maven repository under
>> the group id org.apache.incubator.podlingname, enabling easy adoption
>> by end users.
>>
>> Having the word 'incubator' in the group id conforms to repo
>> conventions matching domain names thereby not surprising any
>> end-users, and also explicitly requires the developer editing the pom
>> or ivy config to visually recognize it is _not_ an ASF TLP.  Because
>> they explicitly manually include the word 'incubator', they know its
>> not an official ASF endorsed project.
>>
>
> Well, that doesn't solve the transitive dependency problem.  Suppose
> you use project X and project X uses a podling release.  You'll
> probably never know it (as pointed out earlier).  For most folks, they
> don't really care as long as it works (also pointed out earlier), but
> I can see where the ASF would want to make sure that the user
> acknowledges that they're know they're using a podling release (even
> if it's indirectly), since the ASF doesn't officially "endorse" the
> project (yet).

the only concern should be with the user of the library: the developer
who elects to depend up it to build their library or application. the
secondary distribution of open source libraries cannot be control and
attempting to do so will only introduce unnecessary friction for
minimal gain.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 12:27 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> My proposed solution:
>
> 1.  A podling could not issue a release until after IP issues have
> been cleared by the IPMC.
> 2.  Once a podling's release has been approved (which includes IP
> approval), they would release to the central maven repository under
> the group id org.apache.incubator.podlingname, enabling easy adoption
> by end users.
>
> Having the word 'incubator' in the group id conforms to repo
> conventions matching domain names thereby not surprising any
> end-users, and also explicitly requires the developer editing the pom
> or ivy config to visually recognize it is _not_ an ASF TLP.  Because
> they explicitly manually include the word 'incubator', they know its
> not an official ASF endorsed project.
>

Well, that doesn't solve the transitive dependency problem.  Suppose
you use project X and project X uses a podling release.  You'll
probably never know it (as pointed out earlier).  For most folks, they
don't really care as long as it works (also pointed out earlier), but
I can see where the ASF would want to make sure that the user
acknowledges that they're know they're using a podling release (even
if it's indirectly), since the ASF doesn't officially "endorse" the
project (yet).

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

I think that that the term "Incubator" is well understood.  Almost
everyone in the software world understands that term.  For the very
few that might not, a quick dictionary or google search, or a visit to
incubator.apache.org would make that very clear.  That's good enough.
Unless there is an absolute legal obligation to actually force the
end-user to recognize that dependency, it is just adding noise.  Keep
It Super Simple.

> Also, then a non-incubator project uses the incubator project as a dependency.
> This hides the incubator dependency - no thank you!

There is nothing wrong with a non-incubator project using the
incubator project as a dependency, as long as the incubator project IP
has been cleared.  See Daniel Kulp's latest response in the parallel
thread related to this topic for why there are many good reasons why
incubator projects can or should be used in non-incubator projects.

A dependency on an incubator's artifact is a decision by the project's
PMC and should remain so  - they know their project better than anyone
and would know best to include that dependency or not.  End users of
that project rarely if ever care if a incubator dependency exists.

So if my two proposed conditions are met (IP clearance as a
stipulation), then I feel with comfortable certainty that no one will
care.

If you want to make it known that a project has transitive
dependencies, it would be far better to note that in the project's
README file.  Plus naming the maven group id with 'incubator' in it.
Plus the Apache 2.0 license part that states "software distributed
under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND".  That is more than enough due
diligence.  Developers don't want to be bothered by this stuff, and if
they do, its clearly documented and the CYA notion is covered.

On Fri, May 30, 2008 at 1:24 PM, sebb <se...@gmail.com> wrote:
> On 30/05/2008, Les Hazlewood <le...@hazlewood.com> wrote:
>> My proposed solution:
>>
>>  1.  A podling could not issue a release until after IP issues have
>>  been cleared by the IPMC.
>>  2.  Once a podling's release has been approved (which includes IP
>>  approval), they would release to the central maven repository under
>>  the group id org.apache.incubator.podlingname, enabling easy adoption
>>  by end users.
>>
>>  Having the word 'incubator' in the group id conforms to repo
>>  conventions matching domain names thereby not surprising any
>>  end-users, and also explicitly requires the developer editing the pom
>>  or ivy config to visually recognize it is _not_ an ASF TLP.  Because
>>  they explicitly manually include the word 'incubator', they know its
>>  not an official ASF endorsed project.
>
> Assuming that the meaning of "Incubator" is well understood - which
> may not be the case.
>
> Also, then a non-incubator project uses the incubator project as a dependency.
> This hides the incubator dependency - no thank you!
>
>>  On Fri, May 30, 2008 at 12:16 PM, James Carman
>>
>> <ja...@carmanconsulting.com> wrote:
>>  > So, let's define the goals here:
>>  >
>>  > 1.  The ASF would like folks who want to use incubating projects to do
>>  > so knowingly somehow.  This is somewhat of a CYA tactic so that people
>>  > are acknowledging "yes, I understand this is not an 'official' ASF
>>  > project, but I'd like to use it anyway."
>>  > 2.  Incubating projects would like to be able to get releases in front
>>  > of people so that they can build their community.
>>  >
>>  >
>>  >
>>  > On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>>  >> Hrm - I thought you had to have IP clearance before you even were
>>  >> accepted as a podling.  Or maybe its just that Alan is such a great
>>  >> Champion for us, that he helped us along that path before we even
>>  >> submitted our proposal ;)
>>  >>
>>  >> Under this assumption (that IP clearance exists already), it makes
>>  >> much more sense to allow the podling to publish approved releases to
>>  >> the central repository, but still under an
>>  >> org.apache.incubator.projectname group id to maintain
>>  >> convention/simplicity.
>>  >>
>>  >> On Fri, May 30, 2008 at 11:38 AM, James Carman
>>  >> <ja...@carmanconsulting.com> wrote:
>>  >>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>  >>>> So it seems that a valid question is whether or not publishing to one
>>  >>>> repository or another indicates an endorsement.
>>  >>>
>>  >>> Yes, that's certainly a valid question.  Again, that's just my
>>  >>> personal point of view.
>>  >>>
>>  >>> The biggest problem with incubator projects (again my opinion) having
>>  >>> releases is the IP clearance.  Perhaps there should be multiple stages
>>  >>> of incubation.  The first stage should be where you verify the IP
>>  >>> clearance and projects in that stage shouldn't be allowed to do
>>  >>> releases at all.  Then they might graduate to the next stage and that
>>  >>> would be a "community building" stage where we make sure the project
>>  >>> has enough community around it.  These projects should be able to
>>  >>> provide incubating releases.
>>  >>>
>>  >>> ---------------------------------------------------------------------
>>  >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >>> For additional commands, e-mail: general-help@incubator.apache.org
>>  >>>
>>  >>>
>>  >>
>>  >> ---------------------------------------------------------------------
>>  >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >> For additional commands, e-mail: general-help@incubator.apache.org
>>  >>
>>  >>
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  > For additional commands, e-mail: general-help@incubator.apache.org
>>  >
>>  >
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[sebb <se...@gmail.com>]

On 30/05/2008, Les Hazlewood <le...@hazlewood.com> wrote:
> My proposed solution:
>
>  1.  A podling could not issue a release until after IP issues have
>  been cleared by the IPMC.
>  2.  Once a podling's release has been approved (which includes IP
>  approval), they would release to the central maven repository under
>  the group id org.apache.incubator.podlingname, enabling easy adoption
>  by end users.
>
>  Having the word 'incubator' in the group id conforms to repo
>  conventions matching domain names thereby not surprising any
>  end-users, and also explicitly requires the developer editing the pom
>  or ivy config to visually recognize it is _not_ an ASF TLP.  Because
>  they explicitly manually include the word 'incubator', they know its
>  not an official ASF endorsed project.

Assuming that the meaning of "Incubator" is well understood - which
may not be the case.

Also, then a non-incubator project uses the incubator project as a dependency.
This hides the incubator dependency - no thank you!

>  On Fri, May 30, 2008 at 12:16 PM, James Carman
>
> <ja...@carmanconsulting.com> wrote:
>  > So, let's define the goals here:
>  >
>  > 1.  The ASF would like folks who want to use incubating projects to do
>  > so knowingly somehow.  This is somewhat of a CYA tactic so that people
>  > are acknowledging "yes, I understand this is not an 'official' ASF
>  > project, but I'd like to use it anyway."
>  > 2.  Incubating projects would like to be able to get releases in front
>  > of people so that they can build their community.
>  >
>  >
>  >
>  > On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>  >> Hrm - I thought you had to have IP clearance before you even were
>  >> accepted as a podling.  Or maybe its just that Alan is such a great
>  >> Champion for us, that he helped us along that path before we even
>  >> submitted our proposal ;)
>  >>
>  >> Under this assumption (that IP clearance exists already), it makes
>  >> much more sense to allow the podling to publish approved releases to
>  >> the central repository, but still under an
>  >> org.apache.incubator.projectname group id to maintain
>  >> convention/simplicity.
>  >>
>  >> On Fri, May 30, 2008 at 11:38 AM, James Carman
>  >> <ja...@carmanconsulting.com> wrote:
>  >>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>  >>>> So it seems that a valid question is whether or not publishing to one
>  >>>> repository or another indicates an endorsement.
>  >>>
>  >>> Yes, that's certainly a valid question.  Again, that's just my
>  >>> personal point of view.
>  >>>
>  >>> The biggest problem with incubator projects (again my opinion) having
>  >>> releases is the IP clearance.  Perhaps there should be multiple stages
>  >>> of incubation.  The first stage should be where you verify the IP
>  >>> clearance and projects in that stage shouldn't be allowed to do
>  >>> releases at all.  Then they might graduate to the next stage and that
>  >>> would be a "community building" stage where we make sure the project
>  >>> has enough community around it.  These projects should be able to
>  >>> provide incubating releases.
>  >>>
>  >>> ---------------------------------------------------------------------
>  >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>> For additional commands, e-mail: general-help@incubator.apache.org
>  >>>
>  >>>
>  >>
>  >> ---------------------------------------------------------------------
>  >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >> For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

["Alan D. Cabrera" <li...@toolazydogs.com>]

On May 30, 2008, at 2:09 PM, Janne Jalkanen wrote:

>> This seems logical provided the java package names also contain the  
>> incubator keyword to avoid classpath conflicts if the jar gets  
>> included twice.
>
> Which would, obviously, kill backwards compatibility for third party  
> extensions when moving out of incubation.
>
> Is not nice if you've built your entire system to be extensible and  
> modular.  Annoys users, too.  Which isn't good for building  
> communities.

Yeah, I have to say, IMO, it's a crazy idea.


Regards,
Alan


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Janne Jalkanen <Ja...@ecyrd.com>]

> This seems logical provided the java package names also contain the  
> incubator keyword to avoid classpath conflicts if the jar gets  
> included twice.

Which would, obviously, kill backwards compatibility for third party  
extensions when moving out of incubation.

Is not nice if you've built your entire system to be extensible and  
modular.  Annoys users, too.  Which isn't good for building communities.

/Janne, who's very much trying to have only a single binary break  
with JSPWiki...

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, May 31, 2008 at 7:34 AM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>> The package names have to change when a podling comes into the
>> incubator (to the org.apache namespace).  So, the "blow" has to happen
>> anyway.  I'm not suggesting we enforce this for existing podlings
>> necessarily, but future ones should probably do it.  Once the podling
>> graduates, the plugins would need to change the package name they use
>> because they are now based on an official ASF library.  Is
>> find/replace really that difficult?
>
> *Once* is doable.  We can do a lot of refactoring of old code during that
> anyway, clean away unused APIs, etc.
>
> *Twice* (that is, once from com.ecyrd.jspwiki to
> org.apache.incubator.jspwiki; then from org.apache.incubator.jspwiki to
> org.apache.jspwiki) is not so nice.
>
> Besides, us doing search-replace on other people's code and then
> redistributing it is very probably not ok anyway.  Our own code is trivial
> to modify; all the external code is not.

IMHO the effort of renaming is not worth the gain

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Janne Jalkanen <Ja...@ecyrd.com>]

> The package names have to change when a podling comes into the
> incubator (to the org.apache namespace).  So, the "blow" has to happen
> anyway.  I'm not suggesting we enforce this for existing podlings
> necessarily, but future ones should probably do it.  Once the podling
> graduates, the plugins would need to change the package name they use
> because they are now based on an official ASF library.  Is
> find/replace really that difficult?

*Once* is doable.  We can do a lot of refactoring of old code during  
that anyway, clean away unused APIs, etc.

*Twice* (that is, once from com.ecyrd.jspwiki to  
org.apache.incubator.jspwiki; then from org.apache.incubator.jspwiki  
to org.apache.jspwiki) is not so nice.

Besides, us doing search-replace on other people's code and then  
redistributing it is very probably not ok anyway.  Our own code is  
trivial to modify; all the external code is not.

/Janne

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

["Alan D. Cabrera" <li...@toolazydogs.com>]

On May 30, 2008, at 2:23 PM, James Carman wrote:

> On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
> <Ja...@ecyrd.com> wrote:
>>> As an end user, I would _hate_ to have to change all of my code to
>>> reference a totally new package structure after the podling  
>>> graduates.
>>> That's a major pain...
>>
>> With JSPWiki we have plenty of plugins and other extensions donated  
>> by
>> people over the years.  Every binary break means that we obsolete  
>> most of
>> this stuff (unless we can take the responsibility of recompiling
>> everything).  Every binary break means that we will have to answer  
>> questions
>> from people running obsolete software because they can't afford the  
>> cost of
>> the upgrade because they have money invested in the customizations.
>>
>> So it's not only the pain of upgrading the package definitions;  
>> changing
>> packages issues a damaging blow to the ecosystem nurtured in the  
>> incubator.
>> Sometimes the impact can be minimal; sometimes it could be rather  
>> bad.
>
> The package names have to change when a podling comes into the
> incubator (to the org.apache namespace).  So, the "blow" has to happen
> anyway.  I'm not suggesting we enforce this for existing podlings
> necessarily, but future ones should probably do it.  Once the podling
> graduates, the plugins would need to change the package name they use
> because they are now based on an official ASF library.  Is
> find/replace really that difficult?

Yes, it is.  When your entire community and the communities that rely  
on them have to do it, yes it is.  Remember, some podlings incubate  
for years and so these roots can go way out.

Frankly, I am really, really, surprised that this is being entertained  
at all.


Regards,
Alan



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

I tend agree that yes it will be annoying but certainly you can't claim
you weren't informed. With modern IDE's refactoring isn't a huge issue
in my opinion.

I could go either way, but if we say the group id changes, then we need
to try to prevent classpath conflicts as Maven will see the new
group:artifact as a totally new thing (which actually seems to be the
intent and a good thing). It's not simply a case of updating your poms
to use the new group, you would have to ensure none of your transitive
dependencies are using the old group as well and exclude them.

The only other alternative is back to the original idea of denoting
incubator in the version, but this could be troublesome as well.


-----Original Message-----
From: Julius Davies [mailto:juliusdavies@gmail.com] 
Sent: Friday, May 30, 2008 5:43 PM
To: general@incubator.apache.org
Subject: Re: maven repository

A general package renaming is going to be the least of your worries if
you're depending on lots of young immature jar files (and
automatically downloading newer versions)!  Many popular jars have
broken binary reverse-compatibility at some point (httpclient,
jfreechart, junit to name three).

To reply to Alan Cabrera, I don't think it's crazy.  I think it's more
crazy to depend on incubator jars and *not* expect some turbulence of
this kind!  I think the package renaming idea is pretty slick, and
appears to accomplish both of the goals James Carman identified, while
tolerating side-by-side presence of a pre-graduated and post-graduated
incubator jars in the classpath.

If you really don't want binary breakage, don't upgrade your jar.


On Fri, May 30, 2008 at 9:16 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> So, let's define the goals here:
>
> 1.  The ASF would like folks who want to use incubating projects to do
> so knowingly somehow.  This is somewhat of a CYA tactic so that people
> are acknowledging "yes, I understand this is not an 'official' ASF
> project, but I'd like to use it anyway."
> 2.  Incubating projects would like to be able to get releases in front
> of people so that they can build their community.
>


yours,

Julius


On Fri, May 30, 2008 at 2:23 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
> <Ja...@ecyrd.com> wrote:
>>> As an end user, I would _hate_ to have to change all of my code to
>>> reference a totally new package structure after the podling
graduates.
>>>  That's a major pain...
>>
>> With JSPWiki we have plenty of plugins and other extensions donated
by
>> people over the years.  Every binary break means that we obsolete
most of
>> this stuff (unless we can take the responsibility of recompiling
>> everything).  Every binary break means that we will have to answer
questions
>> from people running obsolete software because they can't afford the
cost of
>> the upgrade because they have money invested in the customizations.
>>
>> So it's not only the pain of upgrading the package definitions;
changing
>> packages issues a damaging blow to the ecosystem nurtured in the
incubator.
>>  Sometimes the impact can be minimal; sometimes it could be rather
bad.
>


-- 
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Julius Davies <ju...@gmail.com>]

A general package renaming is going to be the least of your worries if
you're depending on lots of young immature jar files (and
automatically downloading newer versions)!  Many popular jars have
broken binary reverse-compatibility at some point (httpclient,
jfreechart, junit to name three).

To reply to Alan Cabrera, I don't think it's crazy.  I think it's more
crazy to depend on incubator jars and *not* expect some turbulence of
this kind!  I think the package renaming idea is pretty slick, and
appears to accomplish both of the goals James Carman identified, while
tolerating side-by-side presence of a pre-graduated and post-graduated
incubator jars in the classpath.

If you really don't want binary breakage, don't upgrade your jar.


On Fri, May 30, 2008 at 9:16 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> So, let's define the goals here:
>
> 1.  The ASF would like folks who want to use incubating projects to do
> so knowingly somehow.  This is somewhat of a CYA tactic so that people
> are acknowledging "yes, I understand this is not an 'official' ASF
> project, but I'd like to use it anyway."
> 2.  Incubating projects would like to be able to get releases in front
> of people so that they can build their community.
>


yours,

Julius


On Fri, May 30, 2008 at 2:23 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
> <Ja...@ecyrd.com> wrote:
>>> As an end user, I would _hate_ to have to change all of my code to
>>> reference a totally new package structure after the podling graduates.
>>>  That's a major pain...
>>
>> With JSPWiki we have plenty of plugins and other extensions donated by
>> people over the years.  Every binary break means that we obsolete most of
>> this stuff (unless we can take the responsibility of recompiling
>> everything).  Every binary break means that we will have to answer questions
>> from people running obsolete software because they can't afford the cost of
>> the upgrade because they have money invested in the customizations.
>>
>> So it's not only the pain of upgrading the package definitions; changing
>> packages issues a damaging blow to the ecosystem nurtured in the incubator.
>>  Sometimes the impact can be minimal; sometimes it could be rather bad.
>


-- 
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
<Ja...@ecyrd.com> wrote:
>> As an end user, I would _hate_ to have to change all of my code to
>> reference a totally new package structure after the podling graduates.
>>  That's a major pain...
>
> With JSPWiki we have plenty of plugins and other extensions donated by
> people over the years.  Every binary break means that we obsolete most of
> this stuff (unless we can take the responsibility of recompiling
> everything).  Every binary break means that we will have to answer questions
> from people running obsolete software because they can't afford the cost of
> the upgrade because they have money invested in the customizations.
>
> So it's not only the pain of upgrading the package definitions; changing
> packages issues a damaging blow to the ecosystem nurtured in the incubator.
>  Sometimes the impact can be minimal; sometimes it could be rather bad.

The package names have to change when a podling comes into the
incubator (to the org.apache namespace).  So, the "blow" has to happen
anyway.  I'm not suggesting we enforce this for existing podlings
necessarily, but future ones should probably do it.  Once the podling
graduates, the plugins would need to change the package name they use
because they are now based on an official ASF library.  Is
find/replace really that difficult?

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Janne Jalkanen <Ja...@ecyrd.com>]

> As an end user, I would _hate_ to have to change all of my code to
> reference a totally new package structure after the podling graduates.
>  That's a major pain...

With JSPWiki we have plenty of plugins and other extensions donated  
by people over the years.  Every binary break means that we obsolete  
most of this stuff (unless we can take the responsibility of  
recompiling everything).  Every binary break means that we will have  
to answer questions from people running obsolete software because  
they can't afford the cost of the upgrade because they have money  
invested in the customizations.

So it's not only the pain of upgrading the package definitions;  
changing packages issues a damaging blow to the ecosystem nurtured in  
the incubator.  Sometimes the impact can be minimal; sometimes it  
could be rather bad.

/Janne

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

Why is this necessary?

As an end user, I would _hate_ to have to change all of my code to
reference a totally new package structure after the podling graduates.
 That's a major pain...

On Fri, May 30, 2008 at 4:49 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
>>My proposed solution:
>
>>1.  A podling could not issue a release until after IP issues have
>>been cleared by the IPMC.
>>2.  Once a podling's release has been approved (which includes IP
>>approval), they would release to the central maven repository under
>>the group id org.apache.incubator.podlingname, enabling easy adoption
>>by end users.
>
> This seems logical provided the java package names also contain the incubator keyword to avoid classpath conflicts if the jar gets included twice.
>
> --Brian
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

>My proposed solution:

>1.  A podling could not issue a release until after IP issues have
>been cleared by the IPMC.
>2.  Once a podling's release has been approved (which includes IP
>approval), they would release to the central maven repository under
>the group id org.apache.incubator.podlingname, enabling easy adoption
>by end users.

This seems logical provided the java package names also contain the incubator keyword to avoid classpath conflicts if the jar gets included twice.

--Brian

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

My proposed solution:

1.  A podling could not issue a release until after IP issues have
been cleared by the IPMC.
2.  Once a podling's release has been approved (which includes IP
approval), they would release to the central maven repository under
the group id org.apache.incubator.podlingname, enabling easy adoption
by end users.

Having the word 'incubator' in the group id conforms to repo
conventions matching domain names thereby not surprising any
end-users, and also explicitly requires the developer editing the pom
or ivy config to visually recognize it is _not_ an ASF TLP.  Because
they explicitly manually include the word 'incubator', they know its
not an official ASF endorsed project.

On Fri, May 30, 2008 at 12:16 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> So, let's define the goals here:
>
> 1.  The ASF would like folks who want to use incubating projects to do
> so knowingly somehow.  This is somewhat of a CYA tactic so that people
> are acknowledging "yes, I understand this is not an 'official' ASF
> project, but I'd like to use it anyway."
> 2.  Incubating projects would like to be able to get releases in front
> of people so that they can build their community.
>
>
>
> On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>> Hrm - I thought you had to have IP clearance before you even were
>> accepted as a podling.  Or maybe its just that Alan is such a great
>> Champion for us, that he helped us along that path before we even
>> submitted our proposal ;)
>>
>> Under this assumption (that IP clearance exists already), it makes
>> much more sense to allow the podling to publish approved releases to
>> the central repository, but still under an
>> org.apache.incubator.projectname group id to maintain
>> convention/simplicity.
>>
>> On Fri, May 30, 2008 at 11:38 AM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>>> So it seems that a valid question is whether or not publishing to one
>>>> repository or another indicates an endorsement.
>>>
>>> Yes, that's certainly a valid question.  Again, that's just my
>>> personal point of view.
>>>
>>> The biggest problem with incubator projects (again my opinion) having
>>> releases is the IP clearance.  Perhaps there should be multiple stages
>>> of incubation.  The first stage should be where you verify the IP
>>> clearance and projects in that stage shouldn't be allowed to do
>>> releases at all.  Then they might graduate to the next stage and that
>>> would be a "community building" stage where we make sure the project
>>> has enough community around it.  These projects should be able to
>>> provide incubating releases.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

So, let's define the goals here:

1.  The ASF would like folks who want to use incubating projects to do
so knowingly somehow.  This is somewhat of a CYA tactic so that people
are acknowledging "yes, I understand this is not an 'official' ASF
project, but I'd like to use it anyway."
2.  Incubating projects would like to be able to get releases in front
of people so that they can build their community.



On Fri, May 30, 2008 at 11:43 AM, Les Hazlewood <le...@hazlewood.com> wrote:
> Hrm - I thought you had to have IP clearance before you even were
> accepted as a podling.  Or maybe its just that Alan is such a great
> Champion for us, that he helped us along that path before we even
> submitted our proposal ;)
>
> Under this assumption (that IP clearance exists already), it makes
> much more sense to allow the podling to publish approved releases to
> the central repository, but still under an
> org.apache.incubator.projectname group id to maintain
> convention/simplicity.
>
> On Fri, May 30, 2008 at 11:38 AM, James Carman
> <ja...@carmanconsulting.com> wrote:
>> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>> So it seems that a valid question is whether or not publishing to one
>>> repository or another indicates an endorsement.
>>
>> Yes, that's certainly a valid question.  Again, that's just my
>> personal point of view.
>>
>> The biggest problem with incubator projects (again my opinion) having
>> releases is the IP clearance.  Perhaps there should be multiple stages
>> of incubation.  The first stage should be where you verify the IP
>> clearance and projects in that stage shouldn't be allowed to do
>> releases at all.  Then they might graduate to the next stage and that
>> would be a "community building" stage where we make sure the project
>> has enough community around it.  These projects should be able to
>> provide incubating releases.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

Hrm - I thought you had to have IP clearance before you even were
accepted as a podling.  Or maybe its just that Alan is such a great
Champion for us, that he helped us along that path before we even
submitted our proposal ;)

Under this assumption (that IP clearance exists already), it makes
much more sense to allow the podling to publish approved releases to
the central repository, but still under an
org.apache.incubator.projectname group id to maintain
convention/simplicity.

On Fri, May 30, 2008 at 11:38 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
>> So it seems that a valid question is whether or not publishing to one
>> repository or another indicates an endorsement.
>
> Yes, that's certainly a valid question.  Again, that's just my
> personal point of view.
>
> The biggest problem with incubator projects (again my opinion) having
> releases is the IP clearance.  Perhaps there should be multiple stages
> of incubation.  The first stage should be where you verify the IP
> clearance and projects in that stage shouldn't be allowed to do
> releases at all.  Then they might graduate to the next stage and that
> would be a "community building" stage where we make sure the project
> has enough community around it.  These projects should be able to
> provide incubating releases.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
> So it seems that a valid question is whether or not publishing to one
> repository or another indicates an endorsement.

Yes, that's certainly a valid question.  Again, that's just my
personal point of view.

The biggest problem with incubator projects (again my opinion) having
releases is the IP clearance.  Perhaps there should be multiple stages
of incubation.  The first stage should be where you verify the IP
clearance and projects in that stage shouldn't be allowed to do
releases at all.  Then they might graduate to the next stage and that
would be a "community building" stage where we make sure the project
has enough community around it.  These projects should be able to
provide incubating releases.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

That's the way I feel as well.

The maven repo exists to make lives easier for people - its an easy
way to pick up dependencies if you need them - nothing more.  It is
primarily organized by domain names, so, if you have an
org.apache.incubator.podlingname group id, you're just following
convention expected by pretty much everyone.

This is a _good thing_ - it is expected behavior, makes things easy
for people, and is extremely clear that its not an ASF top level
project.  IMO, that is all that end-users really care about.  Isn't
that good enough?  I feel with comfortable certainty that the large
majority of people will be perfectly fine with that, and because it
does not require manual intervention, would probably prefer it.

On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
> So it seems that a valid question is whether or not publishing to one
> repository or another indicates an endorsement.  I don't personally see it
> that way.  Just because ASF makes a release available via a maven repository
> isn't the same thing as endorsement to me, just as the fact that the Apache
> (Incubator) name may be used in reference to a project or that Apache is
> hosting the project doesn't mean it's necessarily endorsing it.
>
> I think that if a developer doesn't understand his project's dependencies,
> that's certainly a problem.  But I worry that forcing them to go through
> extra steps of adding a special repository, approving a special key, etc.
> makes it seem like the software isn't trustworthy and could hinder adoption.
>
> To my mind, "incubator project" does not necessarily imply instability.
>  Where it's hosted in maven doesn't necessarily imply endorsement.  The fact
> that the project is in the incubator and the names include incubating is
> what indicates that it isn't an ASF endorsed project yet.
>
> Jeremy
>
> On May 30, 2008, at 11:14 AM, James Carman wrote:
>
>> The bottom line is that incubator projects haven't (yet) gone through
>> all the hoops necessary to become official ASF projects.  So, if they
>> are published to the main repository, that is in a way saying that the
>> ASF endorses the software.  Since it has not graduated from the
>> incubator, the ASF doesn't yet endorse it.  This is the way I see it
>> at least.
>>
>> On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood <le...@hazlewood.com> wrote:
>>>
>>> Noel,
>>>
>>> Could you please help me understand the fundamental reasons why this
>>> is important to the IPMC?
>>>
>>> I mean, I as an end-user could care less about if the dependency
>>> artifact is in incubation or not - as long as it solves the problems
>>> in the way the development team deems necessary, all I want to do is
>>> just have be accessible to me immediately.  I don't care where it
>>> comes from.  If it requires intervention on my part, I view that as a
>>> major pain, especially if it can knowingly be avoided.  I would want
>>> things to be as automatic and hands-off as possible.
>>>
>>> I'm just genuinely trying to understand why the distinction is necessary.
>>>
>>> Thanks for clarifying my naivety,
>>>
>>> Les
>>>
>>> On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <no...@devtech.com>
>>> wrote:
>>>>
>>>> Robert Burrell Donkin wrote:
>>>>
>>>>> it has now been clearly established that we need to move the
>>>>> repository. we're now just asking: where?
>>>>
>>>> As I said, Brett Porter's proposal, made early on in the thread, seemed
>>>> satisfactory.
>>>>
>>>>> asking podlings to publish through a secondary repository is both
>>>>> annoying and ineffective at making it explicit to people that
>>>>> they are using artifacts under incubation. this measure cuts
>>>>> against the grain of maven.
>>>>
>>>> I really don't care what cuts across the grain of Maven.  I do care
>>>> about
>>>> the established principle that people must make a deliberate decision to
>>>> use
>>>> Incubator artifacts.  If Maven would finally support enforcing signing
>>>> of
>>>> artifacts, as they have been asked to do for years, we could use an
>>>> Incubator-specific signing key, forcing people to approve the use of
>>>> Incubator artifacts, regardless of download location.
>>>>
>>>> Rather than relax the principle to accomodate a defective tool, if Maven
>>>> cannot solve this problem, I'd be more inclined to ban the use of maven
>>>> repositories for Incubator artifacts.  That is how strongly I feel about
>>>> the
>>>> principle.
>>>>
>>>> By the way, there has been some talk in Infrastructure about shutting
>>>> down
>>>> the ASF's repository entirely if Maven does not provide enforcement of
>>>> signed artifacts, due to security concerns.
>>>>
>>>> Look back over the years of debate on this issue, and I believe that you
>>>> will find I've been very consistent.  I want Incubator projects to be
>>>> able
>>>> to perform releases in order to grow their (developer) community, but we
>>>> also require that people be aware of the fact that they are not using
>>>> official ASF code, as noted by the disclaimer.
>>>>
>>>>> an easy and effective way to ensure that users know that they are using
>>>>> an artifact from the incubator would be to ensure that the group or
>>>>> artifact ID includes this information.
>>>>
>>>> End users don't read the POM.  They just use it.  So that is no solution
>>>> at
>>>> all.  The signing approach would be, IMO, a reasonable solution.  It
>>>> would
>>>> solve Les' issue -- users would simply have to agree to install the
>>>> Incubator-signed artifact(s), and thereafter they'd be fine.
>>>>
>>>>      --- Noel
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jeremy Haile <jh...@fastmail.fm>]

So it seems that a valid question is whether or not publishing to one  
repository or another indicates an endorsement.  I don't personally  
see it that way.  Just because ASF makes a release available via a  
maven repository isn't the same thing as endorsement to me, just as  
the fact that the Apache (Incubator) name may be used in reference to  
a project or that Apache is hosting the project doesn't mean it's  
necessarily endorsing it.

I think that if a developer doesn't understand his project's  
dependencies, that's certainly a problem.  But I worry that forcing  
them to go through extra steps of adding a special repository,  
approving a special key, etc. makes it seem like the software isn't  
trustworthy and could hinder adoption.

To my mind, "incubator project" does not necessarily imply  
instability.  Where it's hosted in maven doesn't necessarily imply  
endorsement.  The fact that the project is in the incubator and the  
names include incubating is what indicates that it isn't an ASF  
endorsed project yet.

Jeremy

On May 30, 2008, at 11:14 AM, James Carman wrote:

> The bottom line is that incubator projects haven't (yet) gone through
> all the hoops necessary to become official ASF projects.  So, if they
> are published to the main repository, that is in a way saying that the
> ASF endorses the software.  Since it has not graduated from the
> incubator, the ASF doesn't yet endorse it.  This is the way I see it
> at least.
>
> On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood <le...@hazlewood.com>  
> wrote:
>> Noel,
>>
>> Could you please help me understand the fundamental reasons why this
>> is important to the IPMC?
>>
>> I mean, I as an end-user could care less about if the dependency
>> artifact is in incubation or not - as long as it solves the problems
>> in the way the development team deems necessary, all I want to do is
>> just have be accessible to me immediately.  I don't care where it
>> comes from.  If it requires intervention on my part, I view that as a
>> major pain, especially if it can knowingly be avoided.  I would want
>> things to be as automatic and hands-off as possible.
>>
>> I'm just genuinely trying to understand why the distinction is  
>> necessary.
>>
>> Thanks for clarifying my naivety,
>>
>> Les
>>
>> On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman  
>> <no...@devtech.com> wrote:
>>> Robert Burrell Donkin wrote:
>>>
>>>> it has now been clearly established that we need to move the
>>>> repository. we're now just asking: where?
>>>
>>> As I said, Brett Porter's proposal, made early on in the thread,  
>>> seemed
>>> satisfactory.
>>>
>>>> asking podlings to publish through a secondary repository is both
>>>> annoying and ineffective at making it explicit to people that
>>>> they are using artifacts under incubation. this measure cuts
>>>> against the grain of maven.
>>>
>>> I really don't care what cuts across the grain of Maven.  I do  
>>> care about
>>> the established principle that people must make a deliberate  
>>> decision to use
>>> Incubator artifacts.  If Maven would finally support enforcing  
>>> signing of
>>> artifacts, as they have been asked to do for years, we could use an
>>> Incubator-specific signing key, forcing people to approve the use of
>>> Incubator artifacts, regardless of download location.
>>>
>>> Rather than relax the principle to accomodate a defective tool, if  
>>> Maven
>>> cannot solve this problem, I'd be more inclined to ban the use of  
>>> maven
>>> repositories for Incubator artifacts.  That is how strongly I feel  
>>> about the
>>> principle.
>>>
>>> By the way, there has been some talk in Infrastructure about  
>>> shutting down
>>> the ASF's repository entirely if Maven does not provide  
>>> enforcement of
>>> signed artifacts, due to security concerns.
>>>
>>> Look back over the years of debate on this issue, and I believe  
>>> that you
>>> will find I've been very consistent.  I want Incubator projects to  
>>> be able
>>> to perform releases in order to grow their (developer) community,  
>>> but we
>>> also require that people be aware of the fact that they are not  
>>> using
>>> official ASF code, as noted by the disclaimer.
>>>
>>>> an easy and effective way to ensure that users know that they are  
>>>> using
>>>> an artifact from the incubator would be to ensure that the group or
>>>> artifact ID includes this information.
>>>
>>> End users don't read the POM.  They just use it.  So that is no  
>>> solution at
>>> all.  The signing approach would be, IMO, a reasonable solution.   
>>> It would
>>> solve Les' issue -- users would simply have to agree to install the
>>> Incubator-signed artifact(s), and thereafter they'd be fine.
>>>
>>>       --- Noel
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Davanum Srinivas <da...@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Les,

please remember, not all incubator projects make it! i've personally been a mentor on a few projects that were shutdown
for various reasons.

- -- dims

James Carman wrote:
| The bottom line is that incubator projects haven't (yet) gone through
| all the hoops necessary to become official ASF projects.  So, if they
| are published to the main repository, that is in a way saying that the
| ASF endorses the software.  Since it has not graduated from the
| incubator, the ASF doesn't yet endorse it.  This is the way I see it
| at least.
|
| On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood <le...@hazlewood.com> wrote:
|> Noel,
|>
|> Could you please help me understand the fundamental reasons why this
|> is important to the IPMC?
|>
|> I mean, I as an end-user could care less about if the dependency
|> artifact is in incubation or not - as long as it solves the problems
|> in the way the development team deems necessary, all I want to do is
|> just have be accessible to me immediately.  I don't care where it
|> comes from.  If it requires intervention on my part, I view that as a
|> major pain, especially if it can knowingly be avoided.  I would want
|> things to be as automatic and hands-off as possible.
|>
|> I'm just genuinely trying to understand why the distinction is necessary.
|>
|> Thanks for clarifying my naivety,
|>
|> Les
|>
|> On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <no...@devtech.com> wrote:
|>> Robert Burrell Donkin wrote:
|>>
|>>> it has now been clearly established that we need to move the
|>>> repository. we're now just asking: where?
|>> As I said, Brett Porter's proposal, made early on in the thread, seemed
|>> satisfactory.
|>>
|>>> asking podlings to publish through a secondary repository is both
|>>> annoying and ineffective at making it explicit to people that
|>>> they are using artifacts under incubation. this measure cuts
|>>> against the grain of maven.
|>> I really don't care what cuts across the grain of Maven.  I do care about
|>> the established principle that people must make a deliberate decision to use
|>> Incubator artifacts.  If Maven would finally support enforcing signing of
|>> artifacts, as they have been asked to do for years, we could use an
|>> Incubator-specific signing key, forcing people to approve the use of
|>> Incubator artifacts, regardless of download location.
|>>
|>> Rather than relax the principle to accomodate a defective tool, if Maven
|>> cannot solve this problem, I'd be more inclined to ban the use of maven
|>> repositories for Incubator artifacts.  That is how strongly I feel about the
|>> principle.
|>>
|>> By the way, there has been some talk in Infrastructure about shutting down
|>> the ASF's repository entirely if Maven does not provide enforcement of
|>> signed artifacts, due to security concerns.
|>>
|>> Look back over the years of debate on this issue, and I believe that you
|>> will find I've been very consistent.  I want Incubator projects to be able
|>> to perform releases in order to grow their (developer) community, but we
|>> also require that people be aware of the fact that they are not using
|>> official ASF code, as noted by the disclaimer.
|>>
|>>> an easy and effective way to ensure that users know that they are using
|>>> an artifact from the incubator would be to ensure that the group or
|>>> artifact ID includes this information.
|>> End users don't read the POM.  They just use it.  So that is no solution at
|>> all.  The signing approach would be, IMO, a reasonable solution.  It would
|>> solve Les' issue -- users would simply have to agree to install the
|>> Incubator-signed artifact(s), and thereafter they'd be fine.
|>>
|>>        --- Noel
|>>
|>>
|>>
|>> ---------------------------------------------------------------------
|>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
|>> For additional commands, e-mail: general-help@incubator.apache.org
|>>
|>>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
|> For additional commands, e-mail: general-help@incubator.apache.org
|>
|>
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
| For additional commands, e-mail: general-help@incubator.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFIQB1FgNg6eWEDv1kRAnIyAJ4sCgbdRQbPLyRXWwJFqxZEyEg0bgCfZDqV
gFZAWAtMuhR2Tl7AnLXxkYI=
=HcOZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

James Carman wrote:

> The bottom line is that incubator projects haven't (yet) gone through
> all the hoops necessary to become official ASF projects.  So, if they
> are published to the main repository, that is in a way saying that the
> ASF endorses the software.  Since it has not graduated from the
> incubator, the ASF doesn't yet endorse it.  This is the way I see it
> at least.

Close enough, I suppose.

This is not about IP Clearance or code quality.  The former is a
prerequisite for any release at all, the latter is the project's problem.
The Incubator's issue is ensuring that downstream users are aware of the
fact that the project is probational, as per the Incubator Disclaimer.  We
don't want that step to be bypassed merely by the choice of build tool.

As noted in other messages, were Maven to finally correct its artifact
handling flaws and enforce signing, all of this could be resolved.  In lieu
of that, Brett is proposing an interim solution.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

The bottom line is that incubator projects haven't (yet) gone through
all the hoops necessary to become official ASF projects.  So, if they
are published to the main repository, that is in a way saying that the
ASF endorses the software.  Since it has not graduated from the
incubator, the ASF doesn't yet endorse it.  This is the way I see it
at least.

On Fri, May 30, 2008 at 11:06 AM, Les Hazlewood <le...@hazlewood.com> wrote:
> Noel,
>
> Could you please help me understand the fundamental reasons why this
> is important to the IPMC?
>
> I mean, I as an end-user could care less about if the dependency
> artifact is in incubation or not - as long as it solves the problems
> in the way the development team deems necessary, all I want to do is
> just have be accessible to me immediately.  I don't care where it
> comes from.  If it requires intervention on my part, I view that as a
> major pain, especially if it can knowingly be avoided.  I would want
> things to be as automatic and hands-off as possible.
>
> I'm just genuinely trying to understand why the distinction is necessary.
>
> Thanks for clarifying my naivety,
>
> Les
>
> On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <no...@devtech.com> wrote:
>> Robert Burrell Donkin wrote:
>>
>>> it has now been clearly established that we need to move the
>>> repository. we're now just asking: where?
>>
>> As I said, Brett Porter's proposal, made early on in the thread, seemed
>> satisfactory.
>>
>>> asking podlings to publish through a secondary repository is both
>>> annoying and ineffective at making it explicit to people that
>>> they are using artifacts under incubation. this measure cuts
>>> against the grain of maven.
>>
>> I really don't care what cuts across the grain of Maven.  I do care about
>> the established principle that people must make a deliberate decision to use
>> Incubator artifacts.  If Maven would finally support enforcing signing of
>> artifacts, as they have been asked to do for years, we could use an
>> Incubator-specific signing key, forcing people to approve the use of
>> Incubator artifacts, regardless of download location.
>>
>> Rather than relax the principle to accomodate a defective tool, if Maven
>> cannot solve this problem, I'd be more inclined to ban the use of maven
>> repositories for Incubator artifacts.  That is how strongly I feel about the
>> principle.
>>
>> By the way, there has been some talk in Infrastructure about shutting down
>> the ASF's repository entirely if Maven does not provide enforcement of
>> signed artifacts, due to security concerns.
>>
>> Look back over the years of debate on this issue, and I believe that you
>> will find I've been very consistent.  I want Incubator projects to be able
>> to perform releases in order to grow their (developer) community, but we
>> also require that people be aware of the fact that they are not using
>> official ASF code, as noted by the disclaimer.
>>
>>> an easy and effective way to ensure that users know that they are using
>>> an artifact from the incubator would be to ensure that the group or
>>> artifact ID includes this information.
>>
>> End users don't read the POM.  They just use it.  So that is no solution at
>> all.  The signing approach would be, IMO, a reasonable solution.  It would
>> solve Les' issue -- users would simply have to agree to install the
>> Incubator-signed artifact(s), and thereafter they'd be fine.
>>
>>        --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

Noel,

Could you please help me understand the fundamental reasons why this
is important to the IPMC?

I mean, I as an end-user could care less about if the dependency
artifact is in incubation or not - as long as it solves the problems
in the way the development team deems necessary, all I want to do is
just have be accessible to me immediately.  I don't care where it
comes from.  If it requires intervention on my part, I view that as a
major pain, especially if it can knowingly be avoided.  I would want
things to be as automatic and hands-off as possible.

I'm just genuinely trying to understand why the distinction is necessary.

Thanks for clarifying my naivety,

Les

On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> it has now been clearly established that we need to move the
>> repository. we're now just asking: where?
>
> As I said, Brett Porter's proposal, made early on in the thread, seemed
> satisfactory.
>
>> asking podlings to publish through a secondary repository is both
>> annoying and ineffective at making it explicit to people that
>> they are using artifacts under incubation. this measure cuts
>> against the grain of maven.
>
> I really don't care what cuts across the grain of Maven.  I do care about
> the established principle that people must make a deliberate decision to use
> Incubator artifacts.  If Maven would finally support enforcing signing of
> artifacts, as they have been asked to do for years, we could use an
> Incubator-specific signing key, forcing people to approve the use of
> Incubator artifacts, regardless of download location.
>
> Rather than relax the principle to accomodate a defective tool, if Maven
> cannot solve this problem, I'd be more inclined to ban the use of maven
> repositories for Incubator artifacts.  That is how strongly I feel about the
> principle.
>
> By the way, there has been some talk in Infrastructure about shutting down
> the ASF's repository entirely if Maven does not provide enforcement of
> signed artifacts, due to security concerns.
>
> Look back over the years of debate on this issue, and I believe that you
> will find I've been very consistent.  I want Incubator projects to be able
> to perform releases in order to grow their (developer) community, but we
> also require that people be aware of the fact that they are not using
> official ASF code, as noted by the disclaimer.
>
>> an easy and effective way to ensure that users know that they are using
>> an artifact from the incubator would be to ensure that the group or
>> artifact ID includes this information.
>
> End users don't read the POM.  They just use it.  So that is no solution at
> all.  The signing approach would be, IMO, a reasonable solution.  It would
> solve Les' issue -- users would simply have to agree to install the
> Incubator-signed artifact(s), and thereafter they'd be fine.
>
>        --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 10:51 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> You would still end up with duplicate jars being drawn in. Maven
> fingerprints an artifact with groupId:artifactid:classifier:type to see
> if there are conflicts.

Of course, but you can make sure folks aren't using the podling
version of the code vs. the graduated if they're in different
packages.  We are using a similar strategy within Apache Commons to
avoid "jar hell" situations.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

You would still end up with duplicate jars being drawn in. Maven
fingerprints an artifact with groupId:artifactid:classifier:type to see
if there are conflicts. 

-----Original Message-----
From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
On Behalf Of James Carman
Sent: Friday, May 30, 2008 10:31 AM
To: general@incubator.apache.org
Subject: Re: maven repository

Well, to avoid collisions like that you could change the package name:

org.apache.incubating.podlingname


Once it graduates, you get:

org.apache.podlingname




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

That would be my preference - it feels cleaner and still allows the
release to be in the central repository (which is my main concern -
our end-users would be quite upset if they couldn't get our releases
from the main repo anymore).  I prefer not to have 'incubating'
attached to the version.

Although a minor distinction, I prefer the group ids to be
org.apache.incubator.podlingname --> org.apache.podlingname

This just makes sense given that group ids are usually domain names.

On Fri, May 30, 2008 at 10:30 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> Well, to avoid collisions like that you could change the package name:
>
> org.apache.incubating.podlingname
>
>
> Once it graduates, you get:
>
> org.apache.podlingname
>
>
>
> On Fri, May 30, 2008 at 10:28 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>>>The problem with that is when the project graduates and they remove
>>>incubator from the groupId, there is a good potential to have two
>>>versions of the same packages being pulled in
>>
>> You're right, I overlooked that... so I guess the qualifier attached to
>> the version is probably the best bet.
>>
>> --Brian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

Well, to avoid collisions like that you could change the package name:

org.apache.incubating.podlingname


Once it graduates, you get:

org.apache.podlingname



On Fri, May 30, 2008 at 10:28 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>>The problem with that is when the project graduates and they remove
>>incubator from the groupId, there is a good potential to have two
>>versions of the same packages being pulled in
>
> You're right, I overlooked that... so I guess the qualifier attached to
> the version is probably the best bet.
>
> --Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

>The problem with that is when the project graduates and they remove  
>incubator from the groupId, there is a good potential to have two  
>versions of the same packages being pulled in

You're right, I overlooked that... so I guess the qualifier attached to
the version is probably the best bet.

--Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Daniel Kulp <dk...@apache.org>]

On May 30, 2008, at 9:55 AM, Brian E. Fox wrote:

>
>> Wouldn't having "incubating" in the version achieve the same thing
> here?
>
> Not necessarily for users specifying ranges. Further, having the group
> be common for all incubating releases would make it easier for  
> people to
> block in their repo manager (or with an enforcer rule).

The problem with that is when the project graduates and they remove  
incubator from the groupId, there is a good potential to have two  
versions of the same packages being pulled in.  The "incubator"  
version and the "non-incubator" version.   If they use the same  
groupId before/after graduation, that doesn't happen as the normal  
maven dependency resolution applies.   With different groupIds, if a  
developer updates one pom, but doesn't update another or similar, they  
can easily get both versions pulled in.

Not a HUGE deal, but it is something to be aware of.

Given the choices of:
1) incubator in groupid and going to central
or
2) not going to central

I'd choose #2 any day.   That said, I'm still in favor of:
3) incubator in version number and going to central


Dan



>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

>Wouldn't having "incubating" in the version achieve the same thing
here?

Not necessarily for users specifying ranges. Further, having the group
be common for all incubating releases would make it easier for people to
block in their repo manager (or with an enforcer rule).

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 9:22 AM, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
>>Maven artifacts can also specify a "classifier."  Perhaps the
>>"incubating" part could be a classifier?
>
> Only attached artifacts can have a classifier, not the main one, so
> unfortunately this won't work. I think having a different groupId is the
> most logical choice... something like org.apache.incubator.xxxx
>

Wouldn't having "incubating" in the version achieve the same thing here?

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Brian E. Fox" <br...@reply.infinity.nu>]

>Maven artifacts can also specify a "classifier."  Perhaps the
>"incubating" part could be a classifier?

Only attached artifacts can have a classifier, not the main one, so
unfortunately this won't work. I think having a different groupId is the
most logical choice... something like org.apache.incubator.xxxx

The good part about this is that when the project graduates, the id will
change and this will prevent people from inadvertently getting a
pre-graduation artifact if they use ranges. (assuming we don't allow a
relocation to be specified from the old to the new group id)

--Brian 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[James Carman <ja...@carmanconsulting.com>]

On Fri, May 30, 2008 at 8:56 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:

> in terms of communication, the pom is the place to focus. AIUI maven
> users choose to use a library by adding a dependency with artifact and
> group IDs. an easy and effective way to ensure that users know that
> they are using an artifact from the incubator would be to ensure that
> the group or artifact ID includes this information. we could also ask
> that the pom (meta-data) for the project specifies 'Apache Software
> Foundation (Incubator)' rather than 'Apache Software Foundation' as
> the organisation.
>

Maven artifacts can also specify a "classifier."  Perhaps the
"incubating" part could be a classifier?

<dependency>
  <groupId>org.apache.podling</groupId>
  <artifactId>podling</artifactId>
  <version>2.0</version>
  <classifier>incubating</classifier>
</dependency>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Robert Burrell Donkin wrote:

> it has now been clearly established that we need to move the
> repository. we're now just asking: where?

As I said, Brett Porter's proposal, made early on in the thread, seemed
satisfactory.

> asking podlings to publish through a secondary repository is both
> annoying and ineffective at making it explicit to people that
> they are using artifacts under incubation. this measure cuts
> against the grain of maven.

I really don't care what cuts across the grain of Maven.  I do care about
the established principle that people must make a deliberate decision to use
Incubator artifacts.  If Maven would finally support enforcing signing of
artifacts, as they have been asked to do for years, we could use an
Incubator-specific signing key, forcing people to approve the use of
Incubator artifacts, regardless of download location.

Rather than relax the principle to accomodate a defective tool, if Maven
cannot solve this problem, I'd be more inclined to ban the use of maven
repositories for Incubator artifacts.  That is how strongly I feel about the
principle.

By the way, there has been some talk in Infrastructure about shutting down
the ASF's repository entirely if Maven does not provide enforcement of
signed artifacts, due to security concerns.

Look back over the years of debate on this issue, and I believe that you
will find I've been very consistent.  I want Incubator projects to be able
to perform releases in order to grow their (developer) community, but we
also require that people be aware of the fact that they are not using
official ASF code, as noted by the disclaimer.

> an easy and effective way to ensure that users know that they are using
> an artifact from the incubator would be to ensure that the group or
> artifact ID includes this information.

End users don't read the POM.  They just use it.  So that is no solution at
all.  The signing approach would be, IMO, a reasonable solution.  It would
solve Les' issue -- users would simply have to agree to install the
Incubator-signed artifact(s), and thereafter they'd be fine.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, May 30, 2008 at 12:33 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Fri, May 30, 2008 at 2:53 AM, Noel J. Bergman <no...@devtech.com> wrote:
>> I really do not know why we have to revisit this same topic year after year
>> after year.

it has now been clearly established that we need to move the
repository. we're now just asking: where?

> Because it's an arbitrary restriction that IMHO hasn't been properly justified.

i'm not sure i'd put it so categorically

we can choose to ask incubating projects to publish their jars to a
separate repository but this is irrelevant for most users. maven
automatically downloads their releases from central repositories
hosted offshore. jar upload to these repositories is beyond the direct
control of apache or incubating projects.

asking podlings to use a separate repository is not going to be
effective for any well used product. for any product which isn't yet
well used, it creates a barrier to adoption.

>> We do not want people to be using any Incubator artifact without explicit
>> knowledge and action, so we do not want them polluting the standard repository.
>
> Replace "artifact" with "release" and "standard repository" with "the
> Internet" and you have a rationale for preventing incubating releases.
> I wouldn't agree with that, but at least that would be a clear and
> consistent argument.
>
> One of the key principles of open source is that you don't put
> arbitrary restrictions on where or how the code is distributed or
> used. Once we approve a release it should be up to the project to
> decide how they want to make it available to their users.

once an artifact has been released, we lose control over the
distribution. asking podlings to publish through a secondary
repository is both annoying and ineffective at making it explicit to
people that they are using artifacts under incubation. this measure
cuts against the grain of maven.

in terms of communication, the pom is the place to focus. AIUI maven
users choose to use a library by adding a dependency with artifact and
group IDs. an easy and effective way to ensure that users know that
they are using an artifact from the incubator would be to ensure that
the group or artifact ID includes this information. we could also ask
that the pom (meta-data) for the project specifies 'Apache Software
Foundation (Incubator)' rather than 'Apache Software Foundation' as
the organisation.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Jukka Zitting wrote:

> Noel J. Bergman wrote:
> > I really do not know why we have to revisit this same topic year after
year
> > after year.

> Because it's an arbitrary restriction that IMHO hasn't been properly
justified.

So in other words, we'll revisit this again everytime someone (relatively)
new comes along and wants to reopen the debate.

> > We do not want people to be using any Incubator artifact without
explicit
> > knowledge and action, so we do not want them polluting the standard
repository.

> Replace "artifact" with "release" and "standard repository" with "the
> Internet" and you have a rationale for preventing incubating releases.
> I wouldn't agree with that, but at least that would be a clear and
> consistent argument.

Well, more than a few people DID argue against having any Incubator releases
at all, but we agreed that so long as there was proper notice and
disclaimers, that there was a net benefit to allowing people to chose to use
an Incubator release, since it would help to build the developer community,
and thus make it easier for the project to eventually graduate.  So we are
not trying to prevent Incubator releases, we are trying to enforce that no
one uses them without making a deliberate decision to do so.

> One of the key principles of open source is that you don't put
> arbitrary restrictions on where or how the code is distributed
> or used.

So what?  We are not putting an arbitrary restriction on the code.  We are
putting a restriction on how an Incubator project may distribute its
artifacts.  Nothing we did, for example, had, or was intended to have, any
effect on Sun's ability to use Roller in production during Incubation.

> Once we approve a release it should be up to the project to
> decide how they want to make it available to their users.

No.

> For example, if SpamAssassin were to enter incubation today, would we
> prevent them from using CPAN to distribute their releases?

As a matter of fact, we had similar issues with Roller and Wicket.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, May 30, 2008 at 2:53 AM, Noel J. Bergman <no...@devtech.com> wrote:
> I really do not know why we have to revisit this same topic year after year
> after year.

Because it's an arbitrary restriction that IMHO hasn't been properly justified.

> We do not want people to be using any Incubator artifact without explicit
> knowledge and action, so we do not want them polluting the standard repository.

Replace "artifact" with "release" and "standard repository" with "the
Internet" and you have a rationale for preventing incubating releases.
I wouldn't agree with that, but at least that would be a clear and
consistent argument.

One of the key principles of open source is that you don't put
arbitrary restrictions on where or how the code is distributed or
used. Once we approve a release it should be up to the project to
decide how they want to make it available to their users.

For example, if SpamAssassin were to enter incubation today, would we
prevent them from using CPAN to distribute their releases?

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

RE: maven repository

["Noel J. Bergman" <no...@devtech.com>]

Jukka Zitting wrote:
> Craig L Russell wrote:
> > 1. The incubating repository is not mirrored to the world, so incubating
> > artifacts don't pollute the maven-o-sphere.

> What's so bad about incubating artifacts that would "pollute" things?
> We are perfectly happy distributing them on www.apache.org and all our
> mirrors, so why not repo1.maven.org?

I really do not know why we have to revisit this same topic year after year
after year.  We do not want people to be using any Incubator artifact
without explicit knowledge and action, so we do not want them polluting the
standard repository.

> What's the benefit? There's already the "incubating" label attached to
> the artifacts.

Yeah, like the average Maven user has a clue about dependencies, and ever
looks at them except when there is a failure.

I am OK Brett's proposal, but not with conflating Incubator artifacts with
official ASF artifacts.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, May 15, 2008 at 7:01 PM, Craig L Russell <Cr...@sun.com> wrote:
> 1. The incubating repository is not mirrored to the world, so incubating
> artifacts don't pollute the maven-o-sphere.

What's so bad about incubating artifacts that would "pollute" things?
We are perfectly happy distributing them on www.apache.org and all our
mirrors, so why not repo1.maven.org?

> 2. The incubating repository needs to be added to the maven remote repo
> definition of each project that wants to depend on an incubating artifact.

What's the benefit? There's already the "incubating" label attached to
the artifacts.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Craig L Russell <Cr...@Sun.COM>]

On May 15, 2008, at 4:34 AM, Robert Burrell Donkin wrote:

> On Thu, May 15, 2008 at 8:04 AM, Brett Porter  
> <br...@gmail.com> wrote:
>> 2008/5/15 Robert Burrell Donkin <ro...@gmail.com>:
>>> It would be possible to create an incubator only repository in a
>>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>>> just simplify everything by allowing incubator projects to use the
>>> standard repository.Opinions?
>>
>> http://people.apache.org/repo/m2-incubating-repository/

IIUC, there are two differences between an incubating project  
depositing its artifacts into a special incubating repository versus  
the standard:

1. The incubating repository is not mirrored to the world, so  
incubating artifacts don't pollute the maven-o-sphere.

2. The incubating repository needs to be added to the maven remote  
repo definition of each project that wants to depend on an incubating  
artifact.

I think both of these have minor positive effects. So I'm really +0.3  
on using a special incubating repository.

Craig
>>
>>
>> ?
>
> should be under www.apache.org
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, May 15, 2008 at 8:04 AM, Brett Porter <br...@gmail.com> wrote:
> 2008/5/15 Robert Burrell Donkin <ro...@gmail.com>:
>> It would be possible to create an incubator only repository in a
>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>> just simplify everything by allowing incubator projects to use the
>> standard repository.Opinions?
>
> http://people.apache.org/repo/m2-incubating-repository/
>
> ?

should be under www.apache.org

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Brett Porter <br...@gmail.com>]

2008/5/15 Robert Burrell Donkin <ro...@gmail.com>:
> It would be possible to create an incubator only repository in a
> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
> just simplify everything by allowing incubator projects to use the
> standard repository.Opinions?

http://people.apache.org/repo/m2-incubating-repository/

?

- Brett


-- 
Brett Porter
Blog: http://blogs.exist.com/bporter/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Les Hazlewood <le...@hazlewood.com>]

In thinking of our project, JSecurity (which is currently being
proposed to become an Incubator project), I think its a bad idea to
limit incubator releases to a special repository.

We're a mature product and we're already publishing to the main repo -
very many of our end-users rely on this and expect our releases to
continue to be there.  If we're approved as an Incubator project, we
need this to continue to be the case, lest we upset our community.

We're going through the incubator process because it is mandated by
the ASF and we want the project to flourish in the ASF community, not
because we're a fledgling project that needs to see if it can survive.

In my opinion, that a project exists in the incubator is not an
indication that it is not stable or 'worthy' enough to be included in
the main Maven repository.  It is IMO a bad idea to think of incubator
artifacts as 'polluting' the repo-sphere.  Incubator projects should
be used and adopted and made available to everyone who wants to use
them in the easiest manner possible.  The purpose of the Incubator
after all is to try to garner adoption and see projects flourish.
Creating a separate repository that isn't readily available to the
world feels like it undermines this objective.

There is a sufficiently high barrier to entry to even become an
Incubator project in the first place, and incubator releases go
through a quality check and are voted on prior to a release.  This
should be sufficient enough to feel safe that the releases that are
approved are of decent enough quality to be available to the public at
large.

So, I would vote -1 in regards to creating a separate incubator Maven
repository.

Regards,

Les Hazlewood

On Thu, May 29, 2008 at 2:51 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> I'm inclined to call a vote on this matter as the discussion seems to
> have died. Are there any related concerns or opinions that haven't yet
> been voiced?
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jukka Zitting <ju...@gmail.com>]

Hi,

I'm inclined to call a vote on this matter as the discussion seems to
have died. Are there any related concerns or opinions that haven't yet
been voiced?

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Robert Burrell Donkin <ro...@gmail.com>]

On Thu, May 15, 2008 at 9:15 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Thu, May 15, 2008 at 10:01 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>> It would be possible to create an incubator only repository in a
>>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>>> just simplify everything by allowing incubator projects to use the
>>> standard repository.Opinions?
>>
>> I'd put them in the standard repository....
>
> Same here - the artifacts of incubating projects must have
> "incubating" in their name, right?
> I think that's enough to differentiate them.

i think so

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Bertrand Delacretaz <bd...@apache.org>]

On Thu, May 15, 2008 at 10:01 AM, Jukka Zitting <ju...@gmail.com> wrote:
> On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> It would be possible to create an incubator only repository in a
>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>> just simplify everything by allowing incubator projects to use the
>> standard repository.Opinions?
>
> I'd put them in the standard repository....

Same here - the artifacts of incubating projects must have
"incubating" in their name, right?
I think that's enough to differentiate them.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: maven repository

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> It would be possible to create an incubator only repository in a
> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
> just simplify everything by allowing incubator projects to use the
> standard repository.Opinions?

I'd put them in the standard repository.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org