You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jason van Zyl <ja...@maven.org> on 2006/08/27 18:44:58 UTC
[policy] incubating projects and maven repositories v1.0
Hi,
It looks like people objected to creating another mailing list for
policy so I just used [policy] as Robert did in a previous message.
Henri has setup Maven repositories for the incubator and there is a
document which is an attempt to describe the current setup here:
http://www.apache.org/dev/repository-faq.html
I think that everyone agrees that a separate repository for
incubating projects is a good idea as
1) you can clearly see what incubator artifacts have been created
2) we can perform analysis and create reports for incubator artifacts
easily (using Archiva, the maven repository manager)
3) separating the administration duties of the incubator repository
is a good idea I think. This might involve a different instance of
Archiva and/or different people looking after the respective
repositories
I haven't looked at all the projects using Maven in the incubator but
cxf, the one I'm most involved with, looks like its settling on
versions like:
2.0-incubator-SNAPSHOT
So the repository is clearly separated, and from a dependency element
in a Maven POM you can clearly see it's an incubator version.
There was discussion that incubator repository would not be sync'd to
the central repository but I don't really see much point in this. A
few folks with incubating projects have voiced concerns that they
don't want to see their projects be taken out of circulation in the
central repository because they are incubating. If each and every
incubating project has a version for each artifact like that above
then it will be fairly clear that it's from the incubator. Moreso
then if you just had a repository definition pointing at the
incubator repository.
Also someone may make an repository request to place an incubator
artifact in the central repository and at this point a policy
mandated here would conflict with someone's right to redistribute
artifacts created in the incubator. I don't really want to get into
the business of policing repository requests. I think it is in the
best interests of the incubating projects to have the incubator
repository sync'd to Maven's central repository. The source of
artifacts for incubating projects is clear from the version so I
don't think there will be any confusion by consumers of these
artifacts and as such I don't really see any downside to allowing the
sync to Maven's central repository.
Thoughts?
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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
Yes, general list and majority of binding votes AFAIK. please start
another thread with a set of well defined choices to vote on.
thanks,
dims
On 8/31/06, Jason van Zyl <ja...@maven.org> wrote:
>
> On 31 Aug 06, at 12:18 AM 31 Aug 06, Davanum Srinivas wrote:
>
> > Jason,
> >
> > Justin used the word "common decency". No one can twist anyone's arm.
> > If either the ibiblio folks or Maven PMC folks don't honor the
> > request, well, it's upto them...Here we are setting policy for us the
> > incubator participants, incubator mentors and incubator pmc folks. If
> > people working on the incubation project break the policy, then that's
> > an issue for us.
> >
>
> It's not policy until we vote on it. So I guess it's time to vote.
>
> How is this done, no the general list? For 72 hours? A majority wins?
>
> > -- dims
> >
> > On 8/30/06, Jason van Zyl <ja...@maven.org> wrote:
> >> 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 <ja...@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 <ja...@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 <ja...@maven.org> wrote:
> >> >> >> >>
> >> >> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
> >> >> >> >>
> >> >> >> >> > On 8/30/06, Dan Diephouse <da...@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
> >>
> >>
> >
> >
> > --
> > 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
On 31 Aug 06, at 12:18 AM 31 Aug 06, Davanum Srinivas wrote:
> Jason,
>
> Justin used the word "common decency". No one can twist anyone's arm.
> If either the ibiblio folks or Maven PMC folks don't honor the
> request, well, it's upto them...Here we are setting policy for us the
> incubator participants, incubator mentors and incubator pmc folks. If
> people working on the incubation project break the policy, then that's
> an issue for us.
>
It's not policy until we vote on it. So I guess it's time to vote.
How is this done, no the general list? For 72 hours? A majority wins?
> -- dims
>
> On 8/30/06, Jason van Zyl <ja...@maven.org> wrote:
>> 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 <ja...@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 <ja...@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 <ja...@maven.org> wrote:
>> >> >> >>
>> >> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>> >> >> >>
>> >> >> >> > On 8/30/06, Dan Diephouse <da...@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
>>
>>
>
>
> --
> 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
Jason,
Justin used the word "common decency". No one can twist anyone's arm.
If either the ibiblio folks or Maven PMC folks don't honor the
request, well, it's upto them...Here we are setting policy for us the
incubator participants, incubator mentors and incubator pmc folks. If
people working on the incubation project break the policy, then that's
an issue for us.
-- dims
On 8/30/06, Jason van Zyl <ja...@maven.org> wrote:
> 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 <ja...@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 <ja...@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 <ja...@maven.org> wrote:
> >> >> >>
> >> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
> >> >> >>
> >> >> >> > On 8/30/06, Dan Diephouse <da...@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
>
>
--
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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@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 <ja...@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 <ja...@maven.org> wrote:
>> >> >>
>> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>> >> >>
>> >> >> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
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.
-- dims
On 8/30/06, Jason van Zyl <ja...@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 <ja...@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 <ja...@maven.org> wrote:
> >> >>
> >> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
> >> >>
> >> >> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@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 <ja...@maven.org> wrote:
>> >>
>> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>> >>
>> >> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
Please see this email from Noel:
http://marc.theaimsgroup.com/?l=incubator-general&m=115440482328786&w=2
-- dims
On 8/30/06, Jason van Zyl <ja...@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 <ja...@maven.org> wrote:
> >>
> >> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
> >>
> >> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org> wrote:
>>
>> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>>
>> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
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? 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? 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?
-- dims
On 8/30/06, Jason van Zyl <ja...@maven.org> wrote:
>
> On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
>
> > On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
On 30 Aug 06, at 1:48 PM 30 Aug 06, Justin Erenkrantz wrote:
> On 8/30/06, Dan Diephouse <da...@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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/30/06, Dan Diephouse <da...@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.
-- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Yes, and I feel that Jason is addressing the issues brought up
previously. As Jason stated, and I reiterated in my message to Justin,
the incubator policy doesn't really affect the ibiblio distribution
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.
- Dan
Davanum Srinivas wrote:
> I guess, you need to read more emails on this list :) For example see [1]
>
> thanks,
> dims
>
> [1]
> http://marc.theaimsgroup.com/?l=incubator-general&m=115440663222532&w=2
>
>
> On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> Why?
>>
>> Davanum Srinivas wrote:
>> > If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
>> > artifacts to maven central repo.
>> >
>> > -- dims
>> >
>> > On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> >> Jason van Zyl wrote:
>> >> > Hi,
>> >> >
>> >> > It looks like people objected to creating another mailing list for
>> >> > policy so I just used [policy] as Robert did in a previous message.
>> >> >
>> >> > Henri has setup Maven repositories for the incubator and there is a
>> >> > document which is an attempt to describe the current setup here:
>> >> >
>> >> > http://www.apache.org/dev/repository-faq.html
>> >> >
>> >> > I think that everyone agrees that a separate repository for
>> incubating
>> >> > projects is a good idea as
>> >> >
>> >> > 1) you can clearly see what incubator artifacts have been created
>> >> > 2) we can perform analysis and create reports for incubator
>> artifacts
>> >> > easily (using Archiva, the maven repository manager)
>> >> > 3) separating the administration duties of the incubator
>> repository is
>> >> > a good idea I think. This might involve a different instance of
>> >> > Archiva and/or different people looking after the respective
>> >> repositories
>> >> >
>> >> > I haven't looked at all the projects using Maven in the
>> incubator but
>> >> > cxf, the one I'm most involved with, looks like its settling on
>> >> > versions like:
>> >> >
>> >> > 2.0-incubator-SNAPSHOT
>> >> >
>> >> > So the repository is clearly separated, and from a dependency
>> element
>> >> > in a Maven POM you can clearly see it's an incubator version.
>> >> >
>> >> > There was discussion that incubator repository would not be
>> sync'd to
>> >> > the central repository but I don't really see much point in this. A
>> >> > few folks with incubating projects have voiced concerns that they
>> >> > don't want to see their projects be taken out of circulation in the
>> >> > central repository because they are incubating. If each and every
>> >> > incubating project has a version for each artifact like that above
>> >> > then it will be fairly clear that it's from the incubator.
>> Moreso then
>> >> > if you just had a repository definition pointing at the incubator
>> >> > repository.
>> >> >
>> >> > Also someone may make an repository request to place an incubator
>> >> > artifact in the central repository and at this point a policy
>> mandated
>> >> > here would conflict with someone's right to redistribute artifacts
>> >> > created in the incubator. I don't really want to get into the
>> business
>> >> > of policing repository requests. I think it is in the best
>> interests
>> >> > of the incubating projects to have the incubator repository
>> sync'd to
>> >> > Maven's central repository. The source of artifacts for incubating
>> >> > projects is clear from the version so I don't think there will
>> be any
>> >> > confusion by consumers of these artifacts and as such I don't
>> really
>> >> > see any downside to allowing the sync to Maven's central
>> repository.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Jason van Zyl
>> >> > jason@maven.org
>> >>
>> >> +1.
>> >>
>> >> - Dan
>> >>
>> >> --
>> >> Dan Diephouse
>> >> Envoi Solutions
>> >> http://envoisolutions.com
>> >> http://netzooid.com/blog
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com
>> http://netzooid.com/blog
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
I guess, you need to read more emails on this list :) For example see [1]
thanks,
dims
[1] http://marc.theaimsgroup.com/?l=incubator-general&m=115440663222532&w=2
On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> Why?
>
> Davanum Srinivas wrote:
> > If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
> > artifacts to maven central repo.
> >
> > -- dims
> >
> > On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> >> Jason van Zyl wrote:
> >> > Hi,
> >> >
> >> > It looks like people objected to creating another mailing list for
> >> > policy so I just used [policy] as Robert did in a previous message.
> >> >
> >> > Henri has setup Maven repositories for the incubator and there is a
> >> > document which is an attempt to describe the current setup here:
> >> >
> >> > http://www.apache.org/dev/repository-faq.html
> >> >
> >> > I think that everyone agrees that a separate repository for incubating
> >> > projects is a good idea as
> >> >
> >> > 1) you can clearly see what incubator artifacts have been created
> >> > 2) we can perform analysis and create reports for incubator artifacts
> >> > easily (using Archiva, the maven repository manager)
> >> > 3) separating the administration duties of the incubator repository is
> >> > a good idea I think. This might involve a different instance of
> >> > Archiva and/or different people looking after the respective
> >> repositories
> >> >
> >> > I haven't looked at all the projects using Maven in the incubator but
> >> > cxf, the one I'm most involved with, looks like its settling on
> >> > versions like:
> >> >
> >> > 2.0-incubator-SNAPSHOT
> >> >
> >> > So the repository is clearly separated, and from a dependency element
> >> > in a Maven POM you can clearly see it's an incubator version.
> >> >
> >> > There was discussion that incubator repository would not be sync'd to
> >> > the central repository but I don't really see much point in this. A
> >> > few folks with incubating projects have voiced concerns that they
> >> > don't want to see their projects be taken out of circulation in the
> >> > central repository because they are incubating. If each and every
> >> > incubating project has a version for each artifact like that above
> >> > then it will be fairly clear that it's from the incubator. Moreso then
> >> > if you just had a repository definition pointing at the incubator
> >> > repository.
> >> >
> >> > Also someone may make an repository request to place an incubator
> >> > artifact in the central repository and at this point a policy mandated
> >> > here would conflict with someone's right to redistribute artifacts
> >> > created in the incubator. I don't really want to get into the business
> >> > of policing repository requests. I think it is in the best interests
> >> > of the incubating projects to have the incubator repository sync'd to
> >> > Maven's central repository. The source of artifacts for incubating
> >> > projects is clear from the version so I don't think there will be any
> >> > confusion by consumers of these artifacts and as such I don't really
> >> > see any downside to allowing the sync to Maven's central repository.
> >> >
> >> > Thoughts?
> >> >
> >> > Jason van Zyl
> >> > jason@maven.org
> >>
> >> +1.
> >>
> >> - Dan
> >>
> >> --
> >> Dan Diephouse
> >> Envoi Solutions
> >> http://envoisolutions.com
> >> http://netzooid.com/blog
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
>
>
> ---------------------------------------------------------------------
> 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Why?
Davanum Srinivas wrote:
> If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
> artifacts to maven central repo.
>
> -- dims
>
> On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> Jason van Zyl wrote:
>> > Hi,
>> >
>> > It looks like people objected to creating another mailing list for
>> > policy so I just used [policy] as Robert did in a previous message.
>> >
>> > Henri has setup Maven repositories for the incubator and there is a
>> > document which is an attempt to describe the current setup here:
>> >
>> > http://www.apache.org/dev/repository-faq.html
>> >
>> > I think that everyone agrees that a separate repository for incubating
>> > projects is a good idea as
>> >
>> > 1) you can clearly see what incubator artifacts have been created
>> > 2) we can perform analysis and create reports for incubator artifacts
>> > easily (using Archiva, the maven repository manager)
>> > 3) separating the administration duties of the incubator repository is
>> > a good idea I think. This might involve a different instance of
>> > Archiva and/or different people looking after the respective
>> repositories
>> >
>> > I haven't looked at all the projects using Maven in the incubator but
>> > cxf, the one I'm most involved with, looks like its settling on
>> > versions like:
>> >
>> > 2.0-incubator-SNAPSHOT
>> >
>> > So the repository is clearly separated, and from a dependency element
>> > in a Maven POM you can clearly see it's an incubator version.
>> >
>> > There was discussion that incubator repository would not be sync'd to
>> > the central repository but I don't really see much point in this. A
>> > few folks with incubating projects have voiced concerns that they
>> > don't want to see their projects be taken out of circulation in the
>> > central repository because they are incubating. If each and every
>> > incubating project has a version for each artifact like that above
>> > then it will be fairly clear that it's from the incubator. Moreso then
>> > if you just had a repository definition pointing at the incubator
>> > repository.
>> >
>> > Also someone may make an repository request to place an incubator
>> > artifact in the central repository and at this point a policy mandated
>> > here would conflict with someone's right to redistribute artifacts
>> > created in the incubator. I don't really want to get into the business
>> > of policing repository requests. I think it is in the best interests
>> > of the incubating projects to have the incubator repository sync'd to
>> > Maven's central repository. The source of artifacts for incubating
>> > projects is clear from the version so I don't think there will be any
>> > confusion by consumers of these artifacts and as such I don't really
>> > see any downside to allowing the sync to Maven's central repository.
>> >
>> > Thoughts?
>> >
>> > Jason van Zyl
>> > jason@maven.org
>>
>> +1.
>>
>> - Dan
>>
>> --
>> Dan Diephouse
>> Envoi Solutions
>> http://envoisolutions.com
>> http://netzooid.com/blog
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Justin Erenkrantz wrote:
> On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>> Well it can be run around right now too. I as a user of an incubating
>> project can request that a jar be uploaded to ibiblio. The incubator and
>> ibiblio policies are distinct. Unless the incubator can enforce policy
>> on the Ibiblio/Maven project for them to police the artifacts, they can
>> currently be redistributed on Ibiblio, it is just an extra pain for me
>> as a user.
>
> As I understand it, the ibiblio repository is under the de facto
> control of the Maven PMC. So, if the policy was that only project
> owners can upload the JARs, that would be respected. -- justin
I don't believe thats the current policy. Some projects don't care about
maven, so users need to take things into their own hands.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Aug 30, 2006 at 10:41:05AM -0700, Justin Erenkrantz wrote:
> On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> >Well it can be run around right now too. I as a user of an incubating
> >project can request that a jar be uploaded to ibiblio. The incubator and
> >ibiblio policies are distinct. Unless the incubator can enforce policy
> >on the Ibiblio/Maven project for them to police the artifacts, they can
> >currently be redistributed on Ibiblio, it is just an extra pain for me
> >as a user.
<silly>And a naughty little user you would be. Stop running around and be
nice now. Shoosh! Shoosh!</silly>
> As I understand it, the ibiblio repository is under the de facto
> control of the Maven PMC.
http://maven.apache.org/guides/mini/guide-ibiblio-upload.html
The instructions for getting stuff up there are on the apache maven
site. They basically come down to a set of technical instructions for
how to interface with the jira hosted at codehaus. The relevant
jira projects are adminned by Jason van Zyl, Carlos Sanchez seems to
be processing the vast majority of the requests, with Brett Porter
chipping in every now and then.
So, yes, that seems a fair assessment.
However, ibiblio does sync automatically sync with various repositories
*not* under the control (codehaus, jetty, opensymphony, os java) of the
maven PMC, so control is shared with other open source groups.
> So, if the policy was that only project
> owners can upload the JARs, that would be respected. -- justin
The written policy is only about the technical steps needed. In practice,
it seems the repo administrators do do *some* kind of quality control. For
example, if a user uploads new jars for - say- tomcat, he'll often get
told to work with the tomcat developers to just fix the main "pom" files
(which defines how jars are built, named, versioned, published, etc).
I doubt that if the incubator PMC would ask the maven PMC to apply a
patch to their technical policy which says "please do not request the
upload of jars from the apache incubator" they would refuse it, but I
suspect they may not want to be held responsible for enforcing it. The
ibiblio repo just isn't audited right now or held subject to similar
policies as the ASF /dist/ location. Eg they potentially would need to go
after opensymphony for putting incubator jars in their repositories, which
are synced to ibiblio. HenkP can share stories of exactly how much work all
that really is. Of course, the opensymphony folks are not going to do
something silly like that, so there's no *real* issue, just a potential
one.
If we do want that kind of auditing to happen, I suspect the dialogue
should go onto dev@maven or user(s)@maven so the people that do the repo
admin work are involved.
I know I gave up on this kind of agreed-on quality control for the ASF
releases a long time ago. Now I just try and make it policy that ibiblio is
not used for the projects I work on. *ducks*
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> Well it can be run around right now too. I as a user of an incubating
> project can request that a jar be uploaded to ibiblio. The incubator and
> ibiblio policies are distinct. Unless the incubator can enforce policy
> on the Ibiblio/Maven project for them to police the artifacts, they can
> currently be redistributed on Ibiblio, it is just an extra pain for me
> as a user.
As I understand it, the ibiblio repository is under the de facto
control of the Maven PMC. So, if the policy was that only project
owners can upload the JARs, that would be respected. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Justin Erenkrantz wrote:
> On 8/30/06, Davanum Srinivas <da...@gmail.com> wrote:
>> If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
>> artifacts to maven central repo.
>
> I would -1 it as well.
>
> The idea behind a separate repository was to make it very explicit to
> the user that they are fetching stuff from the Incubator. This
> strikes me as an end-run around that policy... -- justin
>
Well it can be run around right now too. I as a user of an incubating
project can request that a jar be uploaded to ibiblio. The incubator and
ibiblio policies are distinct. Unless the incubator can enforce policy
on the Ibiblio/Maven project for them to police the artifacts, they can
currently be redistributed on Ibiblio, it is just an extra pain for me
as a user.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/30/06, Davanum Srinivas <da...@gmail.com> wrote:
> If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
> artifacts to maven central repo.
I would -1 it as well.
The idea behind a separate repository was to make it very explicit to
the user that they are fetching stuff from the Incubator. This
strikes me as an end-run around that policy... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Davanum Srinivas <da...@gmail.com>.
If it comes to a VOTE, i'd vote -1 on automatic syncing of incubator
artifacts to maven central repo.
-- dims
On 8/30/06, Dan Diephouse <da...@envoisolutions.com> wrote:
> Jason van Zyl wrote:
> > Hi,
> >
> > It looks like people objected to creating another mailing list for
> > policy so I just used [policy] as Robert did in a previous message.
> >
> > Henri has setup Maven repositories for the incubator and there is a
> > document which is an attempt to describe the current setup here:
> >
> > http://www.apache.org/dev/repository-faq.html
> >
> > I think that everyone agrees that a separate repository for incubating
> > projects is a good idea as
> >
> > 1) you can clearly see what incubator artifacts have been created
> > 2) we can perform analysis and create reports for incubator artifacts
> > easily (using Archiva, the maven repository manager)
> > 3) separating the administration duties of the incubator repository is
> > a good idea I think. This might involve a different instance of
> > Archiva and/or different people looking after the respective repositories
> >
> > I haven't looked at all the projects using Maven in the incubator but
> > cxf, the one I'm most involved with, looks like its settling on
> > versions like:
> >
> > 2.0-incubator-SNAPSHOT
> >
> > So the repository is clearly separated, and from a dependency element
> > in a Maven POM you can clearly see it's an incubator version.
> >
> > There was discussion that incubator repository would not be sync'd to
> > the central repository but I don't really see much point in this. A
> > few folks with incubating projects have voiced concerns that they
> > don't want to see their projects be taken out of circulation in the
> > central repository because they are incubating. If each and every
> > incubating project has a version for each artifact like that above
> > then it will be fairly clear that it's from the incubator. Moreso then
> > if you just had a repository definition pointing at the incubator
> > repository.
> >
> > Also someone may make an repository request to place an incubator
> > artifact in the central repository and at this point a policy mandated
> > here would conflict with someone's right to redistribute artifacts
> > created in the incubator. I don't really want to get into the business
> > of policing repository requests. I think it is in the best interests
> > of the incubating projects to have the incubator repository sync'd to
> > Maven's central repository. The source of artifacts for incubating
> > projects is clear from the version so I don't think there will be any
> > confusion by consumers of these artifacts and as such I don't really
> > see any downside to allowing the sync to Maven's central repository.
> >
> > Thoughts?
> >
> > Jason van Zyl
> > jason@maven.org
>
> +1.
>
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
>
>
> ---------------------------------------------------------------------
> 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Jason van Zyl wrote:
> Hi,
>
> It looks like people objected to creating another mailing list for
> policy so I just used [policy] as Robert did in a previous message.
>
> Henri has setup Maven repositories for the incubator and there is a
> document which is an attempt to describe the current setup here:
>
> http://www.apache.org/dev/repository-faq.html
>
> I think that everyone agrees that a separate repository for incubating
> projects is a good idea as
>
> 1) you can clearly see what incubator artifacts have been created
> 2) we can perform analysis and create reports for incubator artifacts
> easily (using Archiva, the maven repository manager)
> 3) separating the administration duties of the incubator repository is
> a good idea I think. This might involve a different instance of
> Archiva and/or different people looking after the respective repositories
>
> I haven't looked at all the projects using Maven in the incubator but
> cxf, the one I'm most involved with, looks like its settling on
> versions like:
>
> 2.0-incubator-SNAPSHOT
>
> So the repository is clearly separated, and from a dependency element
> in a Maven POM you can clearly see it's an incubator version.
>
> There was discussion that incubator repository would not be sync'd to
> the central repository but I don't really see much point in this. A
> few folks with incubating projects have voiced concerns that they
> don't want to see their projects be taken out of circulation in the
> central repository because they are incubating. If each and every
> incubating project has a version for each artifact like that above
> then it will be fairly clear that it's from the incubator. Moreso then
> if you just had a repository definition pointing at the incubator
> repository.
>
> Also someone may make an repository request to place an incubator
> artifact in the central repository and at this point a policy mandated
> here would conflict with someone's right to redistribute artifacts
> created in the incubator. I don't really want to get into the business
> of policing repository requests. I think it is in the best interests
> of the incubating projects to have the incubator repository sync'd to
> Maven's central repository. The source of artifacts for incubating
> projects is clear from the version so I don't think there will be any
> confusion by consumers of these artifacts and as such I don't really
> see any downside to allowing the sync to Maven's central repository.
>
> Thoughts?
>
> Jason van Zyl
> jason@maven.org
+1.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Marc,
That's one of the flux items being discussed. I am not clear when
this is going to be resolved; hopefully shortly.
Craig
On Aug 27, 2006, at 11:54 AM, Marc Prud'hommeaux wrote:
> Craig-
>
> Does that that we should still deploy the snapshots to the "m2-
> snapshot-repository" (instead of, e.g., "m2-incubating-
> repository")? The clause: "The incubating repositories are for
> releases from projects within the Apache Incubator - incubating
> snapshots still goto the snapshot repositories." seems to suggest
> so, but I don't think it is completely clear.
>
>
> On Aug 27, 2006, at 11:28 AM, Craig L Russell wrote:
>
>> FYI, policy is still a bit in flux...
>>
>> Craig
>>
>> Begin forwarded message:
>>
>>> From: Jason van Zyl <ja...@maven.org>
>>> Date: August 27, 2006 9:44:58 AM PDT
>>> To: general@incubator.apache.org
>>> Subject: [policy] incubating projects and maven repositories v1.0
>>> Reply-To: general@incubator.apache.org
>>>
>>> Hi,
>>>
>>> It looks like people objected to creating another mailing list
>>> for policy so I just used [policy] as Robert did in a previous
>>> message.
>>>
>>> Henri has setup Maven repositories for the incubator and there is
>>> a document which is an attempt to describe the current setup here:
>>>
>>> http://www.apache.org/dev/repository-faq.html
>>>
>>> I think that everyone agrees that a separate repository for
>>> incubating projects is a good idea as
>>>
>>> 1) you can clearly see what incubator artifacts have been created
>>> 2) we can perform analysis and create reports for incubator
>>> artifacts easily (using Archiva, the maven repository manager)
>>> 3) separating the administration duties of the incubator
>>> repository is a good idea I think. This might involve a different
>>> instance of Archiva and/or different people looking after the
>>> respective repositories
>>>
>>> I haven't looked at all the projects using Maven in the incubator
>>> but cxf, the one I'm most involved with, looks like its settling
>>> on versions like:
>>>
>>> 2.0-incubator-SNAPSHOT
>>>
>>> So the repository is clearly separated, and from a dependency
>>> element in a Maven POM you can clearly see it's an incubator
>>> version.
>>>
>>> There was discussion that incubator repository would not be
>>> sync'd to the central repository but I don't really see much
>>> point in this. A few folks with incubating projects have voiced
>>> concerns that they don't want to see their projects be taken out
>>> of circulation in the central repository because they are
>>> incubating. If each and every incubating project has a version
>>> for each artifact like that above then it will be fairly clear
>>> that it's from the incubator. Moreso then if you just had a
>>> repository definition pointing at the incubator repository.
>>>
>>> Also someone may make an repository request to place an incubator
>>> artifact in the central repository and at this point a policy
>>> mandated here would conflict with someone's right to redistribute
>>> artifacts created in the incubator. I don't really want to get
>>> into the business of policing repository requests. I think it is
>>> in the best interests of the incubating projects to have the
>>> incubator repository sync'd to Maven's central repository. The
>>> source of artifacts for incubating projects is clear from the
>>> version so I don't think there will be any confusion by consumers
>>> of these artifacts and as such I don't really see any downside to
>>> allowing the sync to Maven's central repository.
>>>
>>> Thoughts?
>>>
>>> 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
>>>
>>
>> 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!
>>
>
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: [policy] incubating projects and maven repositories v1.0
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Craig-
Does that that we should still deploy the snapshots to the "m2-
snapshot-repository" (instead of, e.g., "m2-incubating-repository")?
The clause: "The incubating repositories are for releases from
projects within the Apache Incubator - incubating snapshots still
goto the snapshot repositories." seems to suggest so, but I don't
think it is completely clear.
On Aug 27, 2006, at 11:28 AM, Craig L Russell wrote:
> FYI, policy is still a bit in flux...
>
> Craig
>
> Begin forwarded message:
>
>> From: Jason van Zyl <ja...@maven.org>
>> Date: August 27, 2006 9:44:58 AM PDT
>> To: general@incubator.apache.org
>> Subject: [policy] incubating projects and maven repositories v1.0
>> Reply-To: general@incubator.apache.org
>>
>> Hi,
>>
>> It looks like people objected to creating another mailing list for
>> policy so I just used [policy] as Robert did in a previous message.
>>
>> Henri has setup Maven repositories for the incubator and there is
>> a document which is an attempt to describe the current setup here:
>>
>> http://www.apache.org/dev/repository-faq.html
>>
>> I think that everyone agrees that a separate repository for
>> incubating projects is a good idea as
>>
>> 1) you can clearly see what incubator artifacts have been created
>> 2) we can perform analysis and create reports for incubator
>> artifacts easily (using Archiva, the maven repository manager)
>> 3) separating the administration duties of the incubator
>> repository is a good idea I think. This might involve a different
>> instance of Archiva and/or different people looking after the
>> respective repositories
>>
>> I haven't looked at all the projects using Maven in the incubator
>> but cxf, the one I'm most involved with, looks like its settling
>> on versions like:
>>
>> 2.0-incubator-SNAPSHOT
>>
>> So the repository is clearly separated, and from a dependency
>> element in a Maven POM you can clearly see it's an incubator version.
>>
>> There was discussion that incubator repository would not be sync'd
>> to the central repository but I don't really see much point in
>> this. A few folks with incubating projects have voiced concerns
>> that they don't want to see their projects be taken out of
>> circulation in the central repository because they are incubating.
>> If each and every incubating project has a version for each
>> artifact like that above then it will be fairly clear that it's
>> from the incubator. Moreso then if you just had a repository
>> definition pointing at the incubator repository.
>>
>> Also someone may make an repository request to place an incubator
>> artifact in the central repository and at this point a policy
>> mandated here would conflict with someone's right to redistribute
>> artifacts created in the incubator. I don't really want to get
>> into the business of policing repository requests. I think it is
>> in the best interests of the incubating projects to have the
>> incubator repository sync'd to Maven's central repository. The
>> source of artifacts for incubating projects is clear from the
>> version so I don't think there will be any confusion by consumers
>> of these artifacts and as such I don't really see any downside to
>> allowing the sync to Maven's central repository.
>>
>> Thoughts?
>>
>> 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
>>
>
> 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!
>
Fwd: [policy] incubating projects and maven repositories v1.0
Posted by Craig L Russell <Cr...@Sun.COM>.
FYI, policy is still a bit in flux...
Craig
Begin forwarded message:
> From: Jason van Zyl <ja...@maven.org>
> Date: August 27, 2006 9:44:58 AM PDT
> To: general@incubator.apache.org
> Subject: [policy] incubating projects and maven repositories v1.0
> Reply-To: general@incubator.apache.org
>
> Hi,
>
> It looks like people objected to creating another mailing list for
> policy so I just used [policy] as Robert did in a previous message.
>
> Henri has setup Maven repositories for the incubator and there is a
> document which is an attempt to describe the current setup here:
>
> http://www.apache.org/dev/repository-faq.html
>
> I think that everyone agrees that a separate repository for
> incubating projects is a good idea as
>
> 1) you can clearly see what incubator artifacts have been created
> 2) we can perform analysis and create reports for incubator
> artifacts easily (using Archiva, the maven repository manager)
> 3) separating the administration duties of the incubator repository
> is a good idea I think. This might involve a different instance of
> Archiva and/or different people looking after the respective
> repositories
>
> I haven't looked at all the projects using Maven in the incubator
> but cxf, the one I'm most involved with, looks like its settling on
> versions like:
>
> 2.0-incubator-SNAPSHOT
>
> So the repository is clearly separated, and from a dependency
> element in a Maven POM you can clearly see it's an incubator version.
>
> There was discussion that incubator repository would not be sync'd
> to the central repository but I don't really see much point in
> this. A few folks with incubating projects have voiced concerns
> that they don't want to see their projects be taken out of
> circulation in the central repository because they are incubating.
> If each and every incubating project has a version for each
> artifact like that above then it will be fairly clear that it's
> from the incubator. Moreso then if you just had a repository
> definition pointing at the incubator repository.
>
> Also someone may make an repository request to place an incubator
> artifact in the central repository and at this point a policy
> mandated here would conflict with someone's right to redistribute
> artifacts created in the incubator. I don't really want to get into
> the business of policing repository requests. I think it is in the
> best interests of the incubating projects to have the incubator
> repository sync'd to Maven's central repository. The source of
> artifacts for incubating projects is clear from the version so I
> don't think there will be any confusion by consumers of these
> artifacts and as such I don't really see any downside to allowing
> the sync to Maven's central repository.
>
> Thoughts?
>
> 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
>
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: [policy] incubating projects and maven repositories v1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 31 August 2006 00:15, Dan Diephouse wrote:
> I don't really think that this is going to help anything. The user is
> always in control. The responsibility has never left their hands. Lets
> step away from the incubator a sec and take GPL jars for instance - if
> there is a transitive dependency on GPL jars, the user is completely
> responsible for that.
> Why would it be any different for an incubator JAR?
The difference is that no Apache project has a transitive dependency on a
GPL'd project. The Apache PMC is responsible to ensure that no GPL code is
sneaking in via transitive dependencies, and an improved reporting facility
in Maven's release plugin would *really* be good, both for licensing and
other concerns.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Dan Diephouse <da...@envoisolutions.com>.
Niclas Hedhman wrote:
> On Monday 28 August 2006 11:31, Jason van Zyl wrote:
>
>>> Could that report be made part of the release:prepare and the
>>> release manager
>>> had to explicitly approve it??
>>>
>> How are we supposed to enforce that? And what if they are not using
>> Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http
>> get to get artifacts from a repository.
>>
>
> We are probably misunderstanding each other...
> The question that came up was about transitive dependencies, which the user do
> not necessarily check for, and could end up being dependent on incubating
> projects against his/her will. Something that can't happen for snapshots
> (unless you bypass Maven's intended behaviours)
>
> You said, that one can check the full set of dependencies from a report
> generated by Maven2.
>
> I said, if that report could be output during the release:prepare phase, and
> that if the release:prepare phase would require the release manager to
> approve the use of that dependency tree, then we put the responsibility in
> the hands of the Maven2 user.
>
> You then start talking about 'enforcement'... And I am lost. Enforcing what?
> If the report can be generated, then either your statement above isn't valid,
> or the report is not capable of reporting the dependencies, in which case the
> original statement is not accurate.
>
> I suspect that you are trying to find problems with non-Maven systems, but
> that can always happen and not the issue at hand. BuildSystemAbc could pull
> down all kinds of stuff for the users, including snapshots, pirated software
> and virii. IMHO, Maven repositories exist mainly to support Maven and
> Maven-compatible(!) build systems.
>
> Your suggestions in the original mail is very good, and *I* don't have any
> opinion about whether a separate Incubating repository is needed or not. Both
> arguments for and against sound reasonable.
>
I don't really think that this is going to help anything. The user is
always in control. The responsibility has never left their hands. Lets
step away from the incubator a sec and take GPL jars for instance - if
there is a transitive dependency on GPL jars, the user is completely
responsible for that. Why would it be any different for an incubator JAR?
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 28 August 2006 11:31, Jason van Zyl wrote:
> > Could that report be made part of the release:prepare and the
> > release manager
> > had to explicitly approve it??
>
> How are we supposed to enforce that? And what if they are not using
> Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http
> get to get artifacts from a repository.
We are probably misunderstanding each other...
The question that came up was about transitive dependencies, which the user do
not necessarily check for, and could end up being dependent on incubating
projects against his/her will. Something that can't happen for snapshots
(unless you bypass Maven's intended behaviours)
You said, that one can check the full set of dependencies from a report
generated by Maven2.
I said, if that report could be output during the release:prepare phase, and
that if the release:prepare phase would require the release manager to
approve the use of that dependency tree, then we put the responsibility in
the hands of the Maven2 user.
You then start talking about 'enforcement'... And I am lost. Enforcing what?
If the report can be generated, then either your statement above isn't valid,
or the report is not capable of reporting the dependencies, in which case the
original statement is not accurate.
I suspect that you are trying to find problems with non-Maven systems, but
that can always happen and not the issue at hand. BuildSystemAbc could pull
down all kinds of stuff for the users, including snapshots, pirated software
and virii. IMHO, Maven repositories exist mainly to support Maven and
Maven-compatible(!) build systems.
Your suggestions in the original mail is very good, and *I* don't have any
opinion about whether a separate Incubating repository is needed or not. Both
arguments for and against sound reasonable.
Cheers
Niclas
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
On 27 Aug 06, at 10:26 PM 27 Aug 06, Niclas Hedhman wrote:
> On Monday 28 August 2006 08:58, Jason van Zyl wrote:
>>> Perhaps Maven can help by not allowing the transitive dependency on
>>> incubating projects? Just thinking out loud...
>>
>> If you can clearly see what you have in a report so I'm not sure we
>> would want to put any special rules in place to deal with artifacts
>> from incubator.
>
> Could that report be made part of the release:prepare and the
> release manager
> had to explicitly approve it??
How are we supposed to enforce that? And what if they are not using
Maven? Say using either the Maven Ant Tasks, or Ivy, or just an http
get to get artifacts from a repository.
> If so, then I'm totally cool with no other
> Maven adjustments to deal with incubating projects.
Generating the site is not part of a standard release, though it's
usually done as part of a release, and I'm not sure how you're going
to enforce that for every possible project that might use something
from the incubator.
>
>
> Cheers
> Niclas
>
> ---------------------------------------------------------------------
> 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 28 August 2006 08:58, Jason van Zyl wrote:
> > Perhaps Maven can help by not allowing the transitive dependency on
> > incubating projects? Just thinking out loud...
>
> If you can clearly see what you have in a report so I'm not sure we
> would want to put any special rules in place to deal with artifacts
> from incubator.
Could that report be made part of the release:prepare and the release manager
had to explicitly approve it?? If so, then I'm totally cool with no other
Maven adjustments to deal with incubating projects.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
On 27 Aug 06, at 6:28 PM 27 Aug 06, Craig L Russell wrote:
>
> On Aug 27, 2006, at 2:22 PM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On 8/27/06, Jason van Zyl <ja...@maven.org> wrote:
>>> There was discussion that incubator repository would not be
>>> sync'd to
>>> the central repository but I don't really see much point in this.
>>> [...]
>>> Also someone may make an repository request to place an incubator
>>> artifact in the central repository and at this point a policy
>>> mandated here would conflict with someone's right to redistribute
>>> artifacts created in the incubator. I don't really want to get into
>>> the business of policing repository requests. I think it is in the
>>> best interests of the incubating projects to have the incubator
>>> repository sync'd to Maven's central repository. The source of
>>> artifacts for incubating projects is clear from the version so I
>>> don't think there will be any confusion by consumers of these
>>> artifacts and as such I don't really see any downside to allowing
>>> the
>>> sync to Maven's central repository.
>>
>> Me neither. But why do we then need the separate incubator repository
>> if the artifacts get synchronized with the central repository?
>>
>> As I mentioned in the thread before the Incubator Maven repository
>> was
>> created, it makes more sense to enforce an "incubator" label on the
>> artifact versions than enforcing a specific "incubator" repository.
>> Especially since there is no way for us to really enforce that
>> repository policy.
>
> I agree. I understand that we want users who choose to use an
> incubating project's artifacts to declaratively state that. If the
> artifact's name contains "incubating" then it's pretty clear.
>
> The only thing that muddles things for me is when using an m2
> repository that contains a non-incubating project with a dependency
> on an incubating project. Then, a project that depends on the
> project that is itself not in the incubator might not even know
> that it's using an incubating project.
The standard dependency report shows all transitive dependencies so
you can definitely see what you're using:
http://maven.apache.org/continuum/dependencies.html
Could be a little better in display but you can see what's in your
dependency set. There are also things like the netbeans m2
integration which draws nice graphs of the dependencies.
>
> Can this happen? Is it likely?
If you don't look at the dependency report or a graph then I suppose
it could.
> Is there any policy that we can put into place to avoid that
> projects with dependencies on projects with incubating projects
> accidentally have this dependency?
>
> Perhaps Maven can help by not allowing the transitive dependency on
> incubating projects? Just thinking out loud...
>
If you can clearly see what you have in a report so I'm not sure we
would want to put any special rules in place to deal with artifacts
from incubator.
> Craig
>
>
>>
>>
>> BR,
>>
>> Jukka Zitting
>>
>> --
>> Yukatan - http://yukatan.fi/ - info@yukatan.fi
>> Software craftsmanship, JCR consulting, and Java development
>>
>> ---------------------------------------------------------------------
>> 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!
>
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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 27, 2006, at 2:22 PM, Jukka Zitting wrote:
> Hi,
>
> On 8/27/06, Jason van Zyl <ja...@maven.org> wrote:
>> There was discussion that incubator repository would not be sync'd to
>> the central repository but I don't really see much point in this.
>> [...]
>> Also someone may make an repository request to place an incubator
>> artifact in the central repository and at this point a policy
>> mandated here would conflict with someone's right to redistribute
>> artifacts created in the incubator. I don't really want to get into
>> the business of policing repository requests. I think it is in the
>> best interests of the incubating projects to have the incubator
>> repository sync'd to Maven's central repository. The source of
>> artifacts for incubating projects is clear from the version so I
>> don't think there will be any confusion by consumers of these
>> artifacts and as such I don't really see any downside to allowing the
>> sync to Maven's central repository.
>
> Me neither. But why do we then need the separate incubator repository
> if the artifacts get synchronized with the central repository?
>
> As I mentioned in the thread before the Incubator Maven repository was
> created, it makes more sense to enforce an "incubator" label on the
> artifact versions than enforcing a specific "incubator" repository.
> Especially since there is no way for us to really enforce that
> repository policy.
I agree. I understand that we want users who choose to use an
incubating project's artifacts to declaratively state that. If the
artifact's name contains "incubating" then it's pretty clear.
The only thing that muddles things for me is when using an m2
repository that contains a non-incubating project with a dependency
on an incubating project. Then, a project that depends on the project
that is itself not in the incubator might not even know that it's
using an incubating project.
Can this happen? Is it likely? Is there any policy that we can put
into place to avoid that projects with dependencies on projects with
incubating projects accidentally have this dependency?
Perhaps Maven can help by not allowing the transitive dependency on
incubating projects? Just thinking out loud...
Craig
>
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
> ---------------------------------------------------------------------
> 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: [policy] incubating projects and maven repositories v1.0
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/27/06, Jason van Zyl <ja...@maven.org> wrote:
> There was discussion that incubator repository would not be sync'd to
> the central repository but I don't really see much point in this.
> [...]
> Also someone may make an repository request to place an incubator
> artifact in the central repository and at this point a policy
> mandated here would conflict with someone's right to redistribute
> artifacts created in the incubator. I don't really want to get into
> the business of policing repository requests. I think it is in the
> best interests of the incubating projects to have the incubator
> repository sync'd to Maven's central repository. The source of
> artifacts for incubating projects is clear from the version so I
> don't think there will be any confusion by consumers of these
> artifacts and as such I don't really see any downside to allowing the
> sync to Maven's central repository.
Me neither. But why do we then need the separate incubator repository
if the artifacts get synchronized with the central repository?
As I mentioned in the thread before the Incubator Maven repository was
created, it makes more sense to enforce an "incubator" label on the
artifact versions than enforcing a specific "incubator" repository.
Especially since there is no way for us to really enforce that
repository policy.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] incubating projects and maven repositories v1.0
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Aug 06, at 11:44 AM 28 Aug 06, Leo Simons wrote:
> On Sun, Aug 27, 2006 at 12:44:58PM -0400, Jason van Zyl wrote:
> <snip/>
>> There was discussion that incubator repository would not be sync'd to
>> the central repository but I don't really see much point in this. A
>> few folks with incubating projects have voiced concerns that they
>> don't want to see their projects be taken out of circulation in the
>> central repository because they are incubating. If each and every
>> incubating project has a version for each artifact like that above
>> then it will be fairly clear that it's from the incubator. Moreso
>> then if you just had a repository definition pointing at the
>> incubator repository.
>>
>> Also someone may make an repository request to place an incubator
>> artifact in the central repository and at this point a policy
>> mandated here would conflict with someone's right to redistribute
>> artifacts created in the incubator. I don't really want to get into
>> the business of policing repository requests. I think it is in the
>> best interests of the incubating projects to have the incubator
>> repository sync'd to Maven's central repository. The source of
>> artifacts for incubating projects is clear from the version so I
>> don't think there will be any confusion by consumers of these
>> artifacts and as such I don't really see any downside to allowing the
>> sync to Maven's central repository.
>>
>> Thoughts?
>
> "central repository" is ibiblio.org right?
Correct.
> Eg not an ASF machine?
Correct.
> I think
> its not up to the incubator to dictate policies on what external
> parties
> should and should not do with our software.
>
> It all comes back to being clear to users and providing a consistent
> message, and I think the steps we agreed on here (seperate repo, clear
> versioning, incubation notices on website and in readme) are
> sufficient,
> and I doubt we should go any further than that.
>
> If other ASF projects depend on projects that depend on projects that
> depend on incubating projects that are published on the ibiblio
> site and
> that is not sufficiently clear for users of that project, then that's
> not the responsibility of the incubator pmc to fix.
>
> IOW, I don't really want to to get into the business of policing
> anything
> but the bits we're actually responsible for policing :)
>
> So I'll withold actual thoughts (which would've been along the
> lines of
> "centralized storage is so 1990s") ;)
>
> LSD
>
> ---------------------------------------------------------------------
> 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
Re: [policy] incubating projects and maven repositories v1.0
Posted by Leo Simons <ma...@leosimons.com>.
On Sun, Aug 27, 2006 at 12:44:58PM -0400, Jason van Zyl wrote:
<snip/>
> There was discussion that incubator repository would not be sync'd to
> the central repository but I don't really see much point in this. A
> few folks with incubating projects have voiced concerns that they
> don't want to see their projects be taken out of circulation in the
> central repository because they are incubating. If each and every
> incubating project has a version for each artifact like that above
> then it will be fairly clear that it's from the incubator. Moreso
> then if you just had a repository definition pointing at the
> incubator repository.
>
> Also someone may make an repository request to place an incubator
> artifact in the central repository and at this point a policy
> mandated here would conflict with someone's right to redistribute
> artifacts created in the incubator. I don't really want to get into
> the business of policing repository requests. I think it is in the
> best interests of the incubating projects to have the incubator
> repository sync'd to Maven's central repository. The source of
> artifacts for incubating projects is clear from the version so I
> don't think there will be any confusion by consumers of these
> artifacts and as such I don't really see any downside to allowing the
> sync to Maven's central repository.
>
> Thoughts?
"central repository" is ibiblio.org right? Eg not an ASF machine? I think
its not up to the incubator to dictate policies on what external parties
should and should not do with our software.
It all comes back to being clear to users and providing a consistent
message, and I think the steps we agreed on here (seperate repo, clear
versioning, incubation notices on website and in readme) are sufficient,
and I doubt we should go any further than that.
If other ASF projects depend on projects that depend on projects that
depend on incubating projects that are published on the ibiblio site and
that is not sufficiently clear for users of that project, then that's
not the responsibility of the incubator pmc to fix.
IOW, I don't really want to to get into the business of policing anything
but the bits we're actually responsible for policing :)
So I'll withold actual thoughts (which would've been along the lines of
"centralized storage is so 1990s") ;)
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org