Thanks Brett, I kept meaning to separate the maven project parts from
the common ones, and this is a good start.
--Brian (mobile)
On Nov 13, 2009, at 2:29 AM, Brett Porter wrote:
For unrelated reasons, I today split out the Apache-ness part of the
Maven release process (still syncing):
h
>We don't have to. We can simply mandate that every ASF project sign
their
>artifacts and charge the Maven PMC with enforcing it.
And are you going to lobby FireFox and Microsoft to enforce in their
browsers? Seriously why is this Maven's problem simply because it
downloads it when you can't enf
Conversely and more defendable, we could decide that anything with a
transitive dependency hull that is not completely contained by central
cannot be hosted in central. This is yet another approach to nuking the
issue. The unfortunate side-effect would be to exclude all apache (and
other) artifacts
>Maven is *too* transparent in what it does: it hides the disclaimer,
>preventing the POLICY of ensuring that users are explicitly aware of
and
>agree to use of Incubator artifacts.
Maven doesn't *hide* anything, it simply makes requests via http. You
can use your browser to pull stuff from Centr
gt;> wrote:
>>>
>>> 2008/5/31 Brian E. Fox <[EMAIL PROTECTED]>:
>>>>
>>>> Can you elaborate more on what you mean here? I've been on the
Maven PMC
>>>> for over a year now and this is the first I've heard of it.
>>>>
>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
>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
I tend agree that yes it will be annoying but certainly you can't claim
you weren't informed. With modern IDE's refactoring isn't a huge issue
in my opinion.
I could go either way, but if we say the group id changes, then we need
to try to prevent classpath conflicts as Maven will see the new
grou
>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 have been asked to do for years, we could use an
>I
>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
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.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Friday, May 30, 2008 10:31
>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.
>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).
--
>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
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
aren't stable enough, etc). On the other hand, we allow regular releases
16 matches
Mail list logo
