You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Matthias Wessendorf <ma...@apache.org> on 2008/01/23 20:39:08 UTC

package names (was Re: PLEASE READ: package names, trademarks and legal advice)

sorry for hijacking the thread.

On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
> > > Legally, all we can do is ask them to change the package names and if
> they
> > > don't, there's nothing we can do

so, does this mean:
-during incubation the packages should be renamed to org.apache.* but
not on the start?
-is org.apache.* an exit criteria ? I think yes

-M


-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

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


Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Yoav Shapira <yo...@apache.org>.
On Jan 23, 2008 2:39 PM, Matthias Wessendorf <ma...@apache.org> wrote:
> -during incubation the packages should be renamed to org.apache.* but
> not on the start?

My 2 cents: it's OK to do the rename any time before graduation.

> -is org.apache.* an exit criteria ? I think yes

I agree.

Yoav

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


Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> However, if the release-JSPWiki2.8-from-Apache approach does not  
> fly, I would prefer to rename packages for 2.8. Although that would  
> mean we cause two breaks, it might also make migration to the new  
> APIs slightly easier -- because you'd separate the package import  
> migration step from the method-level changes for 3.0.

But since the API would really stay the same between 2.6 and 2.8,  
there would not be a "real" breakage.  Just an "artificial" one.  So  
I'm not sure how exactly that would help anyway.

The aim was pretty much to make 2.6 into 2.8 by making an Apachified- 
version out of it, since we can expect 3.0 to take a long time to  
finish.

> On the other hand -- it's equally possible that plugin and JSP  
> developers would bypass 2.8 regardless of the approach we take,  
> while they wait for the "real" 3.0 release.
>

Of course, all the old plugins (which we have plenty of) which have  
no maintenance will break, even if they might still be useful.

Also, this means that we need to support 2.6 for a long time, which  
is something I would rather not do, due to the fact that *that* code  
would still be LGPL and released from my own CVS...  It might even  
create the odd situation where an Apache incubation project would  
need to tell everyone to use the LGPL version.

/Janne

Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Andrew Jaquith <an...@mac.com>.
I like Simon's idea. The big thing *I* need, as someone who has lots  
of 3.0 Stripes-related checkins ready, is to get that SVN repository  
up and running. If doing that with the com.jspwiki package works for  
Apache, fine.

However, if the release-JSPWiki2.8-from-Apache approach does not fly,  
I would prefer to rename packages for 2.8. Although that would mean we  
cause two breaks, it might also make migration to the new APIs  
slightly easier -- because you'd separate the package import migration  
step from the method-level changes for 3.0.

On the other hand -- it's equally possible that plugin and JSP  
developers would bypass 2.8 regardless of the approach we take, while  
they wait for the "real" 3.0 release.

All of this is a long-winded way of saying, "I don't care," or 0 for  
short.

Andrew

On Jan 24, 2008, at 6:50, Simon Kitching <sk...@ops.co.at> wrote:

> Hi Janne et. al.,
>
> While it is not possible for code to be released from an incubator
> project, I see no reason why code cannot be developed in apache svn  
> but
> released by the jspwiki.org project.
>
> I would therefore suggest that:
> 1) the code be imported into apache svn
> 2) the licensing be changed, but NOT the packagenames
> 3) a 2.8.0 release be made from the jspwiki.org site, as a jspwiki.org
> release, using the code taken from the apache svn. This release will  
> be
> under the Apache license, but with the existing packagenames and  
> stating
> that it is a jspwiki.org product, not an ASF product (ie NOTICE etc
> refer to jspwiki.org or ecyrd).
> 4) then the packagenames can be changed in apache svn, NOTICE updated,
> promotion from incubator to full project can happen, and a 3.0 ASF
> release of the code can be made.
>
> With this approach:
> (a) work can be done in the asf repository, using asf procedures, asf
> mailing lists etc. This will provide evidence of the community  
> necessary
> for promotion from the incubator. The jspwiki.org cvs should be frozen
> at the time of import into apache svn, so there is only one "active"
> repository.
> (b) the move to ASF doesn't block release of a jspwiki 2.8.0 release.
> That release cannot be made under the ASF name, but that doesn't  
> matter.
>
> Even 2.8.1 etc. can be developed in the asf repo, as long as it is
> released by jspwiki.org not jspwiki.apache.org.
>
> The fact that the released code is not in the org.apache namespace
> doesn't matter, because it is not an ASF release.
>
> *Note that this is just my opinion*. The project mentor/incubator PMC
> are the ones who would have to ok this.
>
> Regards,
>
> Simon (skitching@apache.org; ASF member, but not incubator pmc)
>
> Janne Jalkanen schrieb:
>>
>> Folks,
>>
>> The opinion seems to be that for 2.8, we would need to rename all the
>> packages to org.apache.jspwiki.*.  This means that ALL existing
>> plugins and modules will break.  The problem is that we're going to
>> break the API again in 3.0 (that's why the "3"), when revamping the
>> backend.
>>
>> So, this means two source and binary breaks between two consecutive
>> major releases, invalidating all of the existing plugins.
>>
>> We have three options: change our release plans, bite the bullet and
>> accept the breaks, or alternatively, postpone graduation until we  
>> have
>> 3.0 (which may take a while).
>>
>> Opinions?  Other alternatives?
>>
>> /Janne
>>
>> Begin forwarded message:
>>
>>> From: "Noel J. Bergman" <no...@devtech.com>
>>> Date: 24 January 2008 07:23:49 GMT+02:00
>>> To: <ge...@incubator.apache.org>
>>> Subject: RE: package names (was Re: PLEASE READ: package names,
>>> trademarks and legal advice)
>>> Reply-To: general@incubator.apache.org
>>>
>>> Matthias Wessendorf wrote:
>>>
>>>> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>>>>>> Legally, all we can do is ask them to change the package names  
>>>>>>> and
>>> if
>>>>>>> they don't, there's nothing we can do
>>>
>>> Please note: I did not make the above statement.  You quoted me  
>>> quoting
>>> someone else.  Any legal advice would have to come from the ASF  
>>> Legal
>>> Committee in consultation with ASF legal counsel.  I don't know how
>>> to make
>>> this point any clearer.
>>>
>>>> so, does this mean:
>>>> - during incubation the packages should be renamed to  
>>>> org.apache.* but
>>>>  not on the start?
>>>> - is org.apache.* an exit criteria ? I think yes
>>>
>>> We've already been through this many times, with Roller, Wicket and
>>> others,
>>> so I'd go back and look to see how we handled it there --- and
>>> DOCUMENT IT.
>>> And, yes, I agree that switching to the o.a. package space is a
>>> graduation
>>> requirement at the very least.
>>>
>>>    --- Noel
>>>
>>>
>>>
>>> --- 
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>

Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Craig L Russell <Cr...@Sun.COM>.
I'll need to take a closer look at this thread before recommending  
anything. I'll probably have some questions.

By the way, the fact that this discussion is happening on the dev  
alias with plenty of community input is a very positive thing, so keep  
it up.

Thanks,

Craig

On Jan 24, 2008, at 5:18 AM, Janne Jalkanen wrote:

>> I would therefore suggest that:
>> 1) the code be imported into apache svn
>> 2) the licensing be changed, but NOT the packagenames
>> 3) a 2.8.0 release be made from the jspwiki.org site, as a  
>> jspwiki.org
>> release, using the code taken from the apache svn. This release  
>> will be
>> under the Apache license, but with the existing packagenames and  
>> stating
>> that it is a jspwiki.org product, not an ASF product (ie NOTICE etc
>> refer to jspwiki.org or ecyrd).
>> 4) then the packagenames can be changed in apache svn, NOTICE  
>> updated,
>> promotion from incubator to full project can happen, and a 3.0 ASF
>> release of the code can be made.
>
> This sounds like a good approach.  I like it :-)
>
>> (a) work can be done in the asf repository, using asf procedures, asf
>> mailing lists etc. This will provide evidence of the community  
>> necessary
>> for promotion from the incubator. The jspwiki.org cvs should be  
>> frozen
>> at the time of import into apache svn, so there is only one "active"
>> repository.
>
> Yes, I would very much like to freeze the jspwiki.org cvs and create  
> a separate 2.6 branch in the apache svn.
>
>> (b) the move to ASF doesn't block release of a jspwiki 2.8.0 release.
>> That release cannot be made under the ASF name, but that doesn't  
>> matter.
>
> Yes, because in every respect it would be just as good as an ASF  
> release, and it would still be covered by Apache license.
>
>> *Note that this is just my opinion*. The project mentor/incubator PMC
>> are the ones who would have to ok this.
>
> O Mentor, what is thy bidding?
>
> /Janne

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: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> I would therefore suggest that:
> 1) the code be imported into apache svn
> 2) the licensing be changed, but NOT the packagenames
> 3) a 2.8.0 release be made from the jspwiki.org site, as a jspwiki.org
> release, using the code taken from the apache svn. This release  
> will be
> under the Apache license, but with the existing packagenames and  
> stating
> that it is a jspwiki.org product, not an ASF product (ie NOTICE etc
> refer to jspwiki.org or ecyrd).
> 4) then the packagenames can be changed in apache svn, NOTICE updated,
> promotion from incubator to full project can happen, and a 3.0 ASF
> release of the code can be made.

This sounds like a good approach.  I like it :-)

> (a) work can be done in the asf repository, using asf procedures, asf
> mailing lists etc. This will provide evidence of the community  
> necessary
> for promotion from the incubator. The jspwiki.org cvs should be frozen
> at the time of import into apache svn, so there is only one "active"
> repository.

Yes, I would very much like to freeze the jspwiki.org cvs and create  
a separate 2.6 branch in the apache svn.

> (b) the move to ASF doesn't block release of a jspwiki 2.8.0 release.
> That release cannot be made under the ASF name, but that doesn't  
> matter.

Yes, because in every respect it would be just as good as an ASF  
release, and it would still be covered by Apache license.

> *Note that this is just my opinion*. The project mentor/incubator PMC
> are the ones who would have to ok this.

O Mentor, what is thy bidding?

/Janne

Re: Fwd: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Simon Kitching <sk...@ops.co.at>.
Hi Janne et. al.,

While it is not possible for code to be released from an incubator
project, I see no reason why code cannot be developed in apache svn but
released by the jspwiki.org project.

I would therefore suggest that:
1) the code be imported into apache svn
2) the licensing be changed, but NOT the packagenames
3) a 2.8.0 release be made from the jspwiki.org site, as a jspwiki.org
release, using the code taken from the apache svn. This release will be
under the Apache license, but with the existing packagenames and stating
that it is a jspwiki.org product, not an ASF product (ie NOTICE etc
refer to jspwiki.org or ecyrd).
4) then the packagenames can be changed in apache svn, NOTICE updated,
promotion from incubator to full project can happen, and a 3.0 ASF
release of the code can be made.

With this approach:
(a) work can be done in the asf repository, using asf procedures, asf
mailing lists etc. This will provide evidence of the community necessary
for promotion from the incubator. The jspwiki.org cvs should be frozen
at the time of import into apache svn, so there is only one "active"
repository.
(b) the move to ASF doesn't block release of a jspwiki 2.8.0 release.
That release cannot be made under the ASF name, but that doesn't matter.

Even 2.8.1 etc. can be developed in the asf repo, as long as it is
released by jspwiki.org not jspwiki.apache.org.

The fact that the released code is not in the org.apache namespace
doesn't matter, because it is not an ASF release.

*Note that this is just my opinion*. The project mentor/incubator PMC
are the ones who would have to ok this.

Regards,

Simon (skitching@apache.org; ASF member, but not incubator pmc)

Janne Jalkanen schrieb:
>
> Folks,
>
> The opinion seems to be that for 2.8, we would need to rename all the
> packages to org.apache.jspwiki.*.  This means that ALL existing
> plugins and modules will break.  The problem is that we're going to
> break the API again in 3.0 (that's why the "3"), when revamping the
> backend.
>
> So, this means two source and binary breaks between two consecutive
> major releases, invalidating all of the existing plugins.
>
> We have three options: change our release plans, bite the bullet and
> accept the breaks, or alternatively, postpone graduation until we have
> 3.0 (which may take a while).
>
> Opinions?  Other alternatives?
>
> /Janne
>
> Begin forwarded message:
>
>> From: "Noel J. Bergman" <no...@devtech.com>
>> Date: 24 January 2008 07:23:49 GMT+02:00
>> To: <ge...@incubator.apache.org>
>> Subject: RE: package names (was Re: PLEASE READ: package names,
>> trademarks and legal advice)
>> Reply-To: general@incubator.apache.org
>>
>> Matthias Wessendorf wrote:
>>
>>> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>>>>> Legally, all we can do is ask them to change the package names and
>> if
>>>>>> they don't, there's nothing we can do
>>
>> Please note: I did not make the above statement.  You quoted me quoting
>> someone else.  Any legal advice would have to come from the ASF Legal
>> Committee in consultation with ASF legal counsel.  I don't know how
>> to make
>> this point any clearer.
>>
>>> so, does this mean:
>>> - during incubation the packages should be renamed to org.apache.* but
>>>   not on the start?
>>> - is org.apache.* an exit criteria ? I think yes
>>
>> We've already been through this many times, with Roller, Wicket and
>> others,
>> so I'd go back and look to see how we handled it there --- and
>> DOCUMENT IT.
>> And, yes, I agree that switching to the o.a. package space is a
>> graduation
>> requirement at the very least.
>>
>>     --- Noel
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>


Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Olaf Kock <ok...@abstrakt.de>.
Janne Jalkanen schrieb:
>> Given that the plugin path has to be specified in jspwiki.properties,
>> *in theory* the existing plugins could still function if their earlier
>> (i.e., current) paths were added to the list. That's a reasonable interim
> 
> Nope, since even WikiContext would no longer be in com.ecyrd.jspwiki 
> -package, so the WikiPlugin.execute() signature would be incorrect.  So 
> it would be a total breakage.

Hi,

It's been a long time since I laid my hands on JSPWiki Code, so I don't 
know how viable this is. (Provided one really cares for compatibility of 
old plugins without much work on behalf of the plugin authors):

What about providing a "compatibility" layer, e.g. moving WikiContext to 
org.apache.*, together with all code and then provide an empty subclass 
that plugins can rely on. If not subclass, maybe some org.jspwiki.* 
classes that are solely delegating to org.apache.* classes could 
suffice? This would not provide 100% backwards compatibility but may 
ease transition (e.g. instantiating object instances could reveal some 
problems).

As Terry said, too much breakage would reveal some amount of 
frustration. Though I believe the frustration is among developers, not 
users, and developers should be able to handle this better than users - 
adapting to the ever changing world is part of my daily business at least.

Another thought would be a somehow aided migration path: Provide old 
(empty) API classes (in source code) that simply inherit from 
org.apache.* classes (as said above). These are copied into the 3rd 
party plugin dev environment. Then use your favorite IDE to replace 
usage of the org.jspwiki.* class with it's subclass and delete the 
org.jspwiki classes just added to the project. This would have to be 
done in the context (and dev environment) of all plugins that are 
upgrading to org.apache.* code.

Does this communicate the idea?

Of course all this would ease the work of 3rd party plugin developers at 
the cost of JSPWiki core developers. If only few (3rd party) authors 
care for this, I'd rather help them port their plugins one by one...

Please comment,
Cheers,
Olaf

Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> Given that the plugin path has to be specified in jspwiki.properties,
> *in theory* the existing plugins could still function if their earlier
> (i.e., current) paths were added to the list. That's a reasonable  
> interim

Nope, since even WikiContext would no longer be in com.ecyrd.jspwiki - 
package, so the WikiPlugin.execute() signature would be incorrect.   
So it would be a total breakage.

/Janne

Re: Fwd: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Murray Altheim <mu...@altheim.com>.
Janne Jalkanen wrote:
> 
> Folks,
> 
> The opinion seems to be that for 2.8, we would need to rename all the 
> packages to org.apache.jspwiki.*.  This means that ALL existing plugins 
> and modules will break.  The problem is that we're going to break the 
> API again in 3.0 (that's why the "3"), when revamping the backend.

Given that the plugin path has to be specified in jspwiki.properties,
*in theory* the existing plugins could still function if their earlier
(i.e., current) paths were added to the list. That's a reasonable interim
solution. But it's likely that this is a simplification, as there'll be
a bunch of incompatibilities in the mix. There's also all the interaction
with the JSPs and other parts of the code and installation that expects
the current paths.

> So, this means two source and binary breaks between two consecutive 
> major releases, invalidating all of the existing plugins.
> 
> We have three options: change our release plans, bite the bullet and 
> accept the breaks, or alternatively, postpone graduation until we have 
> 3.0 (which may take a while).

I'm ready to bite the bullet as necessary, but I'd *really* prefer to
do this just once.

> Opinions?  Other alternatives?

We probably should break the plugin discussion into the various areas
or characterizations in which plugins are distributed. We have core,
we have contributed, we have all manner of miscellaneous. And as you
probably know, I have a lot of plugins. A *lot*:

   http://www.altheim.com/ceryle/wiki/Wiki.jsp?page=CeryleWikiPluginCatalog

Now, paths wouldn't have to change for hardly any of these, but I think
there may be some I have responsibility for. But in any case I feel like
I'm pretty well-placed to make a mass change of package name for any that
I'm responsible for that you consider part of the distribution. As for
others, I dunno.

But this is likely to introduce a *ton* of bugs, and I don't think any
of us are so well-placed (time-wise) to tackle a bunch of plugin bugs.
I've got a major project going live, two new projects, a ton of documen-
tation to write (including a least one or two papers), all in the next
few months (and I'm also trying desperately but successfully to have a
life).

Murray

PS. I do have a shell script that does mass name transforms of all files
in a directory, which I use for updating year-of-copyright. Simple sh/sed
stuff but I can pass it along if you want if it might save you some time.
...........................................................................
Murray Altheim <murray07 at altheim.com>                           ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

       Boundless wind and moon - the eye within eyes,
       Inexhaustible heaven and earth - the light beyond light,
       The willow dark, the flower bright - ten thousand houses,
       Knock at any door - there's one who will respond.
                                       -- The Blue Cliff Record

Re: Fwd: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Terry Steichen <te...@net-frame.com>.
IMHO, postpone.  Too many such breaks = too much frustration for
existing users.

On Thu, 2008-01-24 at 12:24 +0200, Janne Jalkanen wrote:

> Folks,
> 
> The opinion seems to be that for 2.8, we would need to rename all the  
> packages to org.apache.jspwiki.*.  This means that ALL existing  
> plugins and modules will break.  The problem is that we're going to  
> break the API again in 3.0 (that's why the "3"), when revamping the  
> backend.
> 
> So, this means two source and binary breaks between two consecutive  
> major releases, invalidating all of the existing plugins.
> 
> We have three options: change our release plans, bite the bullet and  
> accept the breaks, or alternatively, postpone graduation until we  
> have 3.0 (which may take a while).
> 
> Opinions?  Other alternatives?
> 
> /Janne
> 
> Begin forwarded message:
> 
> > From: "Noel J. Bergman" <no...@devtech.com>
> > Date: 24 January 2008 07:23:49 GMT+02:00
> > To: <ge...@incubator.apache.org>
> > Subject: RE: package names (was Re: PLEASE READ: package names,  
> > trademarks and legal advice)
> > Reply-To: general@incubator.apache.org
> >
> > Matthias Wessendorf wrote:
> >
> >> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
> >>>>> Legally, all we can do is ask them to change the package names and
> > if
> >>>>> they don't, there's nothing we can do
> >
> > Please note: I did not make the above statement.  You quoted me  
> > quoting
> > someone else.  Any legal advice would have to come from the ASF Legal
> > Committee in consultation with ASF legal counsel.  I don't know how  
> > to make
> > this point any clearer.
> >
> >> so, does this mean:
> >> - during incubation the packages should be renamed to org.apache.*  
> >> but
> >>   not on the start?
> >> - is org.apache.* an exit criteria ? I think yes
> >
> > We've already been through this many times, with Roller, Wicket and  
> > others,
> > so I'd go back and look to see how we handled it there --- and  
> > DOCUMENT IT.
> > And, yes, I agree that switching to the o.a. package space is a  
> > graduation
> > requirement at the very least.
> >
> > 	--- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org

Re: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Harry Metske <ha...@gmail.com>.
just my humble opinion,

assuming that "may take a while" could be somewhere between months and
years, I would opt for a 2 step changeplan.
First change the package names with 2.8, and do the 3.0 upgrade separately
afterwards.

My feeling is that combining them together would make debugging more
difficult, and take us even more time.


regards,
Harry

2008/1/24, Janne Jalkanen <Ja...@ecyrd.com>:
>
>
> Folks,
>
> The opinion seems to be that for 2.8, we would need to rename all the
> packages to org.apache.jspwiki.*.  This means that ALL existing
> plugins and modules will break.  The problem is that we're going to
> break the API again in 3.0 (that's why the "3"), when revamping the
> backend.
>
> So, this means two source and binary breaks between two consecutive
> major releases, invalidating all of the existing plugins.
>
> We have three options: change our release plans, bite the bullet and
> accept the breaks, or alternatively, postpone graduation until we
> have 3.0 (which may take a while).
>
> Opinions?  Other alternatives?
>
> /Janne
>
> Begin forwarded message:
>
> > From: "Noel J. Bergman" <no...@devtech.com>
> > Date: 24 January 2008 07:23:49 GMT+02:00
> > To: <ge...@incubator.apache.org>
> > Subject: RE: package names (was Re: PLEASE READ: package names,
> > trademarks and legal advice)
> > Reply-To: general@incubator.apache.org
> >
> > Matthias Wessendorf wrote:
> >
> >> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
> >>>>> Legally, all we can do is ask them to change the package names and
> > if
> >>>>> they don't, there's nothing we can do
> >
> > Please note: I did not make the above statement.  You quoted me
> > quoting
> > someone else.  Any legal advice would have to come from the ASF Legal
> > Committee in consultation with ASF legal counsel.  I don't know how
> > to make
> > this point any clearer.
> >
> >> so, does this mean:
> >> - during incubation the packages should be renamed to org.apache.*
> >> but
> >>   not on the start?
> >> - is org.apache.* an exit criteria ? I think yes
> >
> > We've already been through this many times, with Roller, Wicket and
> > others,
> > so I'd go back and look to see how we handled it there --- and
> > DOCUMENT IT.
> > And, yes, I agree that switching to the o.a. package space is a
> > graduation
> > requirement at the very least.
> >
> >       --- Noel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081

Fwd: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by Janne Jalkanen <Ja...@ecyrd.com>.
Folks,

The opinion seems to be that for 2.8, we would need to rename all the  
packages to org.apache.jspwiki.*.  This means that ALL existing  
plugins and modules will break.  The problem is that we're going to  
break the API again in 3.0 (that's why the "3"), when revamping the  
backend.

So, this means two source and binary breaks between two consecutive  
major releases, invalidating all of the existing plugins.

We have three options: change our release plans, bite the bullet and  
accept the breaks, or alternatively, postpone graduation until we  
have 3.0 (which may take a while).

Opinions?  Other alternatives?

/Janne

Begin forwarded message:

> From: "Noel J. Bergman" <no...@devtech.com>
> Date: 24 January 2008 07:23:49 GMT+02:00
> To: <ge...@incubator.apache.org>
> Subject: RE: package names (was Re: PLEASE READ: package names,  
> trademarks and legal advice)
> Reply-To: general@incubator.apache.org
>
> Matthias Wessendorf wrote:
>
>> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
>>>>> Legally, all we can do is ask them to change the package names and
> if
>>>>> they don't, there's nothing we can do
>
> Please note: I did not make the above statement.  You quoted me  
> quoting
> someone else.  Any legal advice would have to come from the ASF Legal
> Committee in consultation with ASF legal counsel.  I don't know how  
> to make
> this point any clearer.
>
>> so, does this mean:
>> - during incubation the packages should be renamed to org.apache.*  
>> but
>>   not on the start?
>> - is org.apache.* an exit criteria ? I think yes
>
> We've already been through this many times, with Roller, Wicket and  
> others,
> so I'd go back and look to see how we handled it there --- and  
> DOCUMENT IT.
> And, yes, I agree that switching to the o.a. package space is a  
> graduation
> requirement at the very least.
>
> 	--- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


RE: package names (was Re: PLEASE READ: package names, trademarks and legal advice)

Posted by "Noel J. Bergman" <no...@devtech.com>.
Matthias Wessendorf wrote:

> On Jan 23, 2008 11:02 AM, Noel J. Bergman <no...@devtech.com> wrote:
> > > > Legally, all we can do is ask them to change the package names and
if
> > > > they don't, there's nothing we can do

Please note: I did not make the above statement.  You quoted me quoting
someone else.  Any legal advice would have to come from the ASF Legal
Committee in consultation with ASF legal counsel.  I don't know how to make
this point any clearer.

> so, does this mean:
> - during incubation the packages should be renamed to org.apache.* but
>   not on the start?
> - is org.apache.* an exit criteria ? I think yes

We've already been through this many times, with Roller, Wicket and others,
so I'd go back and look to see how we handled it there --- and DOCUMENT IT.
And, yes, I agree that switching to the o.a. package space is a graduation
requirement at the very least.

	--- Noel



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