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.
On Sat, May 31, 2008 at 3:42 AM, Brett Porter <[EMAIL PROTECTED]> 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.
>>
>> We do support signing of artifacts
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
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.
>
> We do support signing of artifacts and all the maven releases are
> signed. We obviously don't control all the oth
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
Brian E. Fox wrote:
> > 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
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
>>
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
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
>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
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
Ant+Ivy vs Maven =)
On May 30, 2008, at 12:06 PM, James Carman wrote:
On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
Maven vs Ant vs Buildr ?
Who uses Ant or Buildr? ;)
-
To unsubscribe, e-
On Fri, May 30, 2008 at 12:03 PM, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
> Maven vs Ant vs Buildr ?
Who uses Ant or Buildr? ;)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
James Carman wrote:
On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
There's no uniqueness requirement AFAIK. Any kind of project can be
proposed even if there already exist multiple implementations of a similar
technology here at the ASF and abroad.
Perhaps
Alan D. Cabrera wrote:
On May 30, 2008, at 5:27 AM, Alex Karasulu wrote:
On Fri, May 30, 2008 at 8:04 AM, James Carman
<[EMAIL PROTECTED]>
wrote:
Isn't there something that states that an incubating project needs to
be novel or provide something that's not already provided by another
librar
On Fri, May 30, 2008 at 11:47 AM, James Carman <[EMAIL PROTECTED]>
wrote
> On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <[EMAIL PROTECTED]>
> wrote:
>
> > There's no uniqueness requirement AFAIK. Any kind of project can be
> > proposed even if there already exist multiple implementations of a
>
On Fri, May 30, 2008 at 8:27 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> There's no uniqueness requirement AFAIK. Any kind of project can be
> proposed even if there already exist multiple implementations of a similar
> technology here at the ASF and abroad.
>
Perhaps the uniqueness/novel res
On May 29, 2008, at 11:32 PM, Bertrand Delacretaz wrote:
Hi,
On Wed, May 28, 2008 at 11:19 PM, Alan D. Cabrera <[EMAIL PROTECTED]
> wrote:
...http://wiki.apache.org/incubator/JSecurityProposal...
Looks good to me, IMHO this is ready for a vote.
Thanks. I'll let the weekend crowd peruse
On May 30, 2008, at 5:27 AM, Alex Karasulu wrote:
On Fri, May 30, 2008 at 8:04 AM, James Carman <[EMAIL PROTECTED]
>
wrote:
Isn't there something that states that an incubating project needs to
be novel or provide something that's not already provided by another
library (with an open-source
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
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
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
I like this idea! We have an application that has a Swing client and
we talk to the server via Spring remoting. This shared session idea
sounds intriguing. I might have to look into switching to JSecurity!
:)
If you're interested in the Swing-web session interaction check out
our Spring sam
If you're curious, the two classes end-users use the most are the
Subject (http://www.jsecurity.org/api/org/jsecurity/subject/Subject.html),
and the Session
(http://www.jsecurity.org/api/org/jsecurity/session/Session.html) -
acquired via subject.getSession();
Cheers,
Les
On Fri, May 30, 2008 at
>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).
--
The other thing about JSecurity's enterprise session support is that
it in many cases serves as a native basic Single Sign-On solution.
For example, the most common scenario that typically occurs is the
following (there are several current production environments that work
like this):
A session is
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 8:31 AM, Jeremy Haile <[EMAIL PROTECTED]> wrote:
> Another differentiator is that JSecurity provides a session framework
> that is not limited to being shared across just web-based applications.
> We have users that share sessions across multiple environments, such as
> Swi
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
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
The fact that JSecurity is container-agnostic is certainly a
differentiator. JSecurity aims to support security in any environment.
In fact, we have several users that are using JSecurity in non-web
environments, such as pure-service layers or even Swing applications.
JSecurity also aims to gr
On Fri, May 30, 2008 at 8:04 AM, James Carman <[EMAIL PROTECTED]>
wrote:
> Isn't there something that states that an incubating project needs to
> be novel or provide something that's not already provided by another
> library (with an open-source license)? I have looked at the JSecurity
> proposa
Isn't there something that states that an incubating project needs to
be novel or provide something that's not already provided by another
library (with an open-source license)? I have looked at the JSecurity
proposal only briefly, but it seems to me that most of what it aims to
provide is already
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
78 matches
Mail list logo
