incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: [policy] incubating projects and maven repositories v1.0
Date Thu, 31 Aug 2006 03:39:48 GMT
On 30 Aug 06, at 11:18 PM 30 Aug 06, Davanum Srinivas wrote:

> Hmm, we are not setting any limits on anyone else, just ourselves. We
> the incubator folks will not automatically sync *our* repo to the
> central repo *automatically*. Everyone else can do what they want
> within their rights.
>

That doesn't really jive with what Justin said in an earlier thread.  
In that we should tell people not to redistribute incubator artifacts  
and ask they comply out of courtesy.

> -- dims
>
> On 8/30/06, Jason van Zyl <jason@maven.org> wrote:
>>
>> On 30 Aug 06, at 10:16 PM 30 Aug 06, Davanum Srinivas wrote:
>>
>> > Please see this email from Noel:
>> > http://marc.theaimsgroup.com/?l=incubator-
>> > general&m=115440482328786&w=2
>> >
>>
>> Why can't both aims be met? That of user protection and user
>> convenience?
>>
>> I cannot see the how marking *each* and *every* incubator artifact
>> with a version that clearly says it is from the Apache Incubator
>> gives less clarity then adding a repository element.
>>
>> In a standard dependency report like:
>>
>> http://jackrabbit.apache.org/dependencies.html
>>
>> It would be very clear looking at the version that it came from the
>> incubator. And if people download these artifacts with non-Maven
>> tools like an Ant Task, Ivy or simply check in versions of these
>> artifacts then they will clearly be seen as coming from the
>> incubator.  If we are going to make it clear then let's do it in the
>> place where it will be seen by everyone regardless of the tool they
>> use to build.
>>
>> Also the Maven 2.x IDE integration will soon have the ability to pull
>> indices from repositories in order to provide drop down/searchable
>> lists of available artifacts so it will be easy to grab new artifacts
>> to put in your POMs. An IDE could easily provide a set of
>> repositories to pull indices from at which point the user is going to
>> merrily start pulling down dependencies. When you select an artifact
>> you always select the version, like in the Eclipse integration, so
>> people will see "apache-incubator" over and over. They will see the
>> repository entry once.
>>
>> If I then had to go to the people doing IDE integration and say
>> please don't include the apache incubator repository. So you are
>> going to make us:
>>
>> 1) Deny people the right to distribute software as described in our
>> license
>> 2) Make the Maven developers go search out all third party
>> integration efforts to prevent them from providing convenient access
>> to certain repositories
>>
>> I think this is a little heavy handed, unfair and unnecessary.
>>
>> > -- dims
>> >
>> > On 8/30/06, Jason van Zyl <jason@maven.org> wrote:
>> >>
>> >> On 30 Aug 06, at 7:53 PM 30 Aug 06, Davanum Srinivas wrote:
>> >>
>> >> > Jason,
>> >> >
>> >> > Is it rocket science to add a new repo location in pom.xml?  
>> *Any*
>> >> > maven newbie learns *very* quickly how to add a new repo. Are  
>> you
>> >> > stating that *IF* the artifacts are not in the central repo they
>> >> won't
>> >> > find it and won't know how to use it?
>> >>
>> >> As a force of habit most Maven users, particularly those coming  
>> from
>> >> Maven 1.x, assume all open source artifacts are in the central
>> >> repository. And in most cases for Maven 2.x all artifact  
>> required are
>> >> placed in the central repository.
>> >>
>> >> It would be an unnecessary inconvenience. If the goal is to raise
>> >> awareness that it is from the incubator then it can be done  
>> with the
>> >> version. It could even be
>> >>
>> >> 1.0-apache-incubator-foo (1)
>> >>
>> >> As I think that would be preferable to users and that is  
>> abundantly
>> >> clear I think.
>> >>
>> >> > The least anyone will need to
>> >> > know is the artifact id and version id and they find this  
>> when they
>> >> > browse a project's pages, are you stating that a user will never
>> >> look
>> >> > at anyone's web site or download area and will *ONLY* look at
>> >> ibiblio
>> >> > repo and decide to use a project?
>> >>
>> >> The whole point of Maven is to make this easy for users and not  
>> have
>> >> to look at a project's site. Maven users expect what they need  
>> to be
>> >> in the central repository as shown by the many threads when  
>> users go
>> >> to use Sun JARs and we don't have them in the central repository.
>> >>
>> >> > If they do indeed look, isn't it
>> >> > trivial to add instructions on adding info on how to add the
>> >> > incubation repo? Where's the problem?
>> >>
>> >> A lot of times people actually go to the central repository to  
>> find
>> >> the artifact's groupId and artifactId. They don't go to project
>> >> websites, they go to the authority which is the central  
>> repository.
>> >>
>> >> If the goal here is user awareness then I think using an  
>> version like
>> >> (1) supports this end to a great extent while being more  
>> convenient
>> >> for the average Maven user.
>> >>
>> >>
>> >> >
>> >> > -- dims
>> >> >
>> >> >
>> >> >
>> >> > On 8/30/06, Jason van Zyl <jason@maven.org> wrote:
>> >> >>
>> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>> >> >>
>> >> >> > On 8/30/06, Dan Diephouse <dan@envoisolutions.com> wrote:
>> >> >> >> policy, so I see those as in conflict right now. So I
 
>> want to
>> >> >> know on
>> >> >> >> what grounds the incubator can prevent me from requesting
 
>> that
>> >> >> some
>> >> >> >> incubating jars from being uploaded to ibiblio.
>> >> >> >
>> >> >> > Common decency?  If we (as the project owners) ask those
>> >> >> artifacts not
>> >> >> > to be posted, then they shouldn't be posted as a matter of
>> >> >> courtesy.
>> >> >>
>> >> >> It just means that we have to start watching for requests
>> >> coming from
>> >> >> users to put artifacts in the repository. Effectively you are
>> >> asking
>> >> >> us to deny the terms of redistribution stated in our license
>> >> are you
>> >> >> not?
>> >> >>
>> >> >> We could watch for requests going into Ibiblio, but we can't
>> >> prevent
>> >> >> someone else from putting in a repository that they might use.
>> >> >>
>> >> >> What is going to happen is that people are going to want to use
>> >> these
>> >> >> artifacts and they will want to rsync Ibiblio, which many
>> >> people do,
>> >> >> and then attempt to rsync  the incubator repository. We are  
>> just
>> >> >> going to try and circumvent a path that we cannot fully  
>> block off.
>> >> >>
>> >> >> I don't see what is not clear with *every* incubator artifact
>> >> being
>> >> >> marked with a version that has "incubator" in it. Plus the  
>> reports
>> >> >> that can be generated give a clear view to users what they are
>> >> >> consuming.
>> >> >>
>> >> >> I read this:
>> >> >>
>> >> >> http://marc.theaimsgroup.com/?l=incubator-
>> >> >> general&m=115440663222532&w=2
>> >> >>
>> >> >> and to be frank (4) is somewhat paradoxical to me. You want an
>> >> >> incubator project to thrive, and grow while we are tacitly, yet
>> >> >> actively, discouraging their use? I think we should let  
>> people use
>> >> >> their common sense to protect themselves.
>> >> >>
>> >> >> What is being envisioned here as the worst case scenario of
>> >> using an
>> >> >> incubator artifact for a failed incubator project? The mail  
>> says
>> >> >> protect the user, but from what?
>> >> >>
>> >> >> I'm not going to discourage the use of a project I'm  
>> mentoring and
>> >> >> fully support. I'm going to get everyone on the planet I can to
>> >> use
>> >> >> it as fast and as widely as possible.
>> >> >>
>> >> >> > -- justin
>> >> >> >
>> >> >> >
>> >> >>
>> >>  
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: general- 
>> unsubscribe@incubator.apache.org
>> >> >> > For additional commands, e-mail: general-
>> >> help@incubator.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> Jason van Zyl
>> >> >> jason@maven.org
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>  
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: general- 
>> unsubscribe@incubator.apache.org
>> >> >> For additional commands, e-mail: general- 
>> help@incubator.apache.org
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
>> >> > Developers)
>> >> >
>> >> >
>> >>  
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail: general- 
>> help@incubator.apache.org
>> >> >
>> >> >
>> >>
>> >> Jason van Zyl
>> >> jason@maven.org
>> >>
>> >>
>> >>
>> >>
>> >>  
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
>> > Developers)
>> >
>> >  
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>> Jason van Zyl
>> jason@maven.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> -- 
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service  
> Developers)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Jason van Zyl
jason@maven.org




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


Mime
View raw message