On Monday 18 October 2004 04:17, Ugo Cei wrote:
No one has ever demonstrated that doing an import on classes that are
under the LGPL obliges you to license your code under the (L)GPL.
The FSF and ASF legal counsel have both said it does.
It even goes against the publicly stated intentions
Il giorno 18/ott/04, alle 08:45, Niclas Hedhman ha scritto:
No one has ever demonstrated that doing an import on classes that
are
under the LGPL obliges you to license your code under the (L)GPL.
The FSF and ASF legal counsel have both said it does.
Really? My understanding of this is that the
On Monday 18 October 2004 15:14, Ugo Cei wrote:
Really? My understanding of this is that the issue is still open:
As FSF has not yet clarified/answered questions with regard to this,
nor has the LGPL been updated to clarify such - the murkyness around
this makes us do the 'safe' thing; which
On Monday 18 October 2004 15:14, Ugo Cei wrote:
Just to be crystal clear: what I meant to say is that if you, as
individual developer, decide to do an import net.sf.hibernate.* in a
Java source file, you can still put an APL header on top of your source
file (as long as you don't put that
Ugo Cei wrote:
Il giorno 17/ott/04, alle 17:22, Daniel Fagerstrom ha scritto:
data. In Spring you must as well supply wiring information about how
the component is connected to other components thru setters. You need
to describe the life cycle, if there are any initialization and
destruction
So, to summarise
What package names should I use?
What license should I add?
Are we going to have a multi-project repository at cocoondev.org?
Are we going to have an external-blocks build?
Thanks
regards Jeremy
On 17 Oct 2004, at 14:45, Pier Fumagalli wrote:
On 17 Oct 2004, at 14:29, Jeremy
Daniel Fagerstrom wrote:
components and property DI for optional components might be a good
approach. However, IMHO, it would not give enough advantages to be worth
any back compatibillity, a prolonged period of instabillity or (at least
for me), the effort.
Thanks Daniel for speaking it out
Il giorno 18/ott/04, alle 10:18, Jeremy Quinn ha scritto:
So, to summarise
What package names should I use?
I'd suggest org.cocoondev, assuming it is hosted at Cocoondev.org.
What license should I add?
I'd use ASL 2.0.
Ugo
--
Ugo Cei - http://beblogging.com/
smime.p7s
Description:
JD Daniels wrote:
I am about to start building a new server for my new cocoon projects.
I have a few questions:
1.) I have started using SVN in my own projects and I really like it.
but I am a little confused about about what version of cocoon supports
java 1.5, and if that suport is
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=15316.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 18 Oct 2004, at 10:18, Jeremy Quinn wrote:
So, to summarise
What package names should I use?
org.cocoondev should be OK.
What license should I add?
You _can_ do AL2 if you make it clear that the redistribution clause is
tainted by the LGPL dependency, so people should do their own due
On Monday 18 October 2004 16:27, Reinhard Poetz wrote:
Thanks Daniel for speaking it out loudly: Who wants to get his hands dirty
with the two implementations
- kernel (inter-block communication, classloader shielding)
- new Cocoon core engine
and which time frames are those people
On 18 Oct 2004, at 10:24, Steven Noels wrote:
On 18 Oct 2004, at 10:18, Jeremy Quinn wrote:
So, to summarise
What package names should I use?
org.cocoondev should be OK.
eg.
org.cocoondev.cocoon.hibernate ???
or
org.cocoondev.hibernate ??
etc.
What license should I add?
You
On 15 Oct 2004, at 19:32, Reinhard Poetz wrote:
Steven, is moving to org.cocoondev an option, or do we have other
alternatives?
Sure you can use the package name if you want to. If you need commit
access on http://svn.cocoondev.org/, LMK (Rhino+cont sources were moved
to Subversion).
/Steven
Niclas Hedhman wrote:
Yes. As a user, that is the essence. What are the 'Dates of
RoadMap Milestones and who are driving those besides Pier,
Sylvain and Ugo?
So, we can get some birds-eye view, and avoid another 2.x
styled delays.
We agreed that the new core (or the blocks
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be bad
if someone had to
Steven Noels wrote:
On 15 Oct 2004, at 19:32, Reinhard Poetz wrote:
Steven, is moving to org.cocoondev an option, or do we have other
alternatives?
Sure you can use the package name if you want to. If you need commit
access on http://svn.cocoondev.org/, LMK (Rhino+cont sources were moved
to
On 18 Oct 2004, at 12:30, Reinhard Poetz wrote:
Steven Noels wrote:
On 15 Oct 2004, at 19:32, Reinhard Poetz wrote:
Steven, is moving to org.cocoondev an option, or do we have other
alternatives?
Sure you can use the package name if you want to. If you need commit
access on
On 18 Oct 2004, at 11:57, Carsten Ziegeler wrote:
Thoughts? Comments?
I like. Not for compatibility reasons, but merely for untying us from
the ECM knot. If and when we get to move Cocoon further along the road
of our own thing, at least we will have a stable baseline to fall back
to.
/Steven
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
Add your reasons.
Since Avalon came to life and I came to love it, I've had long fights
with some of my colleagues at work to convince them to use it, in
order to have robust architectures. Their argument was that they
didn't want to use
Steven Noels wrote:
On 18 Oct 2004, at 12:30, Reinhard Poetz wrote:
Steven Noels wrote:
On 15 Oct 2004, at 19:32, Reinhard Poetz wrote:
Steven, is moving to org.cocoondev an option, or do we have other
alternatives?
Sure you can use the package name if you want to. If you need commit
access on
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31657.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31657.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31657.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
the minimum functionality.
Hmmm, I like it. But I
Ugo Cei wrote:
Il giorno 18/ott/04, alle 11:57, Carsten Ziegeler ha scritto:
The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and
build a complete container in Cocoon that provides the minimum
Il giorno 18/ott/04, alle 14:14, Carsten Ziegeler ha scritto:
I totally agree, we should have tests. Now, I'm not sure what the
best way to do this is. As I already started :), I think finishing
this first phase, committing it, then adding tests, continuing is
at least for me a little bit easier.
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be
Le 18 oct. 04, à 11:57, Carsten Ziegeler a écrit :
...I just started with this approach and could finish it in the next
days
if people think it is worth going this way. It would give 2.2 more meat
as well...
I like the idea of having our own version of ECM, and if you have code
already I'd say
Luca Morandini wrote:
Vadim Gritsenko wrote:
Luca Morandini wrote:
Vadim Gritsenko wrote:
Problem is that currently Flow session scope is not serializable.
WebLogic requires session attributes to be serializable (required
for clustering).
I mean, is flow unusable on WebLogic ?
Flow requires
Vadim Gritsenko wrote:
Sounds good with the only exception that I'm not sure about
instrumentation vs JMX part. Anybody have ideas how Cocoon
should be integrated with JMX? What management console we
would use then?
I think this is an open topic. The first thing imho is to remove
the
Il giorno 18/ott/04, alle 14:29, Vadim Gritsenko ha scritto:
And what is wrong with that approach (of just using it)? Beside
community issues there were no technical issues which would force us
to move people out of current component management infrastructure.
Right?
Personally, I think there
On 18 Oct 2004, at 13:54, Reinhard Poetz wrote:
I'll create a branch with the current version and renaming will be
done in trunk - as this are the sources where we create builds for
Cocoon from.
+1
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open
On Monday 18 October 2004 17:57, Carsten Ziegeler wrote:
But perhaps this idea is totally foolish?
Not at all.
Very pragmatic, well balanced and sensible thing to do.
And it seems you have a lot of support, and if that support is translated in
to coding help, we are all grateful.
Cheers
On Monday 18 October 2004 20:48, Ugo Cei wrote:
As we cannot depend on the Avalon community for mending some of these
deficiencies, I heartily applaud Carsten's effort towards bringing that
code inside, so we can at least try fixing them ourselves.
Small correction; ECM is in
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be
Ralph Goers wrote:
FWIW, we had trouble getting Flowscript to work with Weblogic because
weblogic had its own version of Rhino.
Ouch ! Did you succeed in the end ?
Regards,
---
Luca Morandini
[EMAIL PROTECTED]
http://www.lucamorandini.it
---
Sylvain Wallez wrote:
As long as the compatibility layer remains, I don't see what
invites people to migrate to new features. Is it just because
new features will be available? Then having them because of
an updated old container or because of a newer one with a
legacy layer isn't very
Carsten Ziegeler wrote:
snip/
Adding new things on top of an old one provides a smooth migration
path, as you can still use the old ones and one or two additional
ones.
If you have a compatibility layer this most often means that you
can either use this layer or the new functionality. So there
I encourage Carsten to wholeheartedly undertake this task. I really
only have two thoughts.
1. I don't think it is a good idea to keep the same package names for
ECM if they are moved into Cocoon. That could be very confusing. I
realize it would be a lot of work to rename existing classes
Carsten Ziegeler wrote:
I just started with this approach and could finish it in the next days
if people think it is worth going this way. It would give 2.2 more meat
as well.
But perhaps this idea is totally foolish?
Thoughts? Comments?
+1
Seem like a very reasonable way to go, we both takes
[EMAIL PROTECTED] wrote:
Author: unico
Date: Mon Oct 18 06:10:24 2004
New Revision: 55002
Added:
cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java
Modified:
cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/EnvironmentWrapper.java
Log:
introduce
Vadim Gritsenko wrote:
Are you talking with me or with yourself? :)
To myself, but loudly... so you could step in if I said something stupid ;)
Regards,
---
Luca Morandini
[EMAIL PROTECTED]
http://www.lucamorandini.it
---
Ralph Goers wrote:
FWIW, we had trouble getting Flowscript to work with Weblogic because
weblogic had its own version of Rhino.
Using the ParanoidCocoonServlet may be a solution in that case as it
shields Cocoon into its own classloader.
Sylvain
--
Sylvain Wallez
Ralph Goers wrote:
I encourage Carsten to wholeheartedly undertake this task. I
really only have two thoughts.
1. I don't think it is a good idea to keep the same package
names for ECM if they are moved into Cocoon. That could be
very confusing. I realize it would be a lot of work to
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Author: unico
Date: Mon Oct 18 06:10:24 2004
New Revision: 55002
Added:
cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java
Modified:
Unico Hommes wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Author: unico
Date: Mon Oct 18 06:10:24 2004
New Revision: 55002
Added:
cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java
Modified:
Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Author: unico
Date: Mon Oct 18 06:10:24 2004
New Revision: 55002
Added:
cocoon/trunk/src/java/org/apache/cocoon/environment/wrapper/ResponseWrapper.java
Modified:
I would suggest that new o.a.cocoon interfaces be used which, for the time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future.
Ralph
Carsten Ziegeler said:
Ralph
ParanoidCocoonServlet failed miserably in Weblogic. I don't recall why.
Our solution was to use Javaflow.
I don't know if Weblogic Express has the same problem.
Ralph
Sylvain Wallez said:
Ralph Goers wrote:
FWIW, we had trouble getting Flowscript to work with Weblogic because
weblogic
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community. I just
did a svn up on the 2.1 branch;
A
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the future.
Don't know, if this
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Reinhard Poetz wrote:
Ralph Goers wrote:
I would suggest that new o.a.cocoon interfaces be used which, for the
time
being simply extend the existing interfaces. The use of the
avalon/excalibur interfaces should be deprecated. This will allow the
complete removal of Avalon/Excalibur in the
Stefano Mazzocchi wrote:
Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:
Because they have been around forever *AND* they don't change their
contracts overnight.
Your talk is not entirely reflected by the actions of the community.
I just did a svn up on the
Hello all!
the first, my english is very very bad so i'm sorry if i don't to
explain very well.
I have a portlet with his sitemap file, XML input file how
'map:generate cocoon' and XSL output file how 'map:transform
cocoon'.
My idea is in my XSL file i check a condition with a label of my XML
Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org (like my
own CVSSource), what about creating a general-purpose project that would
host all interesting cocoon-releated things we cannot host at the ASF
because of license problems?
What about lobbying about
Niclas Hedhman wrote:
On Monday 18 October 2004 04:17, Ugo Cei wrote:
No one has ever demonstrated that doing an import on classes that are
under the LGPL obliges you to license your code under the (L)GPL.
The FSF and ASF legal counsel have both said it does.
This is not correct. Some ASF
Thank you both for your answers :)
Im on my way
JD
Upayavira wrote:
JD Daniels wrote:
I am about to start building a new server for my new cocoon projects.
I have a few questions:
1.) I have started using SVN in my own projects and I really like it.
but I am a little confused about about
Niclas Hedhman wrote:
On Monday 18 October 2004 15:14, Ugo Cei wrote:
Really? My understanding of this is that the issue is still open:
As FSF has not yet clarified/answered questions with regard to this,
nor has the LGPL been updated to clarify such - the murkyness around
this makes us do the
Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org (like
my own CVSSource), what about creating a general-purpose project that
would host all interesting cocoon-releated things we cannot host at
the ASF because of license problems?
Pier made me realize that there are 3 different issues on the table
regarding real blocks:
1) classloading isolation
2) pojoification
3) service isolation
and, interestingly enough, they are orthogonal.
Tani was born to prototype 1.
Butterfly was born to prototype 2.
But what I really care is
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org (like
my own CVSSource), what about creating a general-purpose project that
would host all interesting cocoon-releated things we cannot host at
the ASF because of
On Mon, 18 Oct 2004, Stefano Mazzocchi wrote:
What does this translate to java? Pretty simple, in fact: if you import
a class is fine, if you implement an interface is not.
Let me resend them a msg of a few weeks, months now ago, (to their ED
Bradley Kun and their Compliance Office David
Dirk-Willem van Gulik wrote:
On Mon, 18 Oct 2004, Stefano Mazzocchi wrote:
What does this translate to java? Pretty simple, in fact: if you import
a class is fine, if you implement an interface is not.
Let me resend them a msg of a few weeks, months now ago, (to their ED
Bradley Kun and their
Is what you said below correct? or did you really intend
map:transformer name=blah/* uri=http://apache.org/blah/Blah/
map:param name=src value={1}.src/
/map:transformer
Ralph
Stefano Mazzocchi said:
Now, look at this
map:transform name=blah/*
On 17 Oct 2004, at 21:17, Ugo Cei wrote:
Il giorno 17/ott/04, alle 15:45, Pier Fumagalli ha scritto:
The code can't be licensed using the Apache License 2.0. It's LGPL as
it implements certain LGPL Hibernate classes. That's the whole
reason why we can't post it here...
Do your classes really
On 18 Oct 2004, at 18:27, Stefano Mazzocchi wrote:
I would like to change the ASF policy toward the LGPL saying that
importing is ok, implementing is not. That means that if you
implement, your code has to be LGPL, then you can import that. The
spirit of the LGPL is maintained and the FSF
On 18 Oct 2004, at 20:02, Pier Fumagalli wrote:
It even goes against the publicly stated intentions of the Hibernate
developers. I'd use the Apache license without fear in this case (as
a matter of fact, I do).
And as an ASF member, if what you written is (C) Apache Software
Foundation, I'd not
On 18 Oct 2004, at 18:27, Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org
(like my own CVSSource), what about creating a general-purpose
project that would host all interesting
On Tuesday 19 October 2004 01:27, Stefano Mazzocchi wrote:
What does this translate to java? Pretty simple, in fact: if you import
a class is fine, if you implement an interface is not.
Nice try :o)
But assuming for a second that the 'spirit' is what you say (which I would
like to think), the
Ugo Cei dijo:
FYI, I've just uploaded the Spring Petstore sample that was on the wiki
(at http://wiki.apache.org/cocoon/SpringPetstore ) to the Cocoondev
site at http://new.cocoondev.org/main/g1/43
Great! Thanks for that Ugo!
Best Regards,
Antonio Gallardo
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31760.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefano Mazzocchi dijo:
Besides: what the heck does this list has to do with Daisy anyway?
+1 ;-)
Best Regards,
Antonio Gallardo
On Mon, 18 Oct 2004 10:20:03 -0700, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Pier made me realize that there are 3 different issues on the table
regarding real blocks:
1) classloading isolation
2) pojoification
3) service isolation
Aha!
...
So here is my proposal for Cocoon 2.2
Sylvain Wallez dijo:
Stefano Mazzocchi wrote:
You want daisy to use JDO? submit code instead of evangelizing.
Besides: what the heck does this list has to do with Daisy anyway?
Although off-topic, Daisy is part of the Cocoon galaxy. So more
importantly, what the heck does this list has to
Il giorno 18/ott/04, alle 20:02, Pier Fumagalli ha scritto:
And as an ASF member, if what you written is (C) Apache Software
Foundation, I'd not be sleeping quiet nights...
No, it is just distributed under the ASL. As a matter of fact, it does
not even import Hibernate packages, it imports
Arje Cahn dijo:
Hi everyone,
One big thanks to everyone involved in organizing another brilliant
G(h)e(n)tTogether.
I had great fun talking to everyone and hearing all about the latest
Cocoon news, and I'm definitely looking forward to see you all next year.
Diner was great, beers were
Stefano Mazzocchi wrote:
Pier made me realize that there are 3 different issues on the table
regarding real blocks:
1) classloading isolation
2) pojoification
3) service isolation
and, interestingly enough, they are orthogonal.
Tani was born to prototype 1.
Butterfly was born to prototype 2.
Ralph Goers wrote:
Is what you said below correct? or did you really intend
map:transformer name=blah/* uri=http://apache.org/blah/Blah/
map:param name=src value={1}.src/
/map:transformer
I stand corrected.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Carsten Ziegeler dijo:
So, a big +1 for not depending on someone else, regardless who they
are or how brilliant the project seems today.
I thought that was already agreed at the hackthon. But seems things are
not clear so here is my +1 too. ;-)
Best Regards,
Antonio Gallardo
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Pier made me realize that there are 3 different issues on the table
regarding real blocks:
1) classloading isolation
2) pojoification
3) service isolation
and, interestingly enough, they are orthogonal.
Tani was born to prototype 1.
Butterfly was
http://www.1060research-server-1.co.uk/docs/1.4.0/book/introduction/doc_intro_concepts_requests.html
what do you guys think about Netkernel?
it seems to take some cocoon concepts much further (maybe too far?)
there is also some history available at
One thing confuses me still about this syntax. In Cocoon today the
transformer operates on incoming SAX events and can use what is in the src
parameter for whatever purpose it wants. In many scenarios the src
parameter can be specified as cocoon://whatever so that the stylesheet
(or whatever
85 matches
Mail list logo
