You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/04/05 22:14:51 UTC
Issues with chaperon
We were very picky with Ivelin and his move to factor out xmlform, but
I'm going to be as well with Chaperon.
There are few things that I don't like:
1) copyright is given to the ASF.
While I *do* appreciate the intention, the ASF's policy cannot allow
this (I'm going to be picky on those things, so be prepared in case you
host stuff with the ASF copyright which are not hosted on
ASF-infrastructure-driven hosts)
As a short term solution, I would suggest to change the copyright sign.
[the license is fine]
2) chaperon is impossible to add to gump because it imposes circular
dependencies.
this is a general indication of a bigger problem: chaperon *includes*
its own cocoon-dependent classes.
this is a big issue: as far as it's nice to see libraries that can be
used in other contexts factored out (xmlform, poi, chaperon, fop,
batik... we have tons of them), all the cocoon-related components (all
those importing org.apache.cocoon.* stuff, for example, should remain
inside the cocoon CVS, in this case, into the chaperon module.
Why?
well, if not, cocoon will depend on chaperon and chaperon will depend on
cocoon. And this breaks gump.
I'm *SICK* of updating the gump.xml descriptor for everytime the
chaperon library snapshot is updated and imported in CVS.
Sure, I could keep on nagging Stephen everytime he updates the jar, but
this is just an indication of a bigger problem: circular dependencies
are evil and show a sign of bad architecture or, in the best case, lack
of cooperation.
Comments?
--
Stefano.
Re: Issues with chaperon
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 7/4/03 22:48, "Steven Noels" <st...@outerthought.org> wrote:
> On 7/04/2003 14:16 Stefano Mazzocchi wrote:
>
>> Note that the same holds true for the wiki pages for two reasons:
>>
>> 1) they are hosted in a machine which is not under direct control of the
>> ASF infrastructure team
>>
>> 2) they are not contained in the apache.org contained URI resolution space.
>
> Until the Wiki is moved to nagoya, I've changed the copyright footer to
> "Copyright © 2002-2003 The Cocoon Project. All rights reserved."
>
> After it is moved, we can then change it back to "© The ASF".
>
> OK?
Yes and no... Yes because at least legally we're not involving the
foundation itself, but no because the "Cocoon" project is still an Apache
name, and as said in our license you need to get permission to use the name.
I'd be a happier camper if the PMC members passed a resolution mentioning
the fact that Steven Noels (individual) is allowed to use the "Cocoon
Project" name to host the Apache Cocoon Wiki system until a more permanent
location within the ASF infrastructure is found and the Wiki is moved.
Sorry to be another legally-binding friggin' pain-in-the-ass, but as an ASF
member, it's one of the unfortunate things you gotta watch out for. I know
we're all friends and nothing ever is going to happen, and I thank your
effort for doing all you're doing on your hardware, Steven, but legally, at
the end, even the Foundation is a corporation and has lawyers and stuff :-(
Pier
Re: Issues with chaperon
Posted by Steven Noels <st...@outerthought.org>.
On 7/04/2003 14:16 Stefano Mazzocchi wrote:
> Note that the same holds true for the wiki pages for two reasons:
>
> 1) they are hosted in a machine which is not under direct control of the
> ASF infrastructure team
>
> 2) they are not contained in the apache.org contained URI resolution space.
Until the Wiki is moved to nagoya, I've changed the copyright footer to
"Copyright © 2002-2003 The Cocoon Project. All rights reserved."
After it is moved, we can then change it back to "© The ASF".
OK?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Issues with chaperon
Posted by Steven Noels <st...@outerthought.org>.
On 7/04/2003 14:16 Stefano Mazzocchi wrote:
> Note that the same holds true for the wiki pages for two reasons:
>
> 1) they are hosted in a machine which is not under direct control of the
> ASF infrastructure team
>
> 2) they are not contained in the apache.org contained URI resolution space.
>
> This will be the last thing I, as PMC chair, don't feel totally
> confortable with from a legal point of view.
>
> Note that I'm perfectly aware that nothing of this is done to do harm to
> cocoon nor to abuse its name or the foundation's, so everything will be
> just fine, we just have to deal with the small details and this is a
> boring, even if necessary, job.
>
> Please, bear with me and have patience: I'm doing this so that our legal
> umbrella doesn't leak thru.
Can you please expand on the link between 'being under direct control of
the ASF infrastructure team' or 'being embedded in the ASF URI space'
and the legality of the copyright footer on the Wiki pages?
This has been discussed before, and the (c) footer was an explicit
decision on cocoon-docs IIRC, also
http://wiki.cocoondev.org/Wiki.jsp?page=License has been linked from the
main page to this effect.
Summarizing the decision at that time: material _could_ be transfered
from the Wiki to the project, so please don't post on the Wiki if you
haven't read the contributors guidelines.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Issues with chaperon
Posted by Stephan Michels <st...@apache.org>.
On Mon, 7 Apr 2003, Stefano Mazzocchi wrote:
> on 4/7/03 12:36 PM Stephan Michels wrote:
>
> > On Sat, 5 Apr 2003, Stefano Mazzocchi wrote:
> >
> >
> >>We were very picky with Ivelin and his move to factor out xmlform, but
> >>I'm going to be as well with Chaperon.
> >>
> >>There are few things that I don't like:
> >>
> >>1) copyright is given to the ASF.
> >>
> >>While I *do* appreciate the intention, the ASF's policy cannot allow
> >>this (I'm going to be picky on those things, so be prepared in case you
> >>host stuff with the ASF copyright which are not hosted on
> >>ASF-infrastructure-driven hosts)
> >>
> >>As a short term solution, I would suggest to change the copyright sign.
> >>[the license is fine]
> >
> >
> > Can you please give me a pointer, I'm a bit lost?
>
> Oh, sorry, http://chaperon.sf.net right at the bottom.
>
> Copyright © 2002 The Apache Software Foundation.. All rights reserved.
>
> The ASF has no whatsoever rights on the chaperon web pages, so you are
> stating a lie.
>
> Please, bear with me and have patience: I'm doing this so that our legal
> umbrella doesn't leak thru.
>
> > Do you mean in LICENSE.chaperon ?
>
> No,no, nothign in code or licenses, but on the web. But from your reply
> it seems that you just overlooked it so I think it's just a matter of
> updating your skin.
Yes, I just have forget to change the skinconf.xml :-/ I think I have
fixed it.
> > It's not a bad architecture, it's a evolution stage. The components
> > were originally developed within the Chaperon project, and were moved
> > to Cocoon.
> >
> > And yes, I will removed the cocoon dependency of the Chaperon lib.
>
> Very cool. This is nice to hear. Please keep me informed as you complete
> the transition, becuase as soon as chaperon is free of cocoon
> dependencies, I want to add it to gump so that we can have gump help us
> watch over our contracts.
I must add a infrastructure to allow testcases for block compoments. I
have the blocks-build.xsl already changed on my hd, but I must first
see that everything runs fine. So this will take some time.
Thanks for your time, Stephan.
Re: Issues with chaperon
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/7/03 12:36 PM Stephan Michels wrote:
> On Sat, 5 Apr 2003, Stefano Mazzocchi wrote:
>
>
>>We were very picky with Ivelin and his move to factor out xmlform, but
>>I'm going to be as well with Chaperon.
>>
>>There are few things that I don't like:
>>
>>1) copyright is given to the ASF.
>>
>>While I *do* appreciate the intention, the ASF's policy cannot allow
>>this (I'm going to be picky on those things, so be prepared in case you
>>host stuff with the ASF copyright which are not hosted on
>>ASF-infrastructure-driven hosts)
>>
>>As a short term solution, I would suggest to change the copyright sign.
>>[the license is fine]
>
>
> Can you please give me a pointer, I'm a bit lost?
Oh, sorry, http://chaperon.sf.net right at the bottom.
Copyright © 2002 The Apache Software Foundation.. All rights reserved.
The ASF has no whatsoever rights on the chaperon web pages, so you are
stating a lie.
Note that the same holds true for the wiki pages for two reasons:
1) they are hosted in a machine which is not under direct control of the
ASF infrastructure team
2) they are not contained in the apache.org contained URI resolution space.
This will be the last thing I, as PMC chair, don't feel totally
confortable with from a legal point of view.
Note that I'm perfectly aware that nothing of this is done to do harm to
cocoon nor to abuse its name or the foundation's, so everything will be
just fine, we just have to deal with the small details and this is a
boring, even if necessary, job.
Please, bear with me and have patience: I'm doing this so that our legal
umbrella doesn't leak thru.
> Do you mean in LICENSE.chaperon ?
No,no, nothign in code or licenses, but on the web. But from your reply
it seems that you just overlooked it so I think it's just a matter of
updating your skin.
> It's not a bad architecture, it's a evolution stage. The components
> were originally developed within the Chaperon project, and were moved
> to Cocoon.
>
> And yes, I will removed the cocoon dependency of the Chaperon lib.
Very cool. This is nice to hear. Please keep me informed as you complete
the transition, becuase as soon as chaperon is free of cocoon
dependencies, I want to add it to gump so that we can have gump help us
watch over our contracts.
--
Stefano.
Re: Issues with chaperon
Posted by Stephan Michels <st...@apache.org>.
On Sat, 5 Apr 2003, Stefano Mazzocchi wrote:
> We were very picky with Ivelin and his move to factor out xmlform, but
> I'm going to be as well with Chaperon.
>
> There are few things that I don't like:
>
> 1) copyright is given to the ASF.
>
> While I *do* appreciate the intention, the ASF's policy cannot allow
> this (I'm going to be picky on those things, so be prepared in case you
> host stuff with the ASF copyright which are not hosted on
> ASF-infrastructure-driven hosts)
>
> As a short term solution, I would suggest to change the copyright sign.
> [the license is fine]
Can you please give me a pointer, I'm a bit lost? Do you mean in
LICENSE.chaperon ?
> 2) chaperon is impossible to add to gump because it imposes circular
> dependencies.
>
> this is a general indication of a bigger problem: chaperon *includes*
> its own cocoon-dependent classes.
>
> this is a big issue: as far as it's nice to see libraries that can be
> used in other contexts factored out (xmlform, poi, chaperon, fop,
> batik... we have tons of them), all the cocoon-related components (all
> those importing org.apache.cocoon.* stuff, for example, should remain
> inside the cocoon CVS, in this case, into the chaperon module.
>
> Why?
>
> well, if not, cocoon will depend on chaperon and chaperon will depend on
> cocoon. And this breaks gump.
>
> I'm *SICK* of updating the gump.xml descriptor for everytime the
> chaperon library snapshot is updated and imported in CVS.
>
> Sure, I could keep on nagging Stephen everytime he updates the jar, but
> this is just an indication of a bigger problem: circular dependencies
> are evil and show a sign of bad architecture or, in the best case, lack
> of cooperation.
It's not a bad architecture, it's a evolution stage. The components
were originally developed within the Chaperon project, and were moved
to Cocoon.
And yes, I will removed the cocoon dependency of the Chaperon lib.
Stephan.