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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>> >> >>
>> >> >> > On 8/30/06, Dan Diephouse <[EMAIL PROTECTED]> 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-
>> [EMAIL PROTECTED]
>> >> >> > For additional commands, e-mail: general-
>> >> [EMAIL PROTECTED]
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> Jason van Zyl
>> >> >> [EMAIL PROTECTED]
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>>
---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: general-
>> [EMAIL PROTECTED]
>> >> >> For additional commands, e-mail: general-
>> [EMAIL PROTECTED]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web
Service
>> >> > Developers)
>> >> >
>> >> >
>> >>
>>
---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: general-
[EMAIL PROTECTED]
>> >> > For additional commands, e-mail: general-
>> [EMAIL PROTECTED]
>> >> >
>> >> >
>> >>
>> >> Jason van Zyl
>> >> [EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >>
>> >>
>>
---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-
[EMAIL PROTECTED]
>> >> For additional commands, e-mail: general-
[EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> > --
>> > Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
>> > Developers)
>> >
>> >
>>
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: general-
[EMAIL PROTECTED]
>> >
>> >
>>
>> Jason van Zyl
>> [EMAIL PROTECTED]
>>
>>
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service
> Developers)
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Jason van Zyl
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
