Re: [VOTE] Accept jclouds into the Apache Incubator

[Carlos Sanchez]

 at maginatics dot com
>  * Andrew Phillips, aphillips at qrmedia dot com
>  * Matt Stephenson, mattstep at mattstep dot net
>  * Everett Toews, everett dot toews at rackspace dot com
>  * Becca Wood, silkysun at silkysun dot net
>
> == Affiliations ==
>
>  * Ignasi Barrera, Abiquo
>  * Andrew Bayer, Cloudera
>  * Ioannis Canellos, Red Hat
>  * Adrian Cole, Netflix
>  * Andrew Gaul, Maginatics
>  * Matt Stephenson, Google
>  * Everett Toews, Rackspace
>
> == Sponsors ==
> === Champion ===
>
>  * Brian McCallister, Apache Software Foundation
>
> === Mentors ===
>
>  * Brian McCallister, Apache Software Foundation
>  * Tom White, Apache Software Foundation
>  * Henning Schmiedehausen, Apache Software Foundation
>  * David Nalley, Apache Software Foundation
>  * Jean-Baptiste Onofré, Apache Software Foundation
>  * Mohammad Nour El-Din, Apache Software Foundation
>  * Olivier Lamy, Apache Software Foundation
>  * Tomaz Muraus, Apache Software Foundation
>  * Suresh Marru, Apache Software Foundation
>  * Carlos Sanchez, Apache Software Foundation
>
> === Sponsoring Entity ===
>
> The jclouds contributors and community request sponsorship from the
> Incubator.
>
>

Re: [PROPOSAL] jclouds Proposal for Incubator

[Carlos Sanchez]

I contributed some code back in the day, so happy to help too.


On Tue, Apr 16, 2013 at 9:24 PM, Jean-Baptiste Onofré wrote:

> I'm very interested as well.
>
> I'm also volunteer to be mentor on the project.
>
> Regards
> JB
>
>
> On 04/16/2013 09:19 PM, David Nalley wrote:
>
>> On Tue, Apr 16, 2013 at 2:34 PM, Rebecca Wood  wrote:
>>
>>> Dear ASF members,
>>> We would like to propose the jclouds project to the Incubator.  The
>>> jclouds Proposal is available at:
>>>
>>> http://wiki.apache.org/**incubator/jcloudsProposal
>>>
>>> We welcome your feedback and suggestions.
>>>
>>
>> Excited to see jclouds proposal.
>> If you are looking for additional mentors, I'd be happy to step up.
>>
>> --David
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
> --**--**-
> To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
> For additional commands, e-mail: 
> general-help@incubator.apache.**org
>
>

Re: [VOTE] Accept Libcloud proposal for incubation

[Carlos Sanchez]

ld a last community around cloud API
> interoperability, and is not fascinated with any short term gains of
> being associated with the Apache Brand.
>
> Documentation
>
>    * 
> http://www.informationweek.com/cloud-computing/blog/archives/2009/01/the_urgent_issu.html
>    * http://broadcast.oreilly.com/2009/09/cloud-api-wars---where-is-the.html
>    * 
> http://blogs.gartner.com/lydia_leong/2009/08/27/are-multiple-cloud-apis-bad/
>    * http://deltacloud.org/
>
> Initial Source
>
> Initial source is contained completely inside the libcloud github repository.
>
> External Dependencies
>
>    * zope.interface
>    * For Python =< 2.5, a JSON Parser such as SimpleJSON is required.
>
> Cryptography
>
> Uses standard Python APIs for SSL/HTTPS.
>
> Required Resources
>
> Mailing lists
>
>    * libcloud-dev
>    * libcloud-commits
>    * libcloud-private
>
> Subversion
>
>    * https://svn.apache.org/repos/asf/incubator/libcloud
>
> Issue Tracking
>
>    * JIRA (LCLD)
>
> Initial Committers
>
>    * Alex Polvi 
>    * Dan Di Spaltro 
>    * Ivan Meredith 
>    * Jed Smith 
>    * Jeremy Orem 
>    * Jerry Chen 
>    * Logan Welliver 
>    * Paul Querna 
>    *Tom Davis 
>
> Sponsors
>
> Champion
>
>    * Paul Querna
>
> Nominated Mentors
>
>    * Gavin McDonald
>    * Jean-Frederic Clere
>    * Ant Elder
>    * Carlos Sanchez
>
> Sponsoring Entity
>
>    * Incubator PMC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Re: [PROPOSAL] Libcloud Project

[Carlos Sanchez]

+1 and I'm interested, in case you need a mentor

On Tue, Oct 27, 2009 at 9:56 PM, Niclas Hedhman  wrote:
> +1...
>
> There has been few new, accepted proposals lately...
>
> On Tue, Oct 27, 2009 at 2:59 PM, Paul Querna  wrote:
>> Hi,
>>
>> I would like to propose incubating the existing Libcloud project to
>> join the ASF:
>>
>> Proposal  Wiki: 
>>
>> Libcloud is a unified Python API around many common cloud services
>> provider, and I believe it could benefit greatly by joining the Apache
>> Software Foundation.  I also believe the ASF needs more Python
>> projects, and more projects involved in the developing cloud
>> infrastructure.  We still need a few mentors, so feel free to signup
>> :-)
>>
>> We would appreciate feedback and comments on the proposal.
>>
>> Full proposal is bellow.
>>
>> Thanks,
>>
>> Paul
>>
>> 
>> Libcloud, a unified interface to the cloud
>>
>> Abstract
>>
>> libcloud () is a pure python client library
>> for interacting with many of the popular cloud server providers. It
>> was created to make it easy for developers to build products that work
>> between any of the services that it supports.
>>
>> Proposal
>>
>>    * Provide unified API for manipulating servers instances across
>> many hosting providers who provide an API to manipulate instances.
>> Current API includes: list, reboot, create, destroy, list images, list
>> sizes.
>>
>>    * (future) Provide utilities for manipulating and creating server
>> images in many formats. (See the independent Stacklet project for
>> ideas)
>>
>>    * (future) Provide unified API for storing large objects on
>> popular hosting provider storage APIs.
>>
>> Background
>>
>> While there are some projects to create open standards for
>> interoperability within the cloud, most have failed to gain widespread
>> adoption. Libcloud takes the approach of exposing a unified API to
>> cover multiple vendor's APIs, and in the future to support standard
>> APIs, assuming they become prevalent.
>>
>> Rationale
>>
>> There is a strong need in the developing cloud infrastructure for a
>> community supported, high quality, and vendor independent tool set for
>> managing servers and their resources. When new servers are just an API
>> call away, traditional infrastructure models are changing quickly.
>> Having a good library built around Apache's values and tradition will
>> enable new server infrastructure to evolve much more quickly.
>>
>> Initial Goals
>>
>> Libcloud is an existing open source project, with patches from many
>> different contributors. We view the moving to Apache as a way to
>> improve this community, and look into future APIs around creating
>> server images and large object storage.
>>
>> Current Status
>>
>> Libcloud is already open source under the ASL 2.0:
>>
>>    * Libcloud Website 
>>    * Libcloud Mailing Lists 
>>    * Libcloud Source Control 
>>
>> Meritocracy
>>
>> Libcloud has involvement from members of both the ASF and other open
>> source projects. Communication is driven by both IRC and E-Mail lists.
>>
>> Community
>>
>> Currently libcloud has several contributors, but not a large user
>> community other than a few companies. We would like to increase our
>> userbase as part of the incubator process.
>>
>> Core Developers
>>
>> Alex Polvi who wrote most of the original code is familiar with open
>> source from working at OSUOSL and at Mozilla. Tom Davis drove much of
>> the re factoring of the initial code base. Jed Smith, Ivan Meredith,
>> Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all
>> contributed mainly to developing provider specific drivers.
>>
>> Alignment
>>
>> Currently there are not many Apache communities involved with cloud
>> computing or python based infrastructure. We believe introducing such
>> a community is a good thing for the Apache Software Foundation.
>>
>> Known Risks
>>
>> Orphaned products
>>
>> libcloud is being used actively by Cloudkick to develop services. It
>> is a core part of our ongoing infrastructure improvements.
>>
>> Inexperience with Open Source
>>
>> libcloud was open sourced in July 2009, during OSCON. Core
>> contributors include former employees of Mozilla and an ASF member.
>>
>> Homogenous Developers
>>
>> Much of the initial development was done by Cloudkick, but much of the
>> core design was re-factored by the community, and many of the drivers
>> for each provider have been contributed by 3rd parties.
>>
>> Reliance on Salaried Developers
>>
>> The majority, but not all, of the developers are paid by their
>> employer to work on libcloud at this time.
>>
>> Relationships with Other Apache Products
>>
>> Libcloud doesn't share many attributes with existing Apache projects
>> due to it being in Python and addressing a new need.
>>
>> A Excessive Fascination

Re: [PROPOSAL] Libcloud Project

[Carlos Sanchez]

+1  the idea is very interesting


On Tue, Oct 27, 2009 at 9:56 PM, Niclas Hedhman  wrote:
> +1...
>
> There has been few new, accepted proposals lately...
>
> On Tue, Oct 27, 2009 at 2:59 PM, Paul Querna  wrote:
>> Hi,
>>
>> I would like to propose incubating the existing Libcloud project to
>> join the ASF:
>>
>> Proposal  Wiki: 
>>
>> Libcloud is a unified Python API around many common cloud services
>> provider, and I believe it could benefit greatly by joining the Apache
>> Software Foundation.  I also believe the ASF needs more Python
>> projects, and more projects involved in the developing cloud
>> infrastructure.  We still need a few mentors, so feel free to signup
>> :-)
>>
>> We would appreciate feedback and comments on the proposal.
>>
>> Full proposal is bellow.
>>
>> Thanks,
>>
>> Paul
>>
>> 
>> Libcloud, a unified interface to the cloud
>>
>> Abstract
>>
>> libcloud () is a pure python client library
>> for interacting with many of the popular cloud server providers. It
>> was created to make it easy for developers to build products that work
>> between any of the services that it supports.
>>
>> Proposal
>>
>>    * Provide unified API for manipulating servers instances across
>> many hosting providers who provide an API to manipulate instances.
>> Current API includes: list, reboot, create, destroy, list images, list
>> sizes.
>>
>>    * (future) Provide utilities for manipulating and creating server
>> images in many formats. (See the independent Stacklet project for
>> ideas)
>>
>>    * (future) Provide unified API for storing large objects on
>> popular hosting provider storage APIs.
>>
>> Background
>>
>> While there are some projects to create open standards for
>> interoperability within the cloud, most have failed to gain widespread
>> adoption. Libcloud takes the approach of exposing a unified API to
>> cover multiple vendor's APIs, and in the future to support standard
>> APIs, assuming they become prevalent.
>>
>> Rationale
>>
>> There is a strong need in the developing cloud infrastructure for a
>> community supported, high quality, and vendor independent tool set for
>> managing servers and their resources. When new servers are just an API
>> call away, traditional infrastructure models are changing quickly.
>> Having a good library built around Apache's values and tradition will
>> enable new server infrastructure to evolve much more quickly.
>>
>> Initial Goals
>>
>> Libcloud is an existing open source project, with patches from many
>> different contributors. We view the moving to Apache as a way to
>> improve this community, and look into future APIs around creating
>> server images and large object storage.
>>
>> Current Status
>>
>> Libcloud is already open source under the ASL 2.0:
>>
>>    * Libcloud Website 
>>    * Libcloud Mailing Lists 
>>    * Libcloud Source Control 
>>
>> Meritocracy
>>
>> Libcloud has involvement from members of both the ASF and other open
>> source projects. Communication is driven by both IRC and E-Mail lists.
>>
>> Community
>>
>> Currently libcloud has several contributors, but not a large user
>> community other than a few companies. We would like to increase our
>> userbase as part of the incubator process.
>>
>> Core Developers
>>
>> Alex Polvi who wrote most of the original code is familiar with open
>> source from working at OSUOSL and at Mozilla. Tom Davis drove much of
>> the re factoring of the initial code base. Jed Smith, Ivan Meredith,
>> Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all
>> contributed mainly to developing provider specific drivers.
>>
>> Alignment
>>
>> Currently there are not many Apache communities involved with cloud
>> computing or python based infrastructure. We believe introducing such
>> a community is a good thing for the Apache Software Foundation.
>>
>> Known Risks
>>
>> Orphaned products
>>
>> libcloud is being used actively by Cloudkick to develop services. It
>> is a core part of our ongoing infrastructure improvements.
>>
>> Inexperience with Open Source
>>
>> libcloud was open sourced in July 2009, during OSCON. Core
>> contributors include former employees of Mozilla and an ASF member.
>>
>> Homogenous Developers
>>
>> Much of the initial development was done by Cloudkick, but much of the
>> core design was re-factored by the community, and many of the drivers
>> for each provider have been contributed by 3rd parties.
>>
>> Reliance on Salaried Developers
>>
>> The majority, but not all, of the developers are paid by their
>> employer to work on libcloud at this time.
>>
>> Relationships with Other Apache Products
>>
>> Libcloud doesn't share many attributes with existing Apache projects
>> due to it being in Python and addressing a new need.
>>
>> A Excessive Fascination with the Apach

Re: [POLL] Incubator Maven Repository

[Carlos Sanchez]

I didn't have a chance to talk about this with Shane but the idea in
the end is to make the repository agnostic on how things are stored
and how the client uses them.
Right now is a simple directory, but could be a database with a web
front end or anything like that.
It shouldn't matter how NMaven artifacts are stored, as long as the
client handles them correctly. A solution we talked about time ago was
to put them as any other artifacts and either developers could choose
what format their local repo is in or the pom could say how they
should be stored

But this is a total different discussion

On 5/6/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:


Shane,

Honestly, it sounds like the NMaven stuff will need a complete new set of
repositories for NMaven artifacts.   There isn't any way, IMO, that the
repo layout can change for the normal maven 1 and maven 2 repositories.

Incubator or repo1.maven.org is relatively irrelevant in that regards.
The layout is pretty much set in stone.  There are too many plugins
(deploy, etc...) that rely on it, there are too many other apps (several
different proxy applications, etc...) that rely on it, etc...

If the current layout is inadequate for NMaven, the NMaven team should
figure out an appropriate place for a new repository.   My personal
suggestion is to work with the Maven team and create a new area at
repo1.maven.org/nmaven or similar.   But that's me.  In either case, I
think that discussion is separate from where the m2 artifacts go.  It
make make sense to put the nmaven stuff in dist/incubator for a while
until the layout is finalized, then move to central.However, the
layouts for m1/m2 are finalized.  Thus, they can/should go to central.
(IMO)

That said, I don't know the NMaven details. But my #1 concern is your
line:
> I
> would expect that an incubator release repo would be more amendable to
> such changes.

No chance, IMO.   Once an artifact is released, it's SET IN STONE.   That
includes the layout of the repository it's sitting in.  Once theres the
possibility that another project is relying on a particular artifact to
be living at a particular location, it needs to stay there.   The
incubator m2 release repository is no different from central in that
regard.


Dan



On Sunday 06 May 2007 14:11, Shane Isbell wrote:
> [ ] use standard repositories
> [ x ] relocate repositories under /www.apache.org/dist/incubator
>
> My reasons are as follows: First, NMaven does not follow the standard
> repo layout; second, the repository layout structure is still in a
> state of flux, meaning that there is a need for potentially changing
> the layout for .NET artifacts, while still doing releases.
>
> Getting more into some more specifics, with NMaven, there is no
> version information contained within the artifact file name and the
> version must follow a standard 0.0.0.0 format. This precludes the use
> of "incubator" within the version itself. As mentioned above, at this
> early stage, it's also not 100% clear on exactly how NMaven .NET
> artifacts will reside within the repo. For instance, there is an open
> question as to where pom files will reside when we add the concept of
> classifiers to the repo. Also, given the repository layout structure
> for NET artifacts may change over time, as the incubator project
> evolves, I have concerns whether any of the standard maven repos would
> accept - and with good reason - an NMaven incubator release at all. I
> would expect that an incubator release repo would be more amendable to
> such changes.
>
> Shane
>
> On 5/6/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > [ x ] use standard repositories
> > [ ] relocate repositories under /www.apache.org/dist/incubator
> >
> > Eelco
> >
> > 
> >- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [repo] /www/people.apache.org/repo/m2-incubating-repository/

[Carlos Sanchez]

there's no automatic way to do it. You may leave the xml files as is
until the release is approved.

On 4/8/07, Michael Dick <[EMAIL PROTECTED]> wrote:

What is the best way to recover from erroneously published binaries?

Per Craig's email I should have waited to deploy until after the release
passed a vote on the open-jpa-dev mailing list. I took a look at the maven
repository and I noticed that some of the xml files were updated with the
new version of OpenJPA.

I can go through and remove the new jar files, and take the new version out
of the xml files by hand if that's the best / only way to recover. I'm a
little concerned that I'll break something else if I edit the xml files by
hand (maven-metadata.xml is one of them).

Is there a better way to recover? Or can the artifacts be left in place for
the time being while the vote goes on?

I didn't mean to skirt the process at all, I thought that the artifacts
could be deployed before either vote took place. I am just looking for the
best way to recover and then allow the votes to go forward.

Thanks,
Michael Dick

On 4/8/07, Michael Dick <[EMAIL PROTECTED]> wrote:
>
> Hi Craig,
>
> I thought that deploying them before the vote was a little odd too. I was
> planning on calling for the vote tomorrow (after Easter weekend). In the
> mean time, I'll go ahead and remove the artifacts from people.apache.org.
>
>
> On 4/8/07, Craig L Russell <[EMAIL PROTECTED] > wrote:
> >
> > Hi Mike,
> >
> > Something is wrong with the openjpa release process. Artifacts should
> > not be uploaded to the repository until they are voted out of the
> > project. Until they are ready, you should stage the proposed release,
> > sign it, and after you're sure it's ready to go, call for a review on
> > the dev list, and then call for a vote on the incubator general alias
> > and dev list.
> >
> > You only need one checksum but need a gpg ascii armored signature. So
> > you need the artifact and the artifact.asc (gpg signature) and
> > artifact.md5 to be in the staging area. The sha1 is not needed.
> >
> > This should be part of the release process that's documented...
> >
> > Craig
> >
> > Begin forwarded message:
> >
> > > From: Carlos Sanchez < [EMAIL PROTECTED]>
> > > Date: April 8, 2007 12:40:01 PM PDT
> > > To: [EMAIL PROTECTED]
> > > Cc: repository@apache.org
> > > Subject: Re: [repo] /www/people.apache.org/repo/m2-incubating-
> > > repository/
> > > Reply-To: repository@apache.org
> > >
> > > please add PGP signatures, it's apache policy to sign all releases
> > >
> > > take a look at the latest maven parent pom on how to use the gpg
> > > plugin for automatic signing
> > >
> > > http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-
> > > parent-5.pom
> > >
> > >
> > > On 8 Apr 2007 08:17:08 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > > wrote:
> > >> Repository changed
> > >> ==
> > >>
> > >> Repository: /www/people.apache.org/repo/m2-incubating-repository/
> > >>
> > >> Added
> > >> -
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating.pom
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating.pom.md5
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating.pom.sha1
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating-site.xml
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating-site.xml.md5
> > >> [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7-
> > >> incubating-site.xml.sha1
> > >> [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating
> > >> [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa-
> > >> lib-0.9.7-incubating.jar
> > >> [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa-
> > >> lib-0.9.7-incubating.jar.md5
> > >> [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa-
> > >> lib-0.9.7-incubating.jar.sha1
> > >> [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa-
> > >> lib-0.9.7-incubating.pom
> > >> [mikedd] org/apache/openjpa/openjpa

Re: Killing the incubator m2 repository

[Carlos Sanchez]

On 3/16/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Carlos Sanchez wrote:

> 1. central repo must be self contained, all artifacts in central
> repository must have dependencies already in central, only exception
> is if license doesn't allow redistribution but in that case the pom
> must be there explaining what that artifact is.

This is a Maven repository policy?  Justification(s)?


this is a "central" repository policy to simplify life for users and
avoid complains like "I use A and depends on B that is missing in the
repo"

it was never really enforced though, but if i see that happening i
contact people to get it fixed and prevent uploads, very hard to do in
synced repos so active like apache.

now i guess people is circumventing it by adding external repositories
in A pom, like the incubating one, which defeats the whole purpose of
it as it's transparent for the user, and making people get stuff from
other repos without noticing, which probably was never a planned
"feature".

About "nobody prevents ASL artifacts to be uploaded" that's true as i
mentioned also, but they can't be under org.apache if the ASF don't
want to. I won't prevent them from being in other group, it's a matter
of the ASF and the incubating project, so it would be up to the
incubator to decide if they can keep releasing under the previous
group that they were using before.




--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Difference between Maven repository and dist directory

[Carlos Sanchez]

Let's be clear, the central repo can host apache incubating artifacts,
it's not its business, it's an ASF business.

Now, only the ASF can publish under org.apache groupId through the
repos setup in the ASF boxes that are automatically setup

But if John Doe decides to publish an incubator artifact under
com.johndoe there's nothing the ASF can do as the ASL grants
redistribution. Now it's up to the users to trust com.johndoe
artifacts.


On 3/15/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:

I can understand that the Apache "dist" directory is something
reserved for certain artifacts. Fact is, the ibiblio repository (as
opposed to the incubator repository) is not.

The ibiblio repository is specifically designed to hold artifacts of
all kinds, if the license permits. There are all kind of jar files of
all kind of sources. If artifacts are in the designated incubator
repository, then nothing prevents external users from uploading them
to Ibiblio, which is usually done sooner or later. (If the artifacts
are actually in use.)

In other words, your intention that users have "to configure any
repository" is lost. You cannot prevent that. Or are you telling me
that the owner of the incubator artifacts (typically the ASF) reserves
particular distribution rights, which are limiting the ASL? All you
achieve is that the POM ifiles of ncubator artifacts typically have a
lesser quality, because they aren't maintained by the project owners.


Jochen

--
Emacs 22 will support MacOS and CygWin. It is not yet decided, whether
these will be used to run Emacs or the other way round.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Killing the incubator m2 repository

[Carlos Sanchez]

On 3/15/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Actually, both cases appear to be the same because in case #1, unless the
user is not part of collaborative effort, someone else could have added the
repository to the pom.xml for the project.  Apparently, Maven doesn't
require the user to authorize each repository, and just assumes that it must
be OK if someone stuck it in a pom.xml file.


For projects in the central repository is a requirement that all
dependencies are in central and no other repositories with releases
are listed

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Killing the incubator m2 repository

[Carlos Sanchez]

some Maven/repository details that I don't think were clear in previous threads:

1. central repo must be self contained, all artifacts in central
repository must have dependencies already in central, only exception
is if license doesn't allow redistribution but in that case the pom
must be there explaining what that artifact is.

2. per #1 projects with incubating dependencies can't be in central

3. it's an apache policy not to put incubating artifacts in central,
not a "central repository" policy, which could mean that incubating
projects could put their artifacts in org.myproject it'd be a
problem between them and the ASF

4. all repositories in the pom will be pinged until the dependency is
downloaded, this is by design, we don't want to specify for each
dependency where it is

5. order of repos is not defined so far, so central can be pinged for
incubating artifacts or p.a.o for central artifacts before they are
downloaded, the performance problem would only happen in the second
case

hope I put some light in the issue

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]