I don't care about all the transitive deps maven is downloading and
caching in my local repository and I don't expect any maven user to
control the content of its local repository (mine is more than 2 Go
and i've no clue what's inside besides what i directly use). I'm
talking about maven as a buil
On Sat, May 31, 2008 at 10:20 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> To Robert's comment of:
>
> "it has now been clearly established that we need to move
> therepository. we're now just asking: where?"
>
> I question that. We voted at the last time, and it was very clear
> there was no
Guillaume Nodet wrote:
> Maven is just a tool to build something, it's not used to launch a
> process while downloading the binaries at the same time. At the
> end, people check what ends up in their distribution (be it a war
> or a tar.gz) and at this point, they know that there is an incubator
Why would someone care or even see them ? Are you regularly crawling
the maven repo for new artifacts ?
We don't have to be ashamed if a podling does not graduate, so I don't
think we have to try erasing the memory of this podling.
A non graduated podling could still be revived at a later time or
b
On Mon, Jun 2, 2008 at 12:17 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>>Part of the Incubation process is to ensure that there is sufficient
>>community to maintain the code after incubation.
>
>
>>It seems a bad idea to allow artefacts into the main repository where
>>they can become dependenci
>Part of the Incubation process is to ensure that there is sufficient
>community to maintain the code after incubation.
>It seems a bad idea to allow artefacts into the main repository where
>they can become dependencies unless there is some chance that they
>will be maintained.
This is an argum
On Mon, Jun 2, 2008 at 5:47 PM, sebb <[EMAIL PROTECTED]> wrote:
> On 02/06/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote:
>> That's just the thing though:
>>
>> At the end of the day, the vast majority of TLP end users could care less if
>> the TLP uses an incubator dependency or not, as long as
On 02/06/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> That's just the thing though:
>
> At the end of the day, the vast majority of TLP end users could care less if
> the TLP uses an incubator dependency or not, as long as it is Apache 2.0
> compatible and easily available (i.e. in the centr
I disagree, the problem is not when using a transitive dependencies.
Maven is just a tool to build something, it's not used to launch a
process while downloading the binaries at the same time. At the end,
people check what ends up in their distribution (be it a war or a
tar.gz) and at this point,
That's just the thing though:
At the end of the day, the vast majority of TLP end users could care less if
the TLP uses an incubator dependency or not, as long as it is Apache 2.0
compatible and easily available (i.e. in the central repo). They trust the
TLP to do their due diligence to ensure th
On Mon, Jun 2, 2008 at 10:52 AM, sebb <[EMAIL PROTECTED]> wrote:
> On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>> On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>> >
>>
>> > 1. Incubator releases go into Central
>>
>>
>> +1
>>
>> I think having the "in
On 02/06/2008, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> >
>
> > 1. Incubator releases go into Central
>
>
> +1
>
> I think having the "incubator" or "incubating" word in the version
> name brings sufficient aware
On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> 1. Incubator releases go into Central
+1
I think having the "incubator" or "incubating" word in the version
name brings sufficient awareness to the users.
While ServiceMix was in incubation, we had sometime a hard t
On Fri, May 30, 2008 at 2:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> 1. Incubator releases go into Central
>
> 2. Regular releases cannot use Incubator artifacts
>
>
>
> Since the whole point of the incubator releases is to get some people to
> use them and prove them out, I say
On May 30, 2008, at 11:38 PM, Matt Hogstrom wrote:
For the most part Geronimo is consumed as a whole and this hasn't
been an issue. For those modules that are re-used there hasn't been
any issues. You need to be aware of that. If they checkout and
build the project locally the artifacts
On May 30, 2008, at 9:59 PM, Matt Hogstrom wrote:
On May 30, 2008, at 8:53 AM, Brian E. Fox wrote:
IMO, things going into the central repository must have their entire
transitive hull available in the central repository. Therefore, we
must
draw one of two conclusions:
1. Incubat
Of course we could do that, and we may have to in order to appease our
community. But we'd prefer not to for simplicity's sake.
On Mon, Jun 2, 2008 at 4:25 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> 2008/5/30 Jeremy Haile <[EMAIL PROTECTED]>:
> > Currently JSecurity has a community, is publ
On 02/06/2008, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > Henri Yandell wrote:
> >
> >> Noel J. Bergman wrote:
> >> > I really do not know why we have to revisit this same topic year after
> > year
> >> > after yea
2008/5/30 Jeremy Haile <[EMAIL PROTECTED]>:
> Currently JSecurity has a community, is published to Maven, and does regular
> releases. If joining the incubator meant that we were no longer approved to
> do releases to our community, that seems like a hindrance to adoption. If
> people can no long
On Sun, Jun 1, 2008 at 8:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
>
>> Noel J. Bergman wrote:
>> > I really do not know why we have to revisit this same topic year after
> year
>> > after year. We do not want people to be using any Incubator artifact
>> > without ex
Bernd Fondermann wrote:
> > "While incubation status is not necessarily a reflection of the
> > completeness or stability of the code, it does indicate that
> > the project has yet to be fully endorsed by the ASF."
> Let's say, the Incubator publishes a release 'foo-incubating-0.9-src.zip'
o
James Carman wrote:
> Noel J. Bergman wrote:
> > FWIW, I agree with James that we would use signing to be more
fine-grained,
> > but didn't want to go into that degree of detail in the earlier
discussion.
> I apologize for being so verbose. This is probably not the correct
> forum to discuss thos
On Sat, May 31, 2008 at 3:59 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote:
>
>> > "Every incubator release is also an Apache release"
>> > http://incubator.apache.org/guides/releasemanagement.html#rules
>
>> +1
>> every incubator release is an official apache release
On Sun, Jun 1, 2008 at 11:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> FWIW, I agree with James that we would use signing to be more fine-grained,
> but didn't want to go into that degree of detail in the earlier discussion.
>
I apologize for being so verbose. This is probably not the cor
Henri Yandell wrote:
> Noel J. Bergman wrote:
> > I really do not know why we have to revisit this same topic year after
year
> > after year. We do not want people to be using any Incubator artifact
> > without explicit knowledge and action, so we do not want them polluting
the
> > standard repos
On Sat, May 31, 2008 at 6:59 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin wrote:
>
>> > "Every incubator release is also an Apache release"
>> > http://incubator.apache.org/guides/releasemanagement.html#rules
>
>> +1
>> every incubator release is an official apache release
On Thu, May 29, 2008 at 4:53 PM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Jukka Zitting wrote:
>> Craig L Russell wrote:
>> > 1. The incubating repository is not mirrored to the world, so incubating
>> > artifacts don't pollute the maven-o-sphere.
>
>> What's so bad about incubating artifacts t
Robert Burrell Donkin wrote:
> > "Every incubator release is also an Apache release"
> > http://incubator.apache.org/guides/releasemanagement.html#rules
> +1
> every incubator release is an official apache release
While technically accurate, the way you are both using the term conveys a
false me
On Sat, May 31, 2008 at 7:34 AM, Janne Jalkanen
<[EMAIL PROTECTED]> wrote:
>> The package names have to change when a podling comes into the
>> incubator (to the org.apache namespace). So, the "blow" has to happen
>> anyway. I'm not suggesting we enforce this for existing podlings
>> necessarily,
The package names have to change when a podling comes into the
incubator (to the org.apache namespace). So, the "blow" has to happen
anyway. I'm not suggesting we enforce this for existing podlings
necessarily, but future ones should probably do it. Once the podling
graduates, the plugins would
On Sat, May 31, 2008 at 4:41 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> 2008/5/31 Brett Porter <[EMAIL PROTECTED]>:
>> 2008/5/31 Noel J. Bergman <[EMAIL PROTECTED]>:
I'm more than happy to throw an enforcer rule into the next Maven
release that warns users if they are:
- using the
On Sat, May 31, 2008 at 3:30 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Brett Porter wrote:
>
>> Noel J. Bergman:
>> > I really don't care what cuts across the grain of Maven. I do care
> about
>> > the established principle that people must make a deliberate decision to
> use
>> > Incubator
On Fri, May 30, 2008 at 5:32 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 12:27 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
>> My proposed solution:
>>
>> 1. A podling could not issue a release until after IP issues have
>> been cleared by the IPMC.
>> 2. Once a podling'
On Sat, May 31, 2008 at 2:02 AM, Niall Pemberton
<[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 2:04 PM, sebb <[EMAIL PROTECTED]> wrote:
>> On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>> AIUI, formal ASF releases have some legal protection for the people
>> who make the release.
2008/5/31 Brett Porter <[EMAIL PROTECTED]>:
> 2008/5/31 Noel J. Bergman <[EMAIL PROTECTED]>:
>>> I'm more than happy to throw an enforcer rule into the next Maven
>>> release that warns users if they are:
>>> - using the incubator repository
>>> - using an artifact from org.apache.* with version *-
For the most part Geronimo is consumed as a whole and this hasn't been
an issue. For those modules that are re-used there hasn't been any
issues. You need to be aware of that. If they checkout and build the
project locally the artifacts copied into your local repo.
On May 30, 2008, at 10
2008/5/31 Noel J. Bergman <[EMAIL PROTECTED]>:
>> I'm more than happy to throw an enforcer rule into the next Maven
>> release that warns users if they are:
>> - using the incubator repository
>> - using an artifact from org.apache.* with version *-incubating.
>> and point them to a URL to learn
James Carman wrote:
> The bottom line is that incubator projects haven't (yet) gone through
> all the hoops necessary to become official ASF projects. So, if they
> are published to the main repository, that is in a way saying that the
> ASF endorses the software. Since it has not graduated from
Brett Porter wrote:
> Noel J. Bergman:
> > I really don't care what cuts across the grain of Maven. I do care
about
> > the established principle that people must make a deliberate decision to
use
> > Incubator artifacts. If Maven would finally support enforcing signing
of
> > artifacts, as they
>In this tree we placed the time dependent artifacts so someone that
>wanted to rebuild a release later on could by simply checking out the
>tag. When the build was done the repository project was built and the
>artifacts were then placed into the developers local repository. This
>allowed
2008/5/31 Noel J. Bergman <[EMAIL PROTECTED]>:
> Robert Burrell Donkin wrote:
>
>> it has now been clearly established that we need to move the
>> repository. we're now just asking: where?
>
> As I said, Brett Porter's proposal, made early on in the thread, seemed
> satisfactory.
That wasn't a pro
On May 30, 2008, at 8:53 AM, Brian E. Fox wrote:
IMO, things going into the central repository must have their entire
transitive hull available in the central repository. Therefore, we
must
draw one of two conclusions:
1. Incubator releases go into Central
2. Regular releases
On Fri, May 30, 2008 at 2:04 PM, sebb <[EMAIL PROTECTED]> wrote:
> On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>> I personally think we have conflicting rules in the way we handle
>> incubator releases.
>>
>>
>>
>> On the one hand, we require incubator releases to be in a separate
>>
he only other alternative is back to the original idea of denoting
incubator in the version, but this could be troublesome as well.
-Original Message-
From: Julius Davies [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2008 5:43 PM
To: general@incubator.apache.org
Subject: Re: maven repo
A general package renaming is going to be the least of your worries if
you're depending on lots of young immature jar files (and
automatically downloading newer versions)! Many popular jars have
broken binary reverse-compatibility at some point (httpclient,
jfreechart, junit to name three).
To re
On May 30, 2008, at 2:23 PM, James Carman wrote:
On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
<[EMAIL PROTECTED]> wrote:
As an end user, I would _hate_ to have to change all of my code to
reference a totally new package structure after the podling
graduates.
That's a major pain...
With
On May 30, 2008, at 2:09 PM, Janne Jalkanen wrote:
This seems logical provided the java package names also contain the
incubator keyword to avoid classpath conflicts if the jar gets
included twice.
Which would, obviously, kill backwards compatibility for third party
extensions when movin
On Fri, May 30, 2008 at 5:17 PM, Janne Jalkanen
<[EMAIL PROTECTED]> wrote:
>> As an end user, I would _hate_ to have to change all of my code to
>> reference a totally new package structure after the podling graduates.
>> That's a major pain...
>
> With JSPWiki we have plenty of plugins and other
As an end user, I would _hate_ to have to change all of my code to
reference a totally new package structure after the podling graduates.
That's a major pain...
With JSPWiki we have plenty of plugins and other extensions donated
by people over the years. Every binary break means that we obso
This seems logical provided the java package names also contain the
incubator keyword to avoid classpath conflicts if the jar gets
included twice.
Which would, obviously, kill backwards compatibility for third party
extensions when moving out of incubation.
Is not nice if you've built you
Why is this necessary?
As an end user, I would _hate_ to have to change all of my code to
reference a totally new package structure after the podling graduates.
That's a major pain...
On Fri, May 30, 2008 at 4:49 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
>>My proposed solution:
>
>>1. A pod
>My proposed solution:
>1. A podling could not issue a release until after IP issues have
>been cleared by the IPMC.
>2. Once a podling's release has been approved (which includes IP
>approval), they would release to the central maven repository under
>the group id org.apache.incubator.podlingn
On Fri, May 30, 2008 at 5:53 AM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:
> I personally think we have conflicting rules in the way we handle
> incubator releases.
>
>
>
> On the one hand, we require incubator releases to be in a separate
> repository... for whatever reason (they aren't part of Apa
I think that that the term "Incubator" is well understood. Almost
everyone in the software world understands that term. For the very
few that might not, a quick dictionary or google search, or a visit to
incubator.apache.org would make that very clear. That's good enough.
Unless there is an abso
On Fri, May 30, 2008 at 12:27 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> My proposed solution:
>
> 1. A podling could not issue a release until after IP issues have
> been cleared by the IPMC.
> 2. Once a podling's release has been approved (which includes IP
> approval), they would release t
On 30/05/2008, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> My proposed solution:
>
> 1. A podling could not issue a release until after IP issues have
> been cleared by the IPMC.
> 2. Once a podling's release has been approved (which includes IP
> approval), they would release to the central m
My proposed solution:
1. A podling could not issue a release until after IP issues have
been cleared by the IPMC.
2. Once a podling's release has been approved (which includes IP
approval), they would release to the central maven repository under
the group id org.apache.incubator.podlingname, en
So, let's define the goals here:
1. The ASF would like folks who want to use incubating projects to do
so knowingly somehow. This is somewhat of a CYA tactic so that people
are acknowledging "yes, I understand this is not an 'official' ASF
project, but I'd like to use it anyway."
2. Incubating
Yeah - coming from the point of view of a project working on entering
the incubator, I'd rather have tough IP restrictions on entering the
incubator, but once I'm in the incubator have an environment that most
effectively promotes growth and adoption of the project. Rather than
feeling lik
Hrm - I thought you had to have IP clearance before you even were
accepted as a podling. Or maybe its just that Alan is such a great
Champion for us, that he helped us along that path before we even
submitted our proposal ;)
Under this assumption (that IP clearance exists already), it makes
much
On Fri, May 30, 2008 at 11:23 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote:
> So it seems that a valid question is whether or not publishing to one
> repository or another indicates an endorsement.
Yes, that's certainly a valid question. Again, that's just my
personal point of view.
The biggest pr
That's the way I feel as well.
The maven repo exists to make lives easier for people - its an easy
way to pick up dependencies if you need them - nothing more. It is
primarily organized by domain names, so, if you have an
org.apache.incubator.podlingname group id, you're just following
convention
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Les,
please remember, not all incubator projects make it! i've personally been a
mentor on a few projects that were shutdown
for various reasons.
- -- dims
James Carman wrote:
| The bottom line is that incubator projects haven't (yet) gone through
So it seems that a valid question is whether or not publishing to one
repository or another indicates an endorsement. I don't personally
see it that way. Just because ASF makes a release available via a
maven repository isn't the same thing as endorsement to me, just as
the fact that the
The bottom line is that incubator projects haven't (yet) gone through
all the hoops necessary to become official ASF projects. So, if they
are published to the main repository, that is in a way saying that the
ASF endorses the software. Since it has not graduated from the
incubator, the ASF doesn
Noel,
Could you please help me understand the fundamental reasons why this
is important to the IPMC?
I mean, I as an end-user could care less about if the dependency
artifact is in incubation or not - as long as it solves the problems
in the way the development team deems necessary, all I want to
On May 30, 2008, at 9:24 AM, sebb wrote:
On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
we've been arguing for years about ease of use verses informed
choice
for users of incubator artifacts. not sure that any consensus has
been
reached. the current policy just introduces frictio
On Fri, May 30, 2008 at 10:54 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> End users don't read the POM. They just use it. So that is no solution at
> all. The signing approach would be, IMO, a reasonable solution. It would
> solve Les' issue -- users would simply have to agree to install
Robert Burrell Donkin wrote:
> it has now been clearly established that we need to move the
> repository. we're now just asking: where?
As I said, Brett Porter's proposal, made early on in the thread, seemed
satisfactory.
> asking podlings to publish through a secondary repository is both
> anno
On Fri, May 30, 2008 at 10:51 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> You would still end up with duplicate jars being drawn in. Maven
> fingerprints an artifact with groupId:artifactid:classifier:type to see
> if there are conflicts.
Of course, but you can make sure folks aren't using the p
Jukka Zitting wrote:
> Noel J. Bergman wrote:
> > I really do not know why we have to revisit this same topic year after
year
> > after year.
> Because it's an arbitrary restriction that IMHO hasn't been properly
justified.
So in other words, we'll revisit this again everytime someone (relativel
AM
To: general@incubator.apache.org
Subject: Re: maven repository
Well, to avoid collisions like that you could change the package name:
org.apache.incubating.podlingname
Once it graduates, you get:
org.apache.podlingname
That would be my preference - it feels cleaner and still allows the
release to be in the central repository (which is my main concern -
our end-users would be quite upset if they couldn't get our releases
from the main repo anymore). I prefer not to have 'incubating'
attached to the version.
Alth
Well, to avoid collisions like that you could change the package name:
org.apache.incubating.podlingname
Once it graduates, you get:
org.apache.podlingname
On Fri, May 30, 2008 at 10:28 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>>The problem with that is when the project graduates and they
>The problem with that is when the project graduates and they remove
>incubator from the groupId, there is a good potential to have two
>versions of the same packages being pulled in
You're right, I overlooked that... so I guess the qualifier attached to
the version is probably the best bet.
On May 30, 2008, at 9:55 AM, Brian E. Fox wrote:
Wouldn't having "incubating" in the version achieve the same thing
here?
Not necessarily for users specifying ranges. Further, having the group
be common for all incubating releases would make it easier for
people to
block in their repo ma
>Wouldn't having "incubating" in the version achieve the same thing
here?
Not necessarily for users specifying ranges. Further, having the group
be common for all incubating releases would make it easier for people to
block in their repo manager (or with an enforcer rule).
--
On Fri, May 30, 2008 at 9:22 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
>>Maven artifacts can also specify a "classifier." Perhaps the
>>"incubating" part could be a classifier?
>
> Only attached artifacts can have a classifier, not the main one, so
> unfortunately this won't work. I think havi
On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> >we've been arguing for years about ease of use verses informed choice
> >for users of incubator artifacts. not sure that any consensus has been
> >reached. the current policy just introduces friction (until someone
> >uploads the artif
>Maven artifacts can also specify a "classifier." Perhaps the
>"incubating" part could be a classifier?
Only attached artifacts can have a classifier, not the main one, so
unfortunately this won't work. I think having a different groupId is the
most logical choice... something like org.apache.in
>we've been arguing for years about ease of use verses informed choice
>for users of incubator artifacts. not sure that any consensus has been
>reached. the current policy just introduces friction (until someone
>uploads the artifact to the central repository).
So are we considering informed choi
On Fri, May 30, 2008 at 8:56 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> in terms of communication, the pom is the place to focus. AIUI maven
> users choose to use a library by adding a dependency with artifact and
> group IDs. an easy and effective way to ensure that users know that
>
On 30/05/2008, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I personally think we have conflicting rules in the way we handle
> incubator releases.
>
>
>
> On the one hand, we require incubator releases to be in a separate
> repository... for whatever reason (they aren't part of Apache, they
> are
On Fri, May 30, 2008 at 1:53 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I personally think we have conflicting rules in the way we handle
> incubator releases.
>
>
>
> On the one hand, we require incubator releases to be in a separate
> repository... for whatever reason (they aren't part of Apac
On Fri, May 30, 2008 at 12:33 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Fri, May 30, 2008 at 2:53 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> I really do not know why we have to revisit this same topic year after year
>> after year.
it has now been clearly established that we
Hi,
On Fri, May 30, 2008 at 2:53 AM, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> I really do not know why we have to revisit this same topic year after year
> after year.
Because it's an arbitrary restriction that IMHO hasn't been properly justified.
> We do not want people to be using any Incu
Thilo Goetz wrote:
> One might argue that incubator releases go through a very
> thorough release screening process
So what? The issue isn't code quality. Incubator projects are not part of
the ASF, yet. It is due to arguments like yours that some people have
proposed removing the Incubator fr
Jukka Zitting wrote:
> Craig L Russell wrote:
> > 1. The incubating repository is not mirrored to the world, so incubating
> > artifacts don't pollute the maven-o-sphere.
> What's so bad about incubating artifacts that would "pollute" things?
> We are perfectly happy distributing them on www.apach
In thinking of our project, JSecurity (which is currently being
proposed to become an Incubator project), I think its a bad idea to
limit incubator releases to a special repository.
We're a mature product and we're already publishing to the main repo -
very many of our end-users rely on this and e
Hi,
I'm inclined to call a vote on this matter as the discussion seems to
have died. Are there any related concerns or opinions that haven't yet
been voiced?
BR,
Jukka Zitting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For add
Craig L Russell wrote:
On May 15, 2008, at 4:34 AM, Robert Burrell Donkin wrote:
On Thu, May 15, 2008 at 8:04 AM, Brett Porter <[EMAIL PROTECTED]>
wrote:
2008/5/15 Robert Burrell Donkin <[EMAIL PROTECTED]>:
It would be possible to create an incubator only repository in a
subdirectory www.a
Hi,
On Thu, May 15, 2008 at 7:01 PM, Craig L Russell <[EMAIL PROTECTED]> wrote:
> 1. The incubating repository is not mirrored to the world, so incubating
> artifacts don't pollute the maven-o-sphere.
What's so bad about incubating artifacts that would "pollute" things?
We are perfectly happy dis
On May 15, 2008, at 4:34 AM, Robert Burrell Donkin wrote:
On Thu, May 15, 2008 at 8:04 AM, Brett Porter
<[EMAIL PROTECTED]> wrote:
2008/5/15 Robert Burrell Donkin <[EMAIL PROTECTED]>:
It would be possible to create an incubator only repository in a
subdirectory www.apache.org/dist/incubator/
On Thu, May 15, 2008 at 9:15 AM, Bertrand Delacretaz
<[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 10:01 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
>> On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
>> <[EMAIL PROTECTED]> wrote:
>>> It would be possible to create an incubator only
On Thu, May 15, 2008 at 8:04 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> 2008/5/15 Robert Burrell Donkin <[EMAIL PROTECTED]>:
>> It would be possible to create an incubator only repository in a
>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
>> just simplify everything by al
On Thu, May 15, 2008 at 10:01 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
>> It would be possible to create an incubator only repository in a
>> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
Hi,
On Thu, May 15, 2008 at 10:02 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> It would be possible to create an incubator only repository in a
> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
> just simplify everything by allowing incubator projects to use the
> stan
2008/5/15 Robert Burrell Donkin <[EMAIL PROTECTED]>:
> It would be possible to create an incubator only repository in a
> subdirectory www.apache.org/dist/incubator/maven, say. Or we could
> just simplify everything by allowing incubator projects to use the
> standard repository.Opinions?
http://p
On 2/2/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> robert burrell donkin wrote:
> > Noel J. Bergman wrote:
>
> > > allow automated downloads by Maven? I have an issue with that,
> > > since it could allow people to use the code without knowing
> > > that it is in the Incubator, but more to th
On Feb 2, 2006, at 7:59 AM, Noel J. Bergman wrote:
What I SEEM to recall is that we agree that people were not to
publish into
one of the public Maven repositories, and that was to be a separate
repository for use with the Incubator, so that users would be
required to
knowingly configure th
100 matches
Mail list logo
