You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2003/01/24 19:38:51 UTC
ChartTransformer 0.0.4 urge a commiter!
Hey commiters, what are you waiting for?
This is a very interesting stuff. Please, Hurry up! ;-D
http://www.sidimar.ipzs.it/site/
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Its OK. I know we must play with the world rules. We will wait for the
official donation. :-)
Antonio.
Steven Noels dijo:
> Luca Morandini wrote:
>
>> Steven,
>>
>> I'll arrange the donation in a few days :)
>
> sure thing - just playing by the rules...
>
> given the fact we have our own PMC now, we are 'on our own' now and
> supposed to have oversight whether these things are done by the book
>
> </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
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Luca Morandini wrote:
> Steven,
>
> I'll arrange the donation in a few days :)
sure thing - just playing by the rules...
given the fact we have our own PMC now, we are 'on our own' now and
supposed to have oversight whether these things are done by the book
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Antonio Gallardo wrote:
> <Steven>
> But as I said in the SAP R/3 case, this won't solve the problem of the
> corpulent codebase, and the issues with oversight that comes with its
> weight. Your efforts in blockifying stuff have already unearthed several
> issues, and I think we should actively try to keep the core codebase clean
> & healthy.
> </Steven>
>
> I think it is time to start thinking in a plug-in technology for Cocoon.
> As Steven pointed. It is inevitable to let people add more and more
> components (generators, transformers, etc) to Cocoon.
Welcome to the world of Cocoon Blocks.
> What about let people choice what they need? Then they will download only
> the pieces of code they need. I know this currently can be done manually,
> but we must find an easy and standard way to deploy the new components.
> Like a "Lego" toy.
Thet's a further setp in blocks.
The downloading part is easy, there is already a tool called Ruper that
does it with version info etc.
The fact is that now blocks are needed before Cocoon startup, or even
worse, at compile-time for the ones using Avalon Components.
If you want to help us on this and have time, it would be great.
The first think to do now IMHO, is to have blocks that don't need to be
compiled with Cocoon. In fact Cocoon now includes roles in the
cocoon.jar file, so we have to rebuild the cocoon.jar with the infos
about the roles needed for the Avalon components in the blocks.
When this is done, all blocks can be added without recompiling Cocoon,
and I can add the remote-download feature.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: UnBlocking Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
[...]
>> Now, blocks are needed for two reasons:
>>
>> 1 - separate components development and deployment from Cocoon
>> 2 - dynamic loading, polimorphic usage and wizbang super extra
>> inheritance
>>
>> I see the first part much easier to accomplish than the second, and we
>> could get to that point much easier.
>
> True, I see wisdom in your thinking.
>
> Only a few details... see below.
>
>> Step 1 is the last iteration of the .jar blocks.
>> Step 2 is the .cob system.
>>
>> What do we need to get to step 1, that will alleviate problems a lot?
>>
>> - loading of Avalon components from the block jars
>> - loading of Cocoon components from the block jars
>> - way of defining blocks in the sitemap
>
> this should be future compatible with the planned cob design, otherwise
> we'll break things again.
Yup.
>> - automatic download of blocks
>>
>> I imagine a
>>
>> components
>> blocks
>>
>> section, where I can specify the block to use, and the default
>> download location, and the Cocoon components to load.
>>
>> Something like:
>>
>> <map:blocks repository="blah">
>> <map:block name="batik" version="..."/>
>> <map:block name="fop" version="..."/>
>> </map:blocks>
>>
>> and
>>
>> <map:serializer mime-type="image/png"
>> name="svg2png"
>> src="o.a.c.s.SVGSerializer"
>> block="batik"/>
>>
>> This way we just tell the component to be loaded from a specific block.
>
> As far as classes go (avalon and cocoon components), don't forget that
> we already have unique identifiers, so the sitemap should not include
> that information but it should be somewhere else, and should be treated
> by the classloader as a way to know where to get stuff.
You mean the block="batik" attribute in the serializer.
I didn't like it when I post it, and I like it even less now ;-)
>> The automatic download of blocks is not a problem. Krysalis Ruper
>> already is able to download things and has a nice version
>> specification system, so that part is solved.
>
> Uh, cool, didn't know that.
>
>> What remains is the automatic load from the block jar, and how to tell
>> the sitemap to do it.
>
> As I said, I don't think the sitemap should be any different from that
> is now. It should be the classloader's concern to know where to get
> those classes.
Ok.
>> Given that Fortress is ECM2, and given that we are going to release
>> soon, if we need some feature we can ask if it can support it and move
>> to Fortress.
>>
>> This will give us breathing room for Merlin and proper block
>> implementation.
>
> I'm +1 on implementing blocks incrementally, but only if this doesn't
> require to break things later on (like atting the block="" attribute
> first and then remove it later)
>
> what do you think?
Agreed. But we do need to have a <map:blocks>, no? We have to specify
the version and the name of the blocks, so it should simply be:
<map:blocks repository="blah">
<map:block name="batik" version="..."/>
<map:block name="fop" version="..."/>
</map:blocks>
and have the rest work exactly as now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: UnBlocking Blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Stefano Mazzocchi wrote:
>
>> Antonio Gallardo wrote:
>>
>>> I think it is time to start thinking in a plug-in technology for Cocoon.
>>
>>
>>
>> Yes, it's time, but our avalon container is not good enough for that
>
>
> Let's put down what is lacking, and what the intermediate goals are.
>
> Avalon will do this now:
> - release Fortress
> - release Merlin extends Fortress
> - work on Avalon 5
>
> Merlin is the thing that can give us real blocks.
>
>> But I'm wide open to suggestions on how to move this forward.
>
>
> This is basically what I have proposed at the last live-meeting:
> IMHO blocks need to be done in a slow and steady manner, because we are
> walking on new ground and I don' twant CocoonHEAD to break for big changes.
> Avalon will soon release Fortress, that is a ECM successor.
>
> Now, blocks are needed for two reasons:
>
> 1 - separate components development and deployment from Cocoon
> 2 - dynamic loading, polimorphic usage and wizbang super extra
> inheritance
>
> I see the first part much easier to accomplish than the second, and we
> could get to that point much easier.
True, I see wisdom in your thinking.
Only a few details... see below.
> Step 1 is the last iteration of the .jar blocks.
> Step 2 is the .cob system.
>
> What do we need to get to step 1, that will alleviate problems a lot?
>
> - loading of Avalon components from the block jars
> - loading of Cocoon components from the block jars
> - way of defining blocks in the sitemap
this should be future compatible with the planned cob design, otherwise
we'll break things again.
> - automatic download of blocks
>
> I imagine a
>
> components
> blocks
>
> section, where I can specify the block to use, and the default download
> location, and the Cocoon components to load.
>
> Something like:
>
> <map:blocks repository="blah">
> <map:block name="batik" version="..."/>
> <map:block name="fop" version="..."/>
> </map:blocks>
>
> and
>
> <map:serializer mime-type="image/png"
> name="svg2png"
> src="o.a.c.s.SVGSerializer"
> block="batik"/>
>
> This way we just tell the component to be loaded from a specific block.
As far as classes go (avalon and cocoon components), don't forget that
we already have unique identifiers, so the sitemap should not include
that information but it should be somewhere else, and should be treated
by the classloader as a way to know where to get stuff.
> The automatic download of blocks is not a problem. Krysalis Ruper
> already is able to download things and has a nice version specification
> system, so that part is solved.
Uh, cool, didn't know that.
> What remains is the automatic load from the block jar, and how to tell
> the sitemap to do it.
As I said, I don't think the sitemap should be any different from that
is now. It should be the classloader's concern to know where to get
those classes.
> Given that Fortress is ECM2, and given that we are going to release
> soon, if we need some feature we can ask if it can support it and move
> to Fortress.
>
> This will give us breathing room for Merlin and proper block
> implementation.
I'm +1 on implementing blocks incrementally, but only if this doesn't
require to break things later on (like atting the block="" attribute
first and then remove it later)
what do you think?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: UnBlocking Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
> Given that Fortress is ECM2, and given that we are going to release
> soon, ^^^^
Avaloners
Being multiproject %-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
UnBlocking Blocks
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Antonio Gallardo wrote:
>
>> I think it is time to start thinking in a plug-in technology for Cocoon.
>
>
> Yes, it's time, but our avalon container is not good enough for that
Let's put down what is lacking, and what the intermediate goals are.
Avalon will do this now:
- release Fortress
- release Merlin extends Fortress
- work on Avalon 5
Merlin is the thing that can give us real blocks.
> But I'm wide open to suggestions on how to move this forward.
This is basically what I have proposed at the last live-meeting:
IMHO blocks need to be done in a slow and steady manner, because we are
walking on new ground and I don' twant CocoonHEAD to break for big changes.
Avalon will soon release Fortress, that is a ECM successor.
Now, blocks are needed for two reasons:
1 - separate components development and deployment from Cocoon
2 - dynamic loading, polimorphic usage and wizbang super extra
inheritance
I see the first part much easier to accomplish than the second, and we
could get to that point much easier.
Step 1 is the last iteration of the .jar blocks.
Step 2 is the .cob system.
What do we need to get to step 1, that will alleviate problems a lot?
- loading of Avalon components from the block jars
- loading of Cocoon components from the block jars
- way of defining blocks in the sitemap
- automatic download of blocks
I imagine a
components
blocks
section, where I can specify the block to use, and the default download
location, and the Cocoon components to load.
Something like:
<map:blocks repository="blah">
<map:block name="batik" version="..."/>
<map:block name="fop" version="..."/>
</map:blocks>
and
<map:serializer mime-type="image/png"
name="svg2png"
src="o.a.c.s.SVGSerializer"
block="batik"/>
This way we just tell the component to be loaded from a specific block.
The automatic download of blocks is not a problem. Krysalis Ruper
already is able to download things and has a nice version specification
system, so that part is solved.
What remains is the automatic load from the block jar, and how to tell
the sitemap to do it.
Given that Fortress is ECM2, and given that we are going to release
soon, if we need some feature we can ask if it can support it and move
to Fortress.
This will give us breathing room for Merlin and proper block implementation.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Stefano Mazzocchi <st...@apache.org>.
Antonio Gallardo wrote:
> I think it is time to start thinking in a plug-in technology for Cocoon.
Yes, it's time, but our avalon container is not good enough for that and
avalon-dev is currently a big community mess.
I'm concerned. I really am. I'm about to fork and write my own avalon
container for cocoon blocks and screw them.... this project can't wait
another 6 months for a serious container to happen.
the block pressure will tear us apart.
> As Steven pointed. It is inevitable to let people add more and more
> components (generators, transformers, etc) to Cocoon.
True.
> What about let people choice what they need? Then they will download only
> the pieces of code they need. I know this currently can be done manually,
> but we must find an easy and standard way to deploy the new components.
> Like a "Lego" toy.
We already have a pretty detailed plan of action.
Look for "cocoon blocks" in the wiki.
But implementing it is hard, not technologically but politically. It
must be done right from a community dynamic perspective and we have to
get out with Cocoon 2.1 first.
But I'm wide open to suggestions on how to move this forward.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
<Steven>
But as I said in the SAP R/3 case, this won't solve the problem of the
corpulent codebase, and the issues with oversight that comes with its
weight. Your efforts in blockifying stuff have already unearthed several
issues, and I think we should actively try to keep the core codebase clean
& healthy.
</Steven>
I think it is time to start thinking in a plug-in technology for Cocoon.
As Steven pointed. It is inevitable to let people add more and more
components (generators, transformers, etc) to Cocoon.
What about let people choice what they need? Then they will download only
the pieces of code they need. I know this currently can be done manually,
but we must find an easy and standard way to deploy the new components.
Like a "Lego" toy.
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Donated stuff [WAS: RE: ChartTransformer 0.0.4 urge a commiter!]
Posted by Steven Noels <st...@outerthought.org>.
Luca Morandini wrote:
> So, IMHO, the community should welcome donations, as long as they
> come with no string attached and fit into the general vision.
Sure, but you are stating it a bit twisted yourself what the reasons are
behind a donation ;-)
> Regards,
>
> P.S. A big kiss to you as well, provided you shaved this morning ;)
> ...hmmm, let downsize it to a bear hug ;)
Yummy :-)
Just to put things in perspective: why don't we (Outerthought) try to
donate xreporter to Cocoon? Because it feels wrong right now, having
done all development in-house and such. But we explicitely added a
clause to the license stating that it might eventually be donated to a
larger open source body.
I hope there's more sense in my long reply than the 'loath' thing. That
was a bold thing to say, and sorry of it offended anyone.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Donated stuff [WAS: RE: ChartTransformer 0.0.4 urge a commiter!]
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Saturday, January 25, 2003 11:10 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
> I loath to see people creating stuff outside this community, but with
> the intent to have it moved into Cocoon afterwards. Sorry to say so, and
> please don't take this as a criticism.
Steven, I beg your pardon, but I disagree with this statement.
Yes, in an ideal world we'd happily code all together, but this being the real world, sometimes happens that you develop a piece of
software for a specific customer and only after the customer's needs are met (in terms of time and features) you can think about
donating it.
This is especially true for a package like Cocoon, which is, first and foremost, the plumbing holding software components together
(the water being XML, of course).
So, IMHO, the community should welcome donations, as long as they come with no string attached and fit into the general vision.
Regards,
P.S.
A big kiss to you as well, provided you shaved this morning ;) ...hmmm, let downsize it to a bear hug ;)
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Torsten Curdt <tc...@dff.st>.
Antonio Gallardo wrote:
> Steven Noels dijo:
>
>>Antonio Gallardo wrote:
>>
>>
>>>Oops. I wrote the initial mail of the thread in the good sense. I
>>>think that Cocoon need a chart transformer as it use a PDF serializer,
>>>MP3 directory generator and so on. By the way into Cocoon we see 2 PDF
>>>serializer:
>>>
>>>itext and FOP.
>>
>>those are very different things in my book - have a look at the input
>>format itext requires, and you'll see that it is quite different
>>
>>but you are right, and once again proving my point: too much 'options'
>>for the newcomer
>
>
> Another example:
>
> ESQL tranformer and the ESQL logicsheet for XSP. What about that? Always
> is the same SQL.
...you mean the SQL transformer - not ESQL
(BTW: transformer vs logicsheet is a big difference no matter if they
*might* share the same syntax - as they don't)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Steven Noels dijo:
> Antonio Gallardo wrote:
>
>> Oops. I wrote the initial mail of the thread in the good sense. I
>> think that Cocoon need a chart transformer as it use a PDF serializer,
>> MP3 directory generator and so on. By the way into Cocoon we see 2 PDF
>> serializer:
>>
>> itext and FOP.
>
> those are very different things in my book - have a look at the input
> format itext requires, and you'll see that it is quite different
>
> but you are right, and once again proving my point: too much 'options'
> for the newcomer
Another example:
ESQL tranformer and the ESQL logicsheet for XSP. What about that? Always
is the same SQL.
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Antonio Gallardo wrote:
> Oops. I wrote the initial mail of the thread in the good sense. I think
> that Cocoon need a chart transformer as it use a PDF serializer, MP3
> directory generator and so on. By the way into Cocoon we see 2 PDF
> serializer:
>
> itext and FOP.
those are very different things in my book - have a look at the input
format itext requires, and you'll see that it is quite different
but you are right, and once again proving my point: too much 'options'
for the newcomer
> I never thinked it will trig a hot discusion. Sorry for that.
discussions are good, no?
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Oops. I wrote the initial mail of the thread in the good sense. I think
that Cocoon need a chart transformer as it use a PDF serializer, MP3
directory generator and so on. By the way into Cocoon we see 2 PDF
serializer:
itext and FOP.
I never thinked it will trig a hot discusion. Sorry for that.
Antonio Gallardo.
Nicola Ken Barozzi dijo:
>
>
> Steven Noels wrote:
>> Luca Morandini wrote:
>>
>>> Steven, this begs another question: what's should be inside Cocoon ?
>
> [...]
>> To me, a component/block has not only a 'separateable' implementation,
>> which shows in the package naming and the fact it being a block, but
>> also some 'principal caretaker', if I may say so in an open source
>> project where all code belongs to the community.
>
> So should Bugzilla, so should the site, so should the build... right?
> More organization, this is too chaotic >:->
>
>> A component should also
>> have a separate release schedule/lifecycle (not in the Avalon sense),
>> and would require a well-defined _release_ version of Cocoon. Take
>> XMLForm as an example: it will only be 'released' when 2.1 is out. And
>> new releases of it thereafter will remain dependent on the release
>> cycle of Cocoon.
>>
>> OK, I'm not the coding wizard, but this is basically the _functional_
>> reason of the existence of blocks in my perspective. But I fear that
>> this vision behind blocks will never come true if we don't separate
>> blocks physically from the Cocoon core. Blocks-people, correct me when
>> my assumption is wrong.
>
> Steven, probably you're dreaming. We don't have blocks (yet). We have
> just separated code from the core and are trying to hack a block
> implementation.
>
> The day they will *effectively* be able to be compiled and added to
> Cocoon in a complete separate fashion, I will want to see it too.
> Probably you don't know how it works that much now.
>
>>> Or, more to the point, should a chart-producing package be inserted
>>> in the codebase ?
>>
>> Nope, but SAP connectivity blocks neither, and 5 different database
>> access methods
>> (http://outerthought.net/gettogether/original/Tortsen-orig.pdf) also,
>> etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be
>> Apache projects, even better Cocoon subprojects...? Yes, of course!
>
> Kernel?
>
> src/java/** == kernel
> src/blocks/** != kernel
>
> Do I see a time when cocoon.apache.org has a section where the blocks
> have their own lifecycle, are detatched from core and the development
> bubbles of activity?
>
> Yes.
>
> Is it possible *now*?
>
> Nope.
>
>>> A) If the answer is yes (as it is now), sooner or later a decision
>>> should be made between Wings and ChartTransformer (supporting both
>>> doesn't seem sensible to me ).
>>
>>
>> See above, there might be room for n implementations, and the nature
>> of open source is that the 'best' will survive. I advocate some
>> garbage collection if some component becomes MIA.
>
> Be careful here. I've seen a community shattered to pieces because they
> used software darwinism as the only way of moving forward.
>
> It breaks communities, makes egos grow, and doesn't make it possible for
> the project to go forward.
>
> One thing is having competing codebases based on technical differences,
> one is competing people. Do you really think a charting block has such
> different architectural needs that competition is needed? Come 'on...
>
> Competition is a poor substitute of collaboration.
>
>> So I don't see why two implementations of the same problem can't
>> coexist in one repository, but I don't believed in 'forced'
>> integration or merging, as a requirement before one of them being
>> added. Not anymore: this community alchemy has been tried and tested
>> before, and I don't think it works.
>
> Tried and tested? Where?
> The opposite was tries and tested. It's called Avalon (Excalibur(ECM,
> Merlin, Fortress,...), Cornerstone, Phoenix, ...), and it was a
> community failure.
>
>> If Wings & ChartTransformer have a reason to integrate,
>> that will eventually happen, but not because someone made it a
>> requirement. It might happen only because of the intrinsic need to
>> integrate (for technical or human reasons) both implementations. As it
>> is now, these reasons apparently don't exist, and I have no problems
>> with that.
>
> I never said it has to be a requirement. If Cocoon is to have *a*
> charting package, I'd like to see them integrated, and not see
> JFreeChart used as a default implementation.
>
> In the other case, the two can coexist, but it seems stupid to me. If we
> cannot cooperate in a charting package... heck, it's ridiculous!
>
>> I have a problem (and you will see me bringing this up on
>> each opcoming addition) with the fact new stuff gets added to the core
>> if it can be done equally well outside it, especially since we now
>> have the possibility to address these things structurally, by
>> establishing Cocoon subprojects and whatelse.
>
> It's *not* the core. We *will* move blocks outside. Moving code away
> without a community around == killing it.
>
> So now it's impossible. Anyone wants to make blocks a reality *finally*?
> Steven? >;->
>
>>> B) If the answer is no, then delete Wings from the codebase and
>>> insert in the doc that users can create charts with Cocoon by
>>> downloading Wings and/or ChartTransformer from Krysalis and/or
>>> CocoonDev.
>>>
>>> Well, in all fairness, I'd like "my" package to enter into the
>>> standard Cocoon distro...
>
> Once it's in the Cocoon distro it's not going to be *your* package
> anymore. I would surely add the features that I want to see that are in
> Wings now, and a merge will happen anyway. Don't assumed it will
> necessarily remain that way.
>
>>>partly because I need to feed my ego (the
>>> Nirvana is still ahead of me ;) ), partly because I think that it
>>> could be a good selling point for Cocoon.
>>
>> Yes, it is. And don't worry about that Nirvana thing: if
>> ChartTransformer gets added to _a_ Apache Cocoon CVS repository, your
>> help will be needed and the appropriate privs will be granted. And if
>> your ego needs care: *big sloppy kiss* ;-)
>
> Nice joke Steven, nice joke.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Steven Noels wrote:
>
>> Luca Morandini wrote:
>>
>>> Steven, this begs another question: what's should be inside Cocoon ?
>
>
> [...]
>
>> To me, a component/block has not only a 'separateable' implementation,
>> which shows in the package naming and the fact it being a block, but
>> also some 'principal caretaker', if I may say so in an open source
>> project where all code belongs to the community.
>
>
> So should Bugzilla, so should the site, so should the build... right?
> More organization, this is too chaotic >:->
Uhm. Dunnow whether you are being sarcastic or not, but yes, I think
Cocoon is going through a transition period ATM.
>> A component should also have a separate release schedule/lifecycle
>> (not in the Avalon sense), and would require a well-defined _release_
>> version of Cocoon. Take XMLForm as an example: it will only be
>> 'released' when 2.1 is out. And new releases of it thereafter will
>> remain dependent on the release cycle of Cocoon.
>>
>> OK, I'm not the coding wizard, but this is basically the _functional_
>> reason of the existence of blocks in my perspective. But I fear that
>> this vision behind blocks will never come true if we don't separate
>> blocks physically from the Cocoon core. Blocks-people, correct me when
>> my assumption is wrong.
>
>
> Steven, probably you're dreaming. We don't have blocks (yet). We have
> just separated code from the core and are trying to hack a block
> implementation.
Perfectly aware of that (I know more about blocks & hacks than you
think, Nicola ;-)
> The day they will *effectively* be able to be compiled and added to
> Cocoon in a complete separate fashion, I will want to see it too.
> Probably you don't know how it works that much now.
Even if we complete blocks, and all the nasty sitemap grammar and
dynamic class(re)loading issues that will bring, I don't think the
matter will be over, if we don't organize the project differently. I
think what you are doing w.r.t. to blocks is a great start, BTW.
>>> Or, more to the point, should a chart-producing package be inserted
>>> in the codebase ?
>>
>>
>> Nope, but SAP connectivity blocks neither, and 5 different database
>> access methods
>> (http://outerthought.net/gettogether/original/Tortsen-orig.pdf) also,
>> etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be
>> Apache projects, even better Cocoon subprojects...? Yes, of course!
>
>
> Kernel?
>
> src/java/** == kernel
> src/blocks/** != kernel
Yep, exactly, but I think blocks should reside outside the 'kernel' CVS.
_We_ don't stores the sources for Excalibur inside Cocoon CVS, neither.
> Do I see a time when cocoon.apache.org has a section where the blocks
> have their own lifecycle, are detatched from core and the development
> bubbles of activity?
>
> Yes.
>
> Is it possible *now*?
>
> Nope.
Ah. So the issue can't be discussed? :-)
>>> A) If the answer is yes (as it is now), sooner or later a decision
>>> should be made between Wings and ChartTransformer (supporting both
>>> doesn't seem sensible to me ).
>>
>>
>>
>> See above, there might be room for n implementations, and the nature
>> of open source is that the 'best' will survive. I advocate some
>> garbage collection if some component becomes MIA.
>
>
> Be careful here. I've seen a community shattered to pieces because they
> used software darwinism as the only way of moving forward.
>
> It breaks communities, makes egos grow, and doesn't make it possible for
> the project to go forward.
>
> One thing is having competing codebases based on technical differences,
> one is competing people. Do you really think a charting block has such
> different architectural needs that competition is needed? Come 'on...
>
> Competition is a poor substitute of collaboration.
Yes, but I found you stating collaboration as a requirement for donation
quite 'strong'. Things don't work like that over here.
>> So I don't see why two implementations of the same problem can't
>> coexist in one repository, but I don't believed in 'forced'
>> integration or merging, as a requirement before one of them being
>> added. Not anymore: this community alchemy has been tried and tested
>> before, and I don't think it works.
>
>
> Tried and tested? Where?
> The opposite was tries and tested. It's called Avalon (Excalibur(ECM,
> Merlin, Fortress,...), Cornerstone, Phoenix, ...), and it was a
> community failure.
I've been a happy lurker on Avalon for quite some time. This community
is quite different, as we all know.
>> If Wings & ChartTransformer have a reason to integrate, that will
>> eventually happen, but not because someone made it a requirement. It
>> might happen only because of the intrinsic need to integrate (for
>> technical or human reasons) both implementations. As it is now, these
>> reasons apparently don't exist, and I have no problems with that.
>
>
> I never said it has to be a requirement. If Cocoon is to have *a*
> charting package, I'd like to see them integrated, and not see
> JFreeChart used as a default implementation.
Sure. That can become the case if they are living inside the same community.
</>
>> Yes, it is. And don't worry about that Nirvana thing: if
>> ChartTransformer gets added to _a_ Apache Cocoon CVS repository, your
>> help will be needed and the appropriate privs will be granted. And if
>> your ego needs care: *big sloppy kiss* ;-)
>
>
> Nice joke Steven, nice joke.
Uh??
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 28 January 2003 17:53, Stefano Mazzocchi wrote:
> I've received private comments that suggested me to avoid doing those
> little asskicks of mine in public. Sometimes I do them privately,
> sometimes I do them publicly, mostly depends on who the person is.
People with a lot of community experience both takes "less notice" of personal
attacks to fellow community members (i.e. disregard them and/or turn them
against the attacker) and "can ignore' personal attacks on ourselves, without
retaliation.
That said, Mr Principal, your actions are perhaps warranted to settle disputes
among less "domesticated" members, to restore community harmony.
Nicola.... Luca... Shake hands, apologize, no hard feelings, heat of the
battle, we can all get along. Ok?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote:
>
>> Nicola, you crossed the line.
>
>
> Sorry :-/
>
> Luca and all cocoon-dev, please accept my sincere apologies.
Thank you, your prompt apologies are accepted and greatly appreciated.
I've received private comments that suggested me to avoid doing those
little asskicks of mine in public. Sometimes I do them privately,
sometimes I do them publicly, mostly depends on who the person is.
Nicola is a guy I highly respect. The more I respect you, the more I
think you can handle public things. I consider your ego to be an
obstacle to your work (and a big obstacle for women entering any
male-polarized community!) and I'll do whatever I can to let you
understand this.
A private message would have helped Nicola, but wouldn't have helped you
understanding me and wouldn't have helped you understanding that Nicola
recognized his action and put his ego on a side, earning back the
respect that his last action had a little diluted.
The intention of my public email was to give Nicola the chance to earn
back his respect and to show you all that he deserves yours, no matter
what silly 'faux-pas' he or you do.
Remember: you should be happier when somebody proves or shows you wrong
rather than right, because then the only time you get to learn something
you didn't know before.
Cocoon is a community of people first, and a software project later. And
I realize this by how many times I've been proven wrong, or my personal
random thoughts have been shaped into rock-solid design built to last.
A little ego is a powerful fuel for innovation, but too much will blind
your ability to see your mistakes, thus slowing down your possibility to
learn from others and improve yourself.
Food for thoughts.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Thursday, January 30, 2003 11:04 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a
> commiter!]
> > 4) Donate, to the prospective Cocoon-GIS project (see 3), a
> > transformer to connect Cocoon with ArcIMS, a proprietary web-mapping
> > package
>
> Given my recent private enquiry, and some Apachians playing with the
> idea of mapping committer's geographic locations, that would be a nice
> toy project as a sampler.
Ahem... I wrote "proprietary": that toy project of yours would cost about EUR 10.000 (the street price of ArcIMS... give or take
something).
Anyway, there are open-source alternatives as well, though not as powerful :(
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Steven Noels <st...@outerthought.org>.
Luca Morandini wrote:
> 1) Bring the JFreeChartTransformer (aka ChartTransformer) under the
> aegis of CocoonDev... (provided CocoonDev board accepts it, of
> course)
Cool. Be sure to deal with the license stuff on beforehand.
> 2) Start collaborating with the Wings project on a common XML schema
> for charts, hence letting the user choose which transformer suits
> him/her best (provided, of course, Wings committers agree)
Excellent. Tom will be happy to hear that!
> 3) Setup a new Cocoon-GIS sub-project in CocoonDev (yes, yes, I'll
> ask CocoonDev board first)
>
> 4) Donate, to the prospective Cocoon-GIS project (see 3), a
> transformer to connect Cocoon with ArcIMS, a proprietary web-mapping
> package
Given my recent private enquiry, and some Apachians playing with the
idea of mapping committer's geographic locations, that would be a nice
toy project as a sampler.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, Jan 30, 2003, at 15:18 Europe/London, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> Thanks everybody for their patience on this.
>
> I think we all learned a great deal out of it.
+1
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> Thanks everybody for their patience on this.
I think we all learned a great deal out of it.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Stefano Mazzocchi <st...@apache.org>.
Luca Morandini wrote:
>>-----Original Message-----
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>Sent: Wednesday, January 29, 2003 3:40 PM
>>To: cocoon-dev@xml.apache.org
>>Subject: Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a
>>commiter!]
>
>
>>You had a wonderful chance to accept Nicola's mistakes, appreciate his
>>regrets and earn a bunch of community respect by doing so.
>>Instead, you have choosen to keep beating somebody that admitted his
>>faults and in such a rude and personal way, with the chance of further
>>spreading negative energy and thus pollute the entire community with a
>>potential flamewar.
>>
>
>
> You're right, I acted recklessly, while at 37 I should have been wiser.
>
> Moreover, I needlessy damaged the community in doing so.
>
> To add insult to injury, I sent the notorious message without consulting Piero De Nicola, hence, indirectly damaging that innocent
> man as well.
>
> I should have been much wiser than that... indeed Nirvana is ahead of me :(
>
> Since I hold the view that apologies aren't enough, I will try to repair the damage I've done:
>
> 1) Bring the JFreeChartTransformer (aka ChartTransformer) under the aegis of CocoonDev... (provided CocoonDev board accepts it, of
> course)
>
> 2) Start collaborating with the Wings project on a common XML schema for charts, hence letting the user choose which transformer
> suits him/her best (provided, of course, Wings committers agree)
>
> 3) Setup a new Cocoon-GIS sub-project in CocoonDev (yes, yes, I'll ask CocoonDev board first)
>
> 4) Donate, to the prospective Cocoon-GIS project (see 3), a transformer to connect Cocoon with ArcIMS, a proprietary web-mapping
> package
>
> Do you deem it enough to put the relationship back on course ?
Of course!
But even the first line alone would have done it.
Now that the friction is over, let me talk to you about donations:
1) the LGPL issue is a serious concern in apache-land. while you can
disagree with the idea and the social impact, there is nothing *I* can
do to change this, the inertia of the concept is *way* more than I can
handle.
2) cocoon is too big. we need to factor things out. we need blocks for
that. blocks are hard to implement and we must get them incrementally
right (see my next mail)
3) code donations will be welcome, even if they duplicate functionality,
but only if they are 'helpful' for the community... we might decide to
'route' them somewhere else ('sourceforge' 'cocoondev' 'krysalis'
you-name-it) before incorporating them into something released from
cocoon.apache.org. This should *NOT* be considered offensive, but a way
to protect the community from potentially negative impact (like that one
we just experienced)
4) the cocoon PMC will work a politically fair solution for block
donation and distribution once the block technology will be in place,
this will take a while, though.
5) the line between block and non-block will be thin and easy to cross.
Please, don't get upset if you think others have been treated
differently, for sure, there is no reason to behave 'coldly' to a code
donation on purpose. At the same time, I'll work hard to make sure that
no code ownership and ego problems get in our way.
Hope this solves the issue.
Thanks everybody for their patience on this.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, January 29, 2003 3:40 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a
> commiter!]
> You had a wonderful chance to accept Nicola's mistakes, appreciate his
> regrets and earn a bunch of community respect by doing so.
> Instead, you have choosen to keep beating somebody that admitted his
> faults and in such a rude and personal way, with the chance of further
> spreading negative energy and thus pollute the entire community with a
> potential flamewar.
>
You're right, I acted recklessly, while at 37 I should have been wiser.
Moreover, I needlessy damaged the community in doing so.
To add insult to injury, I sent the notorious message without consulting Piero De Nicola, hence, indirectly damaging that innocent
man as well.
I should have been much wiser than that... indeed Nirvana is ahead of me :(
Since I hold the view that apologies aren't enough, I will try to repair the damage I've done:
1) Bring the JFreeChartTransformer (aka ChartTransformer) under the aegis of CocoonDev... (provided CocoonDev board accepts it, of
course)
2) Start collaborating with the Wings project on a common XML schema for charts, hence letting the user choose which transformer
suits him/her best (provided, of course, Wings committers agree)
3) Setup a new Cocoon-GIS sub-project in CocoonDev (yes, yes, I'll ask CocoonDev board first)
4) Donate, to the prospective Cocoon-GIS project (see 3), a transformer to connect Cocoon with ArcIMS, a proprietary web-mapping
package
Do you deem it enough to put the relationship back on course ?
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Stefano Mazzocchi <st...@apache.org>.
Luca Morandini wrote:
>>Stefano Mazzocchi wrote:
>>
>>>Nicola, you crossed the line.
>>
>>Sorry :-/
>>
>>Luca and all cocoon-dev, please accept my sincere apologies.
>>
>
> "The evil that men do lives after them; the good that men do is often interred with their bones."
>
> --Shakespeare, Julius Caesar.
>
> Which, in less theatrical a manner, means: it is not the first time you regret something you did within the OSS community... but
> apologies won't make those deeds go away.
Wrong. Learning is the process of making mistakes and recognizing them.
Pretending there is only one possibility to fail and to recover is
foolish and pretentious.
> I don't know you, and I don't usually give psychologic advice to strangers, but, let me tell you just one thing: it is probably time
> to re-focus yourself in what you do best, and leave the rest to other people.
You had a wonderful chance to accept Nicola's mistakes, appreciate his
regrets and earn a bunch of community respect by doing so.
Instead, you have choosen to keep beating somebody that admitted his
faults and in such a rude and personal way, with the chance of further
spreading negative energy and thus pollute the entire community with a
potential flamewar.
I'm pretty sure I'm not the only one on this list who now believes that
this 'faux-pax' of yours is much worse than the one Nicola made.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, January 28, 2003 8:44 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a
> commiter!]
>
>
>
> Stefano Mazzocchi wrote:
>
> > Nicola, you crossed the line.
>
> Sorry :-/
>
> Luca and all cocoon-dev, please accept my sincere apologies.
>
"The evil that men do lives after them; the good that men do is often interred with their bones."
--Shakespeare, Julius Caesar.
Which, in less theatrical a manner, means: it is not the first time you regret something you did within the OSS community... but
apologies won't make those deeds go away.
I don't know you, and I don't usually give psychologic advice to strangers, but, let me tell you just one thing: it is probably time
to re-focus yourself in what you do best, and leave the rest to other people.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> Nicola, you crossed the line.
Sorry :-/
Luca and all cocoon-dev, please accept my sincere apologies.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Jeff Turner <je...@apache.org>.
On Mon, Jan 27, 2003 at 11:47:03AM +0100, Stefano Mazzocchi wrote:
<snip>
> Yes, I'm pissed.
No-one's perfect. There's few better examples of
screw-up/apologise/move-on committers than Nicola.
--Jeff
(who frequently screws up)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Personal Attacks [was Re: ChartTransformer 0.0.4 urge a commiter!]
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Torsten Curdt wrote:
>
>>> I thought contributing to Cocoon to be easier... much easier :(
>
>
> I have put much time and effort in trying to make a charting solution.
> I think it's bad that he is not willing at all to collaborate. He says
> he wants "his" code in cocoon.
>
> Wings was based on my code. Then Keiron Liddle donated his stuff and we
> switched. Then JCharts became APL compatible and we switched again.
> Now this guy comes up *totally irrespective* of anything that has
> happened. Look at the class. It loads tags from xml and feeds them in
> JFreeChart. And he cannot integrate with Wings. It's ridiculous.
>
> He is not willing to collaborate in any way, and I don't like it.
>
> As for LGPL, it's really something we should not put in our CVS.
>
> Finally look at the patches in bugzilla. Their authors should be the
> ones saying the above.
Nicola, you crossed the line.
You are generating waves of negative emotions on this list due to code
ownership. I cannot believe this is happening again.
From where I stand, Luca (and others) had a problem for their
customers, solved it in the way they found better then decided that to
say something about it here. Somebody else proposed it for inclusion in CVS.
Then, later, Luca was also honest enough to admit his ego would be proud
of having some of his code into the codebase.
Tell me: wasn't this *exactly* the same thing that made you stick around
in the first place?
Software is *NOT* important around here, do you get it?
Human relationships are. Ask yourself if your comments made this
relationship any better.
From here, with this childlish comment of yours you:
- pissed Luca, deteriorating a possible relationship with him and his
colleagues
- worry other people, that might not want to donate their code because
fearing of such treatment themselves.
- lowered the overall respect others have in you
- reduced the chance of collaboration with the stuff you've written
I will *NOT* tollerate any further stupid personal attack on this list.
You have a ego problem? go over it or leave. I've said so on avalon-dev
I'm saying the same here.
Note that this is true for *EVERYBODY*, myself included.
Moreover, I'm *very* concerned about the fact that this comment doesn't
come from a newbie but from a vice-president of the foundation. Nicola
is the avalon chair and Avalon suffers from these problems. Don't make
me think there is a connection between the two.
Yes, I'm pissed.
And yes, I've used my two-email pattern, (you should have read the other
one)
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
Nicola,
now, I'm starting to take it personally.
> I think it's bad that he is not willing at all to collaborate.
I tried to collaborate some months ago, but I've found Wings not to be not mature enough as a base: and you know that. You may think
the opposite, but I carefully evaluated your solution.
> He says he wants "his" code in cocoon.
I never said that, I said:
"Well, in all fairness, I'd like "my" package to enter into the standard Cocoon distro... partly because I need to feed my ego (the
Nirvana is still ahead of me ;) ), partly because I think that it could be a good selling point for Cocoon."
This was intended to lighten up the discussion and make it more feely: I wrong was I :(
> Now this guy comes up *totally irrespective* of anything that has
> happened.
See above.
> Look at the class. It loads tags from xml and feeds them in
> JFreeChart. And he cannot integrate with Wings. It's ridiculous.
Well, I don't know why you deem it ridicolous, but, as a matter of fact, I think charting to be an easy thing, to be done,
possibily, with ONE class.
Think of it as just a plumbing, an adapter to something doing the real work (in this case JFreeChart).
> He is not willing to collaborate in any way, and I don't like it.
I wrote:
"Moreover:
1) It could remain in a JAR by itself, or in a block
2) We could propose changes to it under the supervision of a committer, which would be officially in charge of it
3) We could create mock classes in order to avoid breaking the build in case JFreeChart is not there
4) We could make IPZS officially donate it to ASF"
Does this mean that "I don't want to collaborate in any way" ? I don't think so.
> As for LGPL, it's really something we should not put in our CVS.
I agree. But you don't need to. Just like you don't need to have an Oracle license to be able to bind to their JDBC driver.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Sunday, January 26, 2003 4:01 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
>
> Torsten Curdt wrote:
> >> I thought contributing to Cocoon to be easier... much easier :(
>
> I have put much time and effort in trying to make a charting solution.
> I think it's bad that he is not willing at all to collaborate. He says
> he wants "his" code in cocoon.
>
> Wings was based on my code. Then Keiron Liddle donated his stuff and we
> switched. Then JCharts became APL compatible and we switched again.
> Now this guy comes up *totally irrespective* of anything that has
> happened. Look at the class. It loads tags from xml and feeds them in
> JFreeChart. And he cannot integrate with Wings. It's ridiculous.
>
> He is not willing to collaborate in any way, and I don't like it.
>
> As for LGPL, it's really something we should not put in our CVS.
>
> Finally look at the patches in bugzilla. Their authors should be the
> ones saying the above.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Torsten Curdt wrote:
>> I thought contributing to Cocoon to be easier... much easier :(
I have put much time and effort in trying to make a charting solution.
I think it's bad that he is not willing at all to collaborate. He says
he wants "his" code in cocoon.
Wings was based on my code. Then Keiron Liddle donated his stuff and we
switched. Then JCharts became APL compatible and we switched again.
Now this guy comes up *totally irrespective* of anything that has
happened. Look at the class. It loads tags from xml and feeds them in
JFreeChart. And he cannot integrate with Wings. It's ridiculous.
He is not willing to collaborate in any way, and I don't like it.
As for LGPL, it's really something we should not put in our CVS.
Finally look at the patches in bugzilla. Their authors should be the
ones saying the above.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Jeff Turner wrote:
>
> Not at Apache, but is there anything stopping a few developers forking
> the last LGPL'ed version on Sourceforge?
Nope, not AFAIK...
> If so, then using LGPL code could be an acceptable risk. The
> alternatives (rewrite, or convince the world to adopt BSD/ASL) aren't fun
> at all..
Maybe from your point of view, from mine (and don't take it personally,
please, it's just an example) there's no difference between Jeff Turner
of the Cocoon fame and Mark Matthews of the MySQL-MM JDBC driver...
I had some chats in the past with Mark, and he understood our vision and
why whe used the BSD/ASL instead of GPL/LGPL, but look at how version
3.0 of his codebase is now distributed! :-)
IIRC (long time have passed) at that time we were even "in the talks"
for bringing the driver under Jakarta...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Jan 26, 2003 at 07:58:28PM +0000, Pier Fumagalli wrote:
> Nicola Ken Barozzi wrote:
> >Steven Noels wrote:
> >>Nicola Ken Barozzi wrote:
> >>
> >>>I'm not going to put another jar in our dependencies that is LGPL also.
> >>
> >>You are not _allowed_ to do so.
> >
> >Actually, we can. It depends on whom you ask ;-)
>
> Both wrong? :-) :-)
>
> Ok, let me try to explain the rationale behind GPL/LGPL for inclusion in
> the ASF codebases.
>
> I believe that everyone will know why GPL is "no-no" for us: it's a
> "viral" license, every modification to some GPL code, and everything
> linked against some GPL code _needs_ to be re-released as GPL.
>
> Now, the folks at GNU one day, seeing the drawbacks imposed by this
> licensing scheme (not many wanted to release software using a GPL
> licensed library) decided to come out with a "Lesser" GPL (LGPL).
>
> LPGL has one small caveat in it: you can LINK against that library and
> not be forced to re-release your code as GPL (however, if you modify the
> library itself, your modifications will have to be licensed under LGPL
> again, it is still "viral" on that part).
>
> Legally there is nothing preventing us (Apache) to base some of our work
> on a LGPL licensed library, then, for real, you can link against, put it
> in CVS, do whatever you want.
Well that's interesting.
> But there is one tricky little detail:
>
> If (for example) we, the ASF, decided to get the library and make some
> modifications to it, or, scarier though, we _had_ to "fork" the library
> for our own needs (imagine, the orignal author changes from LGPL to
> something else, full GPL for example -as happened lately to the MySQL
> JDBC drivers- or even worse, decides the library will only be
> distributed as "commercial software"), then we would be utterly f***ed.
>
> Ethically the ASF does not develops software under a "viral" license,
> therefore, given the "partial virality" of LGPL, we wouldn't be able to
> "fork" and maintain such a library.
Not at Apache, but is there anything stopping a few developers forking
the last LGPL'ed version on Sourceforge?
If so, then using LGPL code could be an acceptable risk. The
alternatives (rewrite, or convince the world to adopt BSD/ASL) aren't fun
at all..
--Jeff
> We wouldn't even be able to change the license, all modifications would
> have to be LGPL, so, we either would have to rewrite the whole thing,
> or get rid of the offending bits and bobs...
>
> Soooo, I'd say, if you see the word GPL somewhere (with or without the
> leading L) my answer is usually no, because now or in the future it
> could/will create problems...
>
> My 2c...
>
> Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Luca Morandini wrote:
>
> I mean, Cocoon already has some components relying on non-ASL
> libraries (like the SAP ones or the JDBC drivers); had these
> libraries to change, ASF wouldn't be able to fork them, hence
> resorting to change the Cocoon components, which is what was
> to be avoided in the first place.
>
> This underlines, I fear, a more general problem: to make Cocoon
> more powerful it has to interface to as many software packages
> as possible, which means it will, in some ways, come to depend
> on them.
>
> As a long-time Cocoon user, I dare to say: the gain is worth the
> risk !
As an old Apache fart, I'd say nope... Look at HTTPd land, modules
relyng on something over which we have some kind of legal troubles with
are not included in the distro, not included in the "core", not on our
CVS... mod_auth_mysql, for example). I don't think they ever will...
> Getting back to the point: in the case of JFreeChartTransformer
> the idea would be to treat it like the SAP components: put the
> transformer in the codebase and leave the non-ASL library out.
>
> Does it sound too risky a strategy ?
This community should not rely on my only judgement to evaluate the
possible risks of a strategy... (I'm the one who put all those nasty
bugs two years ago, and you had to work for 2 years, in more than 30 to
get rid of them! :-) :-) :-)
And please note that already many raised the same issue with the SAPv3
components (I can't find them in CVS, so, I assume they're not going to
be "in" until those problems are solved)...
Steven said:
> If license issues do not allow these components to be added to ASF
> CVS, we could look and see whether they could be hosted at
> cocoondev.org (since yes, they would be a valuable addition to
> Cocoon).
And I share Sylvain's point here:
> we voted a cocoon-apps module to host Cocoon-related developments
> that don't belong to the core. And this ultra-specific component
> typically falls in this category.
Well, in the past, our fellow colleagues on HTTPd created
<http://modules.apache.org>. I believe that most people would prefer to
see a similar solution for Cocoon rather than adding, and adding, and
adding stuff to the main CVS tree. And indeed it would solve the
"legalities" as well, relegating the problem to the end user...
<ashamed>
AxKIT solved all this mess even before starting... They use CPAN, we
don't even have that... :-( :-( :-( :-(
</ashamed>
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Pier Fumagalli [mailto:pier@betaversion.org]
> Sent: Sunday, January 26, 2003 8:58 PM
> To: cocoon-dev@xml.apache.org
> Subject: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a
> commiter!)
> Soooo, I'd say, if you see the word GPL somewhere (with or without the
> leading L) my answer is usually no, because now or in the future it
> could/will create problems...
>
Pier,
your point is very clear and I cannot agree more... but it begs the question: does this precaution extend to libraries that are not
included in the codebase ?
I mean, Cocoon already has some components relying on non-ASL libraries (like the SAP ones or the JDBC drivers); had these libraries
to change, ASF wouldn't be able to fork them, hence resorting to change the Cocoon components, which is what was to be avoided in
the first place.
This underlines, I fear, a more general problem: to make Cocoon more powerful it has to interface to as many software packages as
possible, which means it will, in some ways, come to depend on them.
As a long-time Cocoon user, I dare to say: the gain is worth the risk !
Getting back to the point: in the case of JFreeChartTransformer the idea would be to treat it like the SAP components: put the
transformer in the codebase and leave the non-ASL library out.
Does it sound too risky a strategy ?
My 1.2c (after tax)
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Stefano Mazzocchi <st...@apache.org>.
Ovidiu Predescu wrote:
> Rewriting the code to conform to a license is a poor choice IMO.
Agreed and respected.
Although, there is a real problem: the LGPL says that you are forced to
put changes back into the LGPL license only if you modify the library,
but not the code that links to it.
Now, what is a java library?
The real issue with LGPL is with its imprecision: there potentially no
limit about where the 'gpl infection' can get thru in your code.
Personally, I don't want to give the FSF the possibility to come after
us because of that.
I designed the blocks concept also to get around legal problems because
the xGPL works with 'redistribution', not 'installation'.
You can even install a GPL cocoon block on top of Cocoon and as long as
we don't ship any of that inside Cocoon, we are fine and the user who
does is fine as well.
The block concept will work as a condom around GPL virality (yes, RMS, I
don't like your imposed freedom, I want 'metafreedom' the freedom to
choose my flavor of it and to dislike yours, thank you)
Today, even moch classes are unsafe sex for us, because moch classes
rewrite parts that are *included* in the library so they are part of the
library itself, so they have to be LGPL-ed.
At the end, do not worry, we are not trying to paint the world with
Apache licenses (like the FSF does) so we'll work to make it possible to
make the software interoperate.
But we need blocks for that and we need a serious avalon container for
that and we need a serious community around it... or we simply screw
them and build our own container.
oh well...
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a
commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
<note>
This discussion should be better if continued on community@apache.org.
I'm sending it here because of the last few lines pertinent to Cocoon
specifically.
Also, I'm not on community@apache.org, as I trust my peers over there to
do a great job and have not much time to contribute to the discussuin.
If you think it's appropriate, feel free to CC me as well...
</note>
"Ovidiu Predescu" <ov...@apache.org> wrote:
> Pier,
>
> On Sunday, Jan 26, 2003, at 11:58 US/Pacific, Pier Fumagalli wrote:
>
>> If (for example) we, the ASF, decided to get the library and make some
>> modifications to it, or, scarier though, we _had_ to "fork" the
>> library for our own needs (imagine, the orignal author changes from
>> LGPL to something else, full GPL for example -as happened lately to
>> the MySQL JDBC drivers- or even worse, decides the library will only
>> be distributed as "commercial software"), then we would be utterly
>> f***ed.
>
> Under the same logic, nothing prevents somebody to take any project
> from Apache and release it under their own commercial license, without
> releasing any source code at all for any change. The Apache Software
> License is of no use either in such a situation, since there is no
> provision that prevents such forks to happen.
That is correct. And we have several of those examples. Example prime being
IBM WebSphere, based entirely on Apache-HTTPd, re-stretched and re-wrote to
new extents, but distributed under a purely commercial license (or at least
that was at the beginning, I don't know if now they distribute it using the
IBM Public-Source License).
> I think the real issue is not the _license_, but the _copyright_. If
> you're the copyright holder, you can change the license at will or you
> can release the same code under different licenses. That's why a
> license change was possible in the case of MySQL's JDBC driver. It was
> not LGPL that was viral, it was the copyright holder.
Well, yes: indeed the copyright holder of any particular body of work is
allowed to change the license anytime, but, if you get back to our original
example (forking a LGPL-based library), to be able to change the library's
license, each single line of the library should have to be rewritten (with
copyright of each modified part assigned to the modifier).
Only at that point, when the copyright is entirely owned by the modifier
(and therefore every single line of code has been rewritten), the modifier
is allowed to change from LGPL.
> That's why Apache and FSF require their contributors to assign the copyrights
> to the respective foundations.
Indeed (and also for protection to each individual contributor, I want to
add). One of the ASF main tasks is also to LEGALLY PROTECT each individual
contributor... It's somewhere in our charter, but better outlined in the
Foundation FAQ: <http://www.apache.org/foundation/faq.html>
2.b) provide a means for individual volunteers to be sheltered from legal
suits directed at the Foundation's projects
In layman's terms, if you mess about, you won't be directly sued, the
foundation will (goes back to the discussion on the dues and rights of being
a committer to any project).
> [One nice thing about FSF is that once you
> transfer your copyright to them, they even give you the right to
> continue distributing your original code under a restrictive license.]
You are legally allowed to do that (if I was able to scavenge the three
classes of Cocoon 2 I wrote before posting them on CVS, I can still claim
them as "mine" and fork myself, hehehehe)...
Plus, the ASF doesn't "need" to do that... Our license says "go ahead and do
whatever you want" :-) That's the beauty of it... (or how I persolanny call
it, real "freedom", you're even free to change my license!)
>> Ethically the ASF does not develops software under a "viral" license,
>> therefore, given the "partial virality" of LGPL, we wouldn't be able
>> to "fork" and maintain such a library. We wouldn't even be able to
>> change the license, all modifications would have to be LGPL, so, we
>> either would have to rewrite the whole thing, or get rid of the
>> offending bits and bobs...
>
> This is FUD! What is the problem with your changes being LGPL? If what
> matters is the software continuing to be free software, it should be
> fine with you. The changes you make are copyrighted by you, so the
> original developer will not be able to take your improvements and
> release them under a commercial, more restrictive license without your
> consent.
Well, as you say "if what matters is the software continuing to be free
software".... You see, that doesn't matter for me... I do not care if the
software I wrote continues to be free or not :-) You want it? Get it, use
it, turn'n'twist it, and then sell it "Microsoft way" :-)
All I want is my ego to be satisfied (ASF license point #3, say that we
wrote it! :-) and be a part of a community that shares my concerns...
> Linux worked just fine on exactly these principles, using GPL, an even
> more restrictive license than LGPL. Sure you may not like that Linux is
> not copyrighted by your favorite foundation, but is that a good reason
> to rewrite the whole thing?
Well, ask Brian Behlendorf on why we are using FreeBSD on the Apache
infrastructure! :-) :-)
>> Soooo, I'd say, if you see the word GPL somewhere (with or without
>> the leading L) my answer is usually no, because now or in the future
>> it could/will create problems...
>
> I don't think LGPL is a problem. Informed commercial companies (big
> ones too) are routinely using LGPL code with no problems, even in
> commercial products, without encountering any legal issues. It's a
> shame open source developers stumble on such issues, rather than
> discussing the technical merits of the code and collaborating on
> software that solves the problem. Rewriting the code to conform to a
> license is a poor choice IMO.
I agree entirely, but it's not my fault if the GNU foundation wants to
LEGALLY enforce one vision over another (basically imposing their license to
all software they touch basically forever)...
I believe that one piece of software doesn't have to legally require its
"free" status. The power is only on the community: if the community is
strong enough, and focused on one vision of collaboration and cooperation,
then the software BY ITSELF will remain free because of its evolution.
Do you think that if someone forked Cocoon and went off doing its
"commercial thing" the "derivate" would have more success? Do you think that
if Cocoon was protected to be "always free" by its license it would be more
"effective"?
I don't think so... Cocoon is free, and will remain free, because of its
community.
Each one of you IS Cocoon, and you all TOGETHER are Cocoon. Cocoon is not a
code-base, Cocoon is not a license, Cocoon is this community, Cocoon is
Andy, Bernhard, Bertrand, Carsten, Christian, Dims, Geoff, Giacomo, Gianugo,
Ivelin, Jeff, Jeremy, Michael, Niclas, Nicola, Ovidiu, Stefano, Stephan,
Steven, Sylvain, Torsten, Vadim and all the others I forgot...
Without _THIS_ Cocoon, Cocoon 2.x would only be Stefano's initial idea, and
4 classes full of bugs I wrote back in 2000.
And you only realize this when you go away for some time and realize that
what you wrote is just a drop in an ocean of talented kids! :-) :-)
Power to the people, not to the lawyers! :-) :-) :-)
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Ovidiu Predescu <ov...@apache.org>.
Pier,
On Sunday, Jan 26, 2003, at 11:58 US/Pacific, Pier Fumagalli wrote:
> If (for example) we, the ASF, decided to get the library and make some
> modifications to it, or, scarier though, we _had_ to "fork" the
> library for our own needs (imagine, the orignal author changes from
> LGPL to something else, full GPL for example -as happened lately to
> the MySQL JDBC drivers- or even worse, decides the library will only
> be distributed as "commercial software"), then we would be utterly
> f***ed.
Under the same logic, nothing prevents somebody to take any project
from Apache and release it under their own commercial license, without
releasing any source code at all for any change. The Apache Software
License is of no use either in such a situation, since there is no
provision that prevents such forks to happen.
I think the real issue is not the _license_, but the _copyright_. If
you're the copyright holder, you can change the license at will or you
can release the same code under different licenses. That's why a
license change was possible in the case of MySQL's JDBC driver. It was
not LGPL that was viral, it was the copyright holder. That's why Apache
and FSF require their contributors to assign the copyrights to the
respective foundations. [One nice thing about FSF is that once you
transfer your copyright to them, they even give you the right to
continue distributing your original code under a restrictive license.]
> Ethically the ASF does not develops software under a "viral" license,
> therefore, given the "partial virality" of LGPL, we wouldn't be able
> to "fork" and maintain such a library. We wouldn't even be able to
> change the license, all modifications would have to be LGPL, so, we
> either would have to rewrite the whole thing, or get rid of the
> offending bits and bobs...
This is FUD! What is the problem with your changes being LGPL? If what
matters is the software continuing to be free software, it should be
fine with you. The changes you make are copyrighted by you, so the
original developer will not be able to take your improvements and
release them under a commercial, more restrictive license without your
consent.
Linux worked just fine on exactly these principles, using GPL, an even
more restrictive license than LGPL. Sure you may not like that Linux is
not copyrighted by your favorite foundation, but is that a good reason
to rewrite the whole thing?
> Soooo, I'd say, if you see the word GPL somewhere (with or without
> the leading L) my answer is usually no, because now or in the future
> it could/will create problems...
I don't think LGPL is a problem. Informed commercial companies (big
ones too) are routinely using LGPL code with no problems, even in
commercial products, without encountering any legal issues. It's a
shame open source developers stumble on such issues, rather than
discussing the technical merits of the code and collaborating on
software that solves the problem. Rewriting the code to conform to a
license is a poor choice IMO.
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.google.com/search?btnI=&q=ovidiu (I'm feeling lucky)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Why not LGPL? (Was: Re: ChartTransformer 0.0.4 urge a commiter!)
Posted by Pier Fumagalli <pi...@betaversion.org>.
Nicola Ken Barozzi wrote:
> Steven Noels wrote:
>> Nicola Ken Barozzi wrote:
>>
>>> I'm not going to put another jar in our dependencies that is LGPL also.
>>
>> You are not _allowed_ to do so.
>
> Actually, we can. It depends on whom you ask ;-)
Both wrong? :-) :-)
Ok, let me try to explain the rationale behind GPL/LGPL for inclusion in
the ASF codebases.
I believe that everyone will know why GPL is "no-no" for us: it's a
"viral" license, every modification to some GPL code, and everything
linked against some GPL code _needs_ to be re-released as GPL.
Now, the folks at GNU one day, seeing the drawbacks imposed by this
licensing scheme (not many wanted to release software using a GPL
licensed library) decided to come out with a "Lesser" GPL (LGPL).
LPGL has one small caveat in it: you can LINK against that library and
not be forced to re-release your code as GPL (however, if you modify the
library itself, your modifications will have to be licensed under LGPL
again, it is still "viral" on that part).
Legally there is nothing preventing us (Apache) to base some of our work
on a LGPL licensed library, then, for real, you can link against, put it
in CVS, do whatever you want. But there is one tricky little detail:
If (for example) we, the ASF, decided to get the library and make some
modifications to it, or, scarier though, we _had_ to "fork" the library
for our own needs (imagine, the orignal author changes from LGPL to
something else, full GPL for example -as happened lately to the MySQL
JDBC drivers- or even worse, decides the library will only be
distributed as "commercial software"), then we would be utterly f***ed.
Ethically the ASF does not develops software under a "viral" license,
therefore, given the "partial virality" of LGPL, we wouldn't be able to
"fork" and maintain such a library. We wouldn't even be able to change
the license, all modifications would have to be LGPL, so, we either
would have to rewrite the whole thing, or get rid of the offending bits
and bobs...
Soooo, I'd say, if you see the word GPL somewhere (with or without the
leading L) my answer is usually no, because now or in the future it
could/will create problems...
My 2c...
Pier
BTW, this whole argument about Charts is getting _so_ tedious! :-) :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
>> 1) make mock classes for JFreeChart. I'm not going to put another jar
>> in our dependencies that is LGPL also.
>
>
> You are not _allowed_ to do so.
Actually, we can. It depends on whom you ask ;-)
> Nobody asked for it, too.
Somebody asked that it be committed. These are just the basic requirements.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
(wrong quoting)
> Nicola Ken Barozzi wrote:
>
>> I'm not going to put another jar in our dependencies that is LGPL
>> also.
>
> You are not _allowed_ to do so. Nobody asked for it, too.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> 1) make mock classes for JFreeChart. I'm not going to put another jar in
> our dependencies that is LGPL also.
You are not _allowed_ to do so. Nobody asked for it, too.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
Nicola,
we'll be glad to make these changes, but I'd like a consensus to be built around the inclusion (or not) of JFreeChartTransformer
(aka ChartTransformer),
You and Steven think the it shouldn't be included, Torsten thinks it might be.
Since I deem open-source software to be a sort of democracy, I think more opinions are needed.
Regards,
P.S.
I've just seen your message about the moving of Wings to the scrachpad: may you wait until a consensus is built ?
We (me an Piero) can happily go to CocoonDev and wait the maturing of "our" transformer there: please, the community is more
important than the software... <joke>even "my" software</joke>
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Sunday, January 26, 2003 4:03 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
>
> I will commit the patch myself given the below points:
>
>
> 1) make mock classes for JFreeChart. I'm not going to put another jar in
> our dependencies that is LGPL also.
>
> 2) rename the transformer to JFreeChartTransformer
>
> 3) make a block called jfreechart
>
> 4) add an enrty to Bugzilla with [PATCH] in the description and a zip of
> the block
>
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I will commit the patch myself given the below points:
1) make mock classes for JFreeChart. I'm not going to put another jar in
our dependencies that is LGPL also.
2) rename the transformer to JFreeChartTransformer
3) make a block called jfreechart
4) add an enrty to Bugzilla with [PATCH] in the description and a zip of
the block
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Torsten Curdt wrote:
> I personally would really appreciate the offer - but dislike the
> urge. ...that's a matter of attitude. Although I bet it has been
> meant as offer.
It was Antonio who came up with the plea, and he already said it was
meant enticing or provocative, nothing more. Luca feels strong about his
own contribution, which is very human, and also because he tries to be a
good member of this community. Nothing less, nothing more.
The discussion then went off tangentially with my obsession about our
codebase collapsing under its own weight, but I'll refrain from making
any further comments on that since people call me 'bossy' when I do so.
Must be the effect of looking into the mirror and being confronted with
yourself. Ha.
I'm getting back into silent mode again:
http://blogs.cocoondev.org/stevenn/archives/000590.html
(oh Torsten, even though I pick your mail to reply on, this has nothing
to do with you)
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Sunday, January 26, 2003 6:43 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
> I personally would really appreciate the offer - but dislike the urge.
> ...that's a matter of attitude. Although I bet it has been meant as offer.
ahem... I didn't urge anyone, actually it was Antonio who started the thread.
My post to him read like:
<<Antonio,
thanks for your appreciation.
We'd like to insert it into the next release of Cocoon, but we're not committers :( moreover, JFreeChart is (L)PGL.>>
To which he replied by starting the thread with the "urge" in the subject line:
<<Hey commiters, what are you waiting for?
This is a very interesting stuff. Please, Hurry up! ;-D>>
> Do you really think there is no way merging the both - or do you think
> it's not worth the effort? Have you had a look into the latest wings
> stuff - not yet in CVS?
Ok, I'll investigate that, but the two approaches are really different.
BTW, has it to be charting-package agnostic ? That is the only solid reason to make it more complex that it needs to be.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Torsten Curdt <tc...@dff.st>.
I have no idea how much you guys realy tried to work things out before
starting the new transformer - so I am out on this.
Do you really think there is no way merging the both - or do you think
it's not worth the effort? Have you had a look into the latest wings
stuff - not yet in CVS?
All I can say is that if it's just a drop-off of a project you could
_offer_ it to the community but then there is no reason to _urge_
someone to include your code.
I personally would really appreciate the offer - but dislike the urge.
...that's a matter of attitude. Although I bet it has been meant as offer.
>>Anyway I am having the feeling this hot discussion somehow got into the
>>wrong direction - please don't let this "my code" story from avalon
>>happen here... *PLEASE*
>
>
> Got the message :( In all fairness, I must say I'm starting to take it personal...
...as long as you don't want to really have this "my code" attitude
there is nothing much to take personal on the above statement;)
>>Better let's start the discussion about a better build system which
>>downloads blocks as they are needed. So we don't have to carry those
>>thousand jar in our distribution and we are able to include
>>components/blocks from sources other than our CVS just by adding a URL.
>
> I agree completely.
excellent :)
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Sunday, January 26, 2003 3:51 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
> Although merging of both (if possible at all) would have been much
> better!!! With "rule my own" you cannot suddenly have the community
> behind you... especially if you create some kind of competition by that.
> I don't think such Darwinism is good for the community...
Yes, I agree, but I tried to use Wings well before the idea of donating this thing to Cocoon arised in me: I've found it to be not
up to the task (see [1]).
Moreover, I must repeat myself:
<<Yes, in an ideal world we'd happily code all together, but this being the real world, sometimes happens that you develop a piece
of
software for a specific customer and only after the customer's needs are met (in terms of time and features) you can think about
donating it.
This is especially true for a package like Cocoon, which is, first and foremost, the plumbing holding software components together
(the water being XML, of course).>>
AAMOF, I dislike re-inventing the wheel: it costed money to hire Piero on that project. But, again, Wings was not a viable option.
In a nutshell: Wings was not ready and it was too complex, since it is meant to be graphic-package-indipendent, which the customer
didn't see as a requirement (actually, I agree with the customer on this matter).
> Anyway I am having the feeling this hot discussion somehow got into the
> wrong direction - please don't let this "my code" story from avalon
> happen here... *PLEASE*
Got the message :( In all fairness, I must say I'm starting to take it personal...
> Better let's start the discussion about a better build system which
> downloads blocks as they are needed. So we don't have to carry those
> thousand jar in our distribution and we are able to include
> components/blocks from sources other than our CVS just by adding a URL.
I agree completely.
Regards,
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103538905118641&w=2
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> Although merging of both (if possible at all) would have been much
> better!!! With "rule my own" you cannot suddenly have the community
> behind you... especially if you create some kind of competition by that.
> I don't think such Darwinism is good for the community...
>
> Anyway I am having the feeling this hot discussion somehow got into the
> wrong direction - please don't let this "my code" story from avalon
> happen here... *PLEASE*
>
> Better let's start the discussion about a better build system which
> downloads blocks as they are needed. So we don't have to carry those
> thousand jar in our distribution and we are able to include
> components/blocks from sources other than our CVS just by adding a URL.
>
> my 2 cents
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Torsten Curdt <tc...@dff.st>.
> I thought contributing to Cocoon to be easier... much easier :(
Actually I feel a bit sorry about this... that's not very rewarding for
someone wanting to contribute some code! And it makes me wonder: what
are the objective reasons to include code into the codebase or not.
Even for the committers!
I always thought that a least the scratchpad should be used freely for
any addition. Of course this might fill up our codebase with dead code
...which is bad!!!!!! But why not saying: if something does not make it
from the scratchpad into the main trunk or has no changes within -let's
say- a year we drop it. Which is basically - "let's see how it develops..."
This rule might remove some stuff from the scratchpad. Probably the
current chart/wings transformer as well as "my" precept stuff. Whatever
- if people don't use it and I don't have the time to work on it...
I had just a very brief look into the chart transformer but to be
honest: just looking at the examples and the amount of documentation
that is currently available - I'd probably would go for the chart
transformer if I need it in a future project. For the project itself it
doesn't make a big difference whether it is LGPL or APL.
Although merging of both (if possible at all) would have been much
better!!! With "rule my own" you cannot suddenly have the community
behind you... especially if you create some kind of competition by that.
I don't think such Darwinism is good for the community...
Anyway I am having the feeling this hot discussion somehow got into the
wrong direction - please don't let this "my code" story from avalon
happen here... *PLEASE*
Better let's start the discussion about a better build system which
downloads blocks as they are needed. So we don't have to carry those
thousand jar in our distribution and we are able to include
components/blocks from sources other than our CVS just by adding a URL.
my 2 cents
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Stephan Michels <st...@apache.org>.
On Sat, 25 Jan 2003, Luca Morandini wrote:
> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@apache.org]
> > Sent: Saturday, January 25, 2003 8:58 PM
> > To: cocoon-dev
> > Subject: RE: ChartTransformer 0.0.4 urge a commiter!
> >
>
> > That reminds me with my discussion with Stefano etc. for year ago.
> >
> > http://marc.theaimsgroup.com/?l=xml-apache-general&m=101130268126515&w=2
> >
> > Luca, your ChartTransformer very intersting, and it will not be more
> > interesting, if it's part of the cocoon codebase.
> >
> > I have also written a DiagramSerializer(yes ;-) I'm not joking).
> > In the past I adding the Slide support and the chaperon parser components
> > to the Cocoon codebase. But time went by, and I think more and more
> > that blowing up the codebase wasn't a good way :-/
> > If I set up a new webapp, I must always remove parts, which I don't
> > need.
> >
> > We respect your good will! Try first cocoondev or sourceforge, believe me.
>
> Stephan,
>
> now I'm completely confused: you're saying you would like it to be in the Cocoon codebase, but Stefano's answer to you went in the
> direction of starting a subproject.
>
> As a matter of fact, I don't want to start a subproject I mean, it is just ONE class !
> I envisaged this as a simple thing, to be completed and donated as a matter of course.
For my opinion, it is not always the one transformer, it is more the
rat-tail, the dependency to JChart.
Have ever count number of libaries in WEB-INF/lib? No? There are in a
complete dist. 107! jar files. Okay, without the cocoon libs 80 files.
I'm guilty for 4 files :-/
<kidding>
The CVS HEAD is so big! How big is it? It is so big that
on my 2.4GHz Computer with 1GB ram the build took 4min 20sec.
</kidding>
So users got a OutOfMemoryException during the generation of the build.
If anyone ask me, I would move my stuff to cocoondev.
My 2cents, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Stephan Michels [mailto:stephan@apache.org]
> Sent: Saturday, January 25, 2003 8:58 PM
> To: cocoon-dev
> Subject: RE: ChartTransformer 0.0.4 urge a commiter!
>
> That reminds me with my discussion with Stefano etc. for year ago.
>
> http://marc.theaimsgroup.com/?l=xml-apache-general&m=101130268126515&w=2
>
> Luca, your ChartTransformer very intersting, and it will not be more
> interesting, if it's part of the cocoon codebase.
>
> I have also written a DiagramSerializer(yes ;-) I'm not joking).
> In the past I adding the Slide support and the chaperon parser components
> to the Cocoon codebase. But time went by, and I think more and more
> that blowing up the codebase wasn't a good way :-/
> If I set up a new webapp, I must always remove parts, which I don't
> need.
>
> We respect your good will! Try first cocoondev or sourceforge, believe me.
Stephan,
now I'm completely confused: you're saying you would like it to be in the Cocoon codebase, but Stefano's answer to you went in the
direction of starting a subproject.
As a matter of fact, I don't want to start a subproject I mean, it is just ONE class !
I envisaged this as a simple thing, to be completed and donated as a matter of course.
Moreover:
1) It could remain in a JAR by itself, or in a block
2) We could propose changes to it under the supervision of a committer, which would be officially in charge of it
3) We could create mock classes in order to avoid breaking the build in case JFreeChart is not there
4) We could make IPZS officially donate it to ASF
So, exactly, what's the problem ?
1) Is the license issue ?
2) Is that ChartTransformer is not mature enough ? Well, it may be, but I'd like some findings to subustantiate it.
3) Is not well-documented ? I beg to differ (grin).
4) Is because you don't want to get more stuff onboard with the 2.1 release approaching ? That I would understand... but, is that so
?
5) Is beacuse it comes out-of-the-blue, without discussing it first in the community ? Yes, but we hadn't any other option
6) Is something else ?
Regards,
P.S.
I thought contributing to Cocoon to be easier... much easier :(
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Stephan Michels <st...@apache.org>.
On Sat, 25 Jan 2003, Luca Morandini wrote:
> > -----Original Message-----
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > Sent: Saturday, January 25, 2003 8:06 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: ChartTransformer 0.0.4 urge a commiter!
> >
>
> > I've looked at the source code, and it's one class, and it's heavily
> > tied to JFreeChart. Wings is much more abstract in this regard. I don't
> > think that it will be easy to make it renderer-agnostic.
> >
>
> Yep. We tried to make it as simple as possible, which has meant binding it to JFreeChart.
>
>
> > Also, the fact that it's tied to a LGPL package is something I don't like.
>
> Yes, this opinion of yours is very clear.
>
>
> > The fact that you want to continue with adding many features to it makes
> > me think that you will need quite a lot of freedom too.
>
> No. It is just that we don't want to lose our momentum. Moreover, we'd like to add XY graphs to make it truly a charting solution.
>
>
> > I think you should set it up on cocoondev and chenge the license to APL
> > compatible, for all the reasons I said in my email
>
> ChartTransformer is already APL, only JFreeChart is not. Moreover, as Steven suggested, the codebase my be offically donated to
> Apache.
>
>
> > Fnally, if there is going to be *a* charting package, it should be
> > renderer agnostic. If not, they should have their own names (as FOP is
> > not FO, itext is not called PDF).
>
> I don't agree that it should neessarly be render-agnostic, since there is NO open-standard for charting.
> Conversely I agree on changing its name: JFreeChartTransformer would give the people developing JFreeChart their due :)
That reminds me with my discussion with Stefano etc. for year ago.
http://marc.theaimsgroup.com/?l=xml-apache-general&m=101130268126515&w=2
Luca, your ChartTransformer very intersting, and it will not be more
interesting, if it's part of the cocoon codebase.
I have also written a DiagramSerializer(yes ;-) I'm not joking).
In the past I adding the Slide support and the chaperon parser components
to the Cocoon codebase. But time went by, and I think more and more
that blowing up the codebase wasn't a good way :-/
If I set up a new webapp, I must always remove parts, which I don't
need.
We respect your good will! Try first cocoondev or sourceforge, believe me.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Saturday, January 25, 2003 8:06 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
> I've looked at the source code, and it's one class, and it's heavily
> tied to JFreeChart. Wings is much more abstract in this regard. I don't
> think that it will be easy to make it renderer-agnostic.
>
Yep. We tried to make it as simple as possible, which has meant binding it to JFreeChart.
> Also, the fact that it's tied to a LGPL package is something I don't like.
Yes, this opinion of yours is very clear.
> The fact that you want to continue with adding many features to it makes
> me think that you will need quite a lot of freedom too.
No. It is just that we don't want to lose our momentum. Moreover, we'd like to add XY graphs to make it truly a charting solution.
> I think you should set it up on cocoondev and chenge the license to APL
> compatible, for all the reasons I said in my email
ChartTransformer is already APL, only JFreeChart is not. Moreover, as Steven suggested, the codebase my be offically donated to
Apache.
> Fnally, if there is going to be *a* charting package, it should be
> renderer agnostic. If not, they should have their own names (as FOP is
> not FO, itext is not called PDF).
I don't agree that it should neessarly be render-agnostic, since there is NO open-standard for charting.
Conversely I agree on changing its name: JFreeChartTransformer would give the people developing JFreeChart their due :)
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Luca Morandini wrote:
[...]
> what to do about ChartTransformer ?
>
> Plese, take into account that we're going to add more features to it (see the todo list) and they will be developed with only
> JFreeChart in mind
I've looked at the source code, and it's one class, and it's heavily
tied to JFreeChart. Wings is much more abstract in this regard. I don't
think that it will be easy to make it renderer-agnostic.
Also, the fact that it's tied to a LGPL package is something I don't like.
The fact that you want to continue with adding many features to it makes
me think that you will need quite a lot of freedom too.
I think you should set it up on cocoondev and chenge the license to APL
compatible, for all the reasons I said in my email. IMHO cocoonapps is a
dead horse ATM, and since we could move cocoon to cocoondev HW, it would
be the same (still have decide it though).
This is *M*HO, I'm not a gatekeeper or a guardian.
But please, if someone wants to say his opinion, please take a look at
the two codebases, and make a reasoned comparison.
Fnally, if there is going to be *a* charting package, it should be
renderer agnostic. If not, they should have their own names (as FOP is
not FO, itext is not called PDF).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Saturday, January 25, 2003 6:49 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
> >> Well, in all fairness, I'd like "my" package to enter into the
> >> standard Cocoon distro...
>
> Once it's in the Cocoon distro it's not going to be *your* package
> anymore. I would surely add the features that I want to see that are in
> Wings now, and a merge will happen anyway. Don't assumed it will
> necessarily remain that way.
Nicola, I didn't make myself clear.
I just wanted to say that I like my software more than yours, just as I like my son more than anyone else's son. That's human I
presume. Period.
For the same reason, I like my software to grow, and I want other people to enjoy and enhance it.
If ChartTransfromer stayed the same in, say, two years from now, it would mean that it was useful to nobody, hence, I welcome your
(or anybody's) changes to it.
Having said that, what to do about ChartTransformer ?
Plese, take into account that we're going to add more features to it (see the todo list) and they will be developed with only
JFreeChart in mind... as I stated before, I think licensing is an issue that can be easily overcome.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Luca Morandini wrote:
>
>> Steven, this begs another question: what's should be inside Cocoon ?
[...]
> To me, a component/block has not only a 'separateable' implementation,
> which shows in the package naming and the fact it being a block, but
> also some 'principal caretaker', if I may say so in an open source
> project where all code belongs to the community.
So should Bugzilla, so should the site, so should the build... right?
More organization, this is too chaotic >:->
> A component should also
> have a separate release schedule/lifecycle (not in the Avalon sense),
> and would require a well-defined _release_ version of Cocoon. Take
> XMLForm as an example: it will only be 'released' when 2.1 is out. And
> new releases of it thereafter will remain dependent on the release cycle
> of Cocoon.
>
> OK, I'm not the coding wizard, but this is basically the _functional_
> reason of the existence of blocks in my perspective. But I fear that
> this vision behind blocks will never come true if we don't separate
> blocks physically from the Cocoon core. Blocks-people, correct me when
> my assumption is wrong.
Steven, probably you're dreaming. We don't have blocks (yet). We have
just separated code from the core and are trying to hack a block
implementation.
The day they will *effectively* be able to be compiled and added to
Cocoon in a complete separate fashion, I will want to see it too.
Probably you don't know how it works that much now.
>> Or, more to the point, should a chart-producing package be inserted
>> in the codebase ?
>
> Nope, but SAP connectivity blocks neither, and 5 different database
> access methods
> (http://outerthought.net/gettogether/original/Tortsen-orig.pdf) also,
> etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be
> Apache projects, even better Cocoon subprojects...? Yes, of course!
Kernel?
src/java/** == kernel
src/blocks/** != kernel
Do I see a time when cocoon.apache.org has a section where the blocks
have their own lifecycle, are detatched from core and the development
bubbles of activity?
Yes.
Is it possible *now*?
Nope.
>> A) If the answer is yes (as it is now), sooner or later a decision
>> should be made between Wings and ChartTransformer (supporting both
>> doesn't seem sensible to me ).
>
>
> See above, there might be room for n implementations, and the nature of
> open source is that the 'best' will survive. I advocate some garbage
> collection if some component becomes MIA.
Be careful here. I've seen a community shattered to pieces because they
used software darwinism as the only way of moving forward.
It breaks communities, makes egos grow, and doesn't make it possible for
the project to go forward.
One thing is having competing codebases based on technical differences,
one is competing people. Do you really think a charting block has such
different architectural needs that competition is needed? Come 'on...
Competition is a poor substitute of collaboration.
> So I don't see why two implementations of the same problem can't coexist
> in one repository, but I don't believed in 'forced' integration or
> merging, as a requirement before one of them being added. Not anymore:
> this community alchemy has been tried and tested before, and I don't
> think it works.
Tried and tested? Where?
The opposite was tries and tested. It's called Avalon (Excalibur(ECM,
Merlin, Fortress,...), Cornerstone, Phoenix, ...), and it was a
community failure.
> If Wings & ChartTransformer have a reason to integrate,
> that will eventually happen, but not because someone made it a
> requirement. It might happen only because of the intrinsic need to
> integrate (for technical or human reasons) both implementations. As it
> is now, these reasons apparently don't exist, and I have no problems
> with that.
I never said it has to be a requirement. If Cocoon is to have *a*
charting package, I'd like to see them integrated, and not see
JFreeChart used as a default implementation.
In the other case, the two can coexist, but it seems stupid to me. If we
cannot cooperate in a charting package... heck, it's ridiculous!
> I have a problem (and you will see me bringing this up on
> each opcoming addition) with the fact new stuff gets added to the core
> if it can be done equally well outside it, especially since we now have
> the possibility to address these things structurally, by establishing
> Cocoon subprojects and whatelse.
It's *not* the core. We *will* move blocks outside. Moving code away
without a community around == killing it.
So now it's impossible. Anyone wants to make blocks a reality *finally*?
Steven? >;->
>> B) If the answer is no, then delete Wings from the codebase and
>> insert in the doc that users can create charts with Cocoon by
>> downloading Wings and/or ChartTransformer from Krysalis and/or
>> CocoonDev.
>>
>> Well, in all fairness, I'd like "my" package to enter into the
>> standard Cocoon distro...
Once it's in the Cocoon distro it's not going to be *your* package
anymore. I would surely add the features that I want to see that are in
Wings now, and a merge will happen anyway. Don't assumed it will
necessarily remain that way.
>>partly because I need to feed my ego (the
>> Nirvana is still ahead of me ;) ), partly because I think that it
>> could be a good selling point for Cocoon.
>
> Yes, it is. And don't worry about that Nirvana thing: if
> ChartTransformer gets added to _a_ Apache Cocoon CVS repository, your
> help will be needed and the appropriate privs will be granted. And if
> your ego needs care: *big sloppy kiss* ;-)
Nice joke Steven, nice joke.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Luca Morandini wrote:
> Steven, this begs another question: what's should be inside Cocoon ?
http://dictionary.reference.com/search?q=panacea ;-)
I promised to start a Wiki page about that, but haven't come across some
copious free time yet. _My_ main problem in researching this is the
disjunction between package hierarchy and organizational decomposition.
I see many blocks right now, but no neat organizational decomposition.
To me, a component/block has not only a 'separateable' implementation,
which shows in the package naming and the fact it being a block, but
also some 'principal caretaker', if I may say so in an open source
project where all code belongs to the community. A component should also
have a separate release schedule/lifecycle (not in the Avalon sense),
and would require a well-defined _release_ version of Cocoon. Take
XMLForm as an example: it will only be 'released' when 2.1 is out. And
new releases of it thereafter will remain dependent on the release cycle
of Cocoon.
OK, I'm not the coding wizard, but this is basically the _functional_
reason of the existence of blocks in my perspective. But I fear that
this vision behind blocks will never come true if we don't separate
blocks physically from the Cocoon core. Blocks-people, correct me when
my assumption is wrong.
> Or, more to the point, should a chart-producing package be inserted
> in the codebase ?
Nope, but SAP connectivity blocks neither, and 5 different database
access methods
(http://outerthought.net/gettogether/original/Tortsen-orig.pdf) also,
etc etc etc...: _not_ in the Cocoon _kernel_. Should such things be
Apache projects, even better Cocoon subprojects...? Yes, of course!
> A) If the answer is yes (as it is now), sooner or later a decision
> should be made between Wings and ChartTransformer (supporting both
> doesn't seem sensible to me ).
See above, there might be room for n implementations, and the nature of
open source is that the 'best' will survive. I advocate some garbage
collection if some component becomes MIA.
So I don't see why two implementations of the same problem can't coexist
in one repository, but I don't believed in 'forced' integration or
merging, as a requirement before one of them being added. Not anymore:
this community alchemy has been tried and tested before, and I don't
think it works. If Wings & ChartTransformer have a reason to integrate,
that will eventually happen, but not because someone made it a
requirement. It might happen only because of the intrinsic need to
integrate (for technical or human reasons) both implementations. As it
is now, these reasons apparently don't exist, and I have no problems
with that. I have a problem (and you will see me bringing this up on
each opcoming addition) with the fact new stuff gets added to the core
if it can be done equally well outside it, especially since we now have
the possibility to address these things structurally, by establishing
Cocoon subprojects and whatelse.
> B) If the answer is no, then delete Wings from the codebase and
> insert in the doc that users can create charts with Cocoon by
> downloading Wings and/or ChartTransformer from Krysalis and/or
> CocoonDev.
>
> Well, in all fairness, I'd like "my" package to enter into the
> standard Cocoon distro... partly because I need to feed my ego (the
> Nirvana is still ahead of me ;) ), partly because I think that it
> could be a good selling point for Cocoon.
Yes, it is. And don't worry about that Nirvana thing: if
ChartTransformer gets added to _a_ Apache Cocoon CVS repository, your
help will be needed and the appropriate privs will be granted. And if
your ego needs care: *big sloppy kiss* ;-)
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Saturday, January 25, 2003 11:10 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
> Sure. If more people, and hopefully Tom and other Wings folks, become
> stewards of 'the' Cocoon charting codebase, we can commit either
> solution, or both, or one solution as we see fit. But as I said in the
> SAP R/3 case, this won't solve the problem of the corpulent codebase,
> and the issues with oversight that comes with its weight. Your efforts
> in blockifying stuff have already unearthed several issues, and I think
> we should actively try to keep the core codebase clean & healthy.
>
Steven, this begs another question: what's should be inside Cocoon ?
Or, more to the point, should a chart-producing package be inserted in the codebase ?
A) If the answer is yes (as it is now), sooner or later a decision should be made between Wings and ChartTransformer (supporting
both doesn't seem sensible to me ).
B) If the answer is no, then delete Wings from the codebase and insert in the doc that users can create charts with Cocoon by
downloading Wings and/or ChartTransformer from Krysalis and/or CocoonDev.
Well, in all fairness, I'd like "my" package to enter into the standard Cocoon distro... partly because I need to feed my ego (the
Nirvana is still ahead of me ;) ), partly because I think that it could be a good selling point for Cocoon.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Saturday, January 25, 2003 11:10 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
> Nicola Ken Barozzi wrote:
>
> > In Cocoon we already have a chart transformer, based on Krysalis Wings.
> > It has evolved, and now we use JCharts, that is APL compatible.
>
> Evolved? It requires some serious work, you mean. You are overselling
> Wings, Nicola. Wings has a committers base which is rather inactive, and
> the Cocoon stuff is quite poor feature-wise when compared to
> ChartTransformer.
>
> (don't start defending Wings or its committers base, I know Tom very
> well and I know he can cope with such a message - especially since we
> (xreporter) are one of the few who actually tried to put it to use)
>
> > Wings has the possibility of using different charting packages as
> > back-ends, and JFreechart too, but it ships with jCharts as default.
> >
> > I'd personally prefer that we use a completely APL-compatible system for
> > charting. Overmore Wings has been developed with separation of content
> > and syle in mind...
> >
> > Anyway, I really don't want to stop this, but I'd like that we decide
> > what we want to do.
> >
> > The fact is that putting something in Cocoon CVS makes it somewhat
> > "standard". If this solution had been there for some time, it would be a
> > sure bet, and can be inserted by name.
>
> It has been suggested before that ChartTransformer and Wings could
> cooperate, but due to time-to-market and technical issues, each group
> went its own way. So be it. Software Darwinism.
>
> From a Cocoon perspective, this is the nth example of my recurrent
> theme/worry that we are adding too much stuff to the core CVS. Or we
> should make more active use of the cocoon-apps module, or stuff should
> be moved to cocoondev.org. Either way I'm happy. Blocks ain't good
> enough, if the xml-cocoon2 repository keeps on growing in terms of size.
>
> I loath to see people creating stuff outside this community, but with
> the intent to have it moved into Cocoon afterwards. Sorry to say so, and
> please don't take this as a criticism. I think, given our new
> independence and responsability that comes with being being a toplevel
> project, we should worry about long-term oversight of Cocoon code (and
> don't be mad, Luca, it's with the best intentions). AAMOF, I proposed to
> Luca to move to cocoondev.org minutes after seeing his mail, so that we
> get a publicly accessible CVS repository.
>
> > In this case we have two different charting transformers, which to insert?
> >
> > IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that
> > this transformer be hosted on cocoondev so that it can grow.
> > And I'd like that we get to combine efforts, so that we can commit a
> > unified version to the Cocoon CVS.
>
> Sure. If more people, and hopefully Tom and other Wings folks, become
> stewards of 'the' Cocoon charting codebase, we can commit either
> solution, or both, or one solution as we see fit. But as I said in the
> SAP R/3 case, this won't solve the problem of the corpulent codebase,
> and the issues with oversight that comes with its weight. Your efforts
> in blockifying stuff have already unearthed several issues, and I think
> we should actively try to keep the core codebase clean & healthy.
>
> </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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> In Cocoon we already have a chart transformer, based on Krysalis Wings.
> It has evolved, and now we use JCharts, that is APL compatible.
Evolved? It requires some serious work, you mean. You are overselling
Wings, Nicola. Wings has a committers base which is rather inactive, and
the Cocoon stuff is quite poor feature-wise when compared to
ChartTransformer.
(don't start defending Wings or its committers base, I know Tom very
well and I know he can cope with such a message - especially since we
(xreporter) are one of the few who actually tried to put it to use)
> Wings has the possibility of using different charting packages as
> back-ends, and JFreechart too, but it ships with jCharts as default.
>
> I'd personally prefer that we use a completely APL-compatible system for
> charting. Overmore Wings has been developed with separation of content
> and syle in mind...
>
> Anyway, I really don't want to stop this, but I'd like that we decide
> what we want to do.
>
> The fact is that putting something in Cocoon CVS makes it somewhat
> "standard". If this solution had been there for some time, it would be a
> sure bet, and can be inserted by name.
It has been suggested before that ChartTransformer and Wings could
cooperate, but due to time-to-market and technical issues, each group
went its own way. So be it. Software Darwinism.
From a Cocoon perspective, this is the nth example of my recurrent
theme/worry that we are adding too much stuff to the core CVS. Or we
should make more active use of the cocoon-apps module, or stuff should
be moved to cocoondev.org. Either way I'm happy. Blocks ain't good
enough, if the xml-cocoon2 repository keeps on growing in terms of size.
I loath to see people creating stuff outside this community, but with
the intent to have it moved into Cocoon afterwards. Sorry to say so, and
please don't take this as a criticism. I think, given our new
independence and responsability that comes with being being a toplevel
project, we should worry about long-term oversight of Cocoon code (and
don't be mad, Luca, it's with the best intentions). AAMOF, I proposed to
Luca to move to cocoondev.org minutes after seeing his mail, so that we
get a publicly accessible CVS repository.
> In this case we have two different charting transformers, which to insert?
>
> IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that
> this transformer be hosted on cocoondev so that it can grow.
> And I'd like that we get to combine efforts, so that we can commit a
> unified version to the Cocoon CVS.
Sure. If more people, and hopefully Tom and other Wings folks, become
stewards of 'the' Cocoon charting codebase, we can commit either
solution, or both, or one solution as we see fit. But as I said in the
SAP R/3 case, this won't solve the problem of the corpulent codebase,
and the issues with oversight that comes with its weight. Your efforts
in blockifying stuff have already unearthed several issues, and I think
we should actively try to keep the core codebase clean & healthy.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
Nicola,
as you know, I evaluated the use of Wings and discarded it on purely technical considerations some months ago: probably things have
improved in the meantime.
We too had the separation of style and content in mind, actually, we have experimented the use of static style and dynamic data to
make charts in a real-world app.
I think the license objection could be easily overcome, since (L)GPL is not "viral" as GPL, and allows the embedding of libraries
into software products.
Anyway, I'd like to point out that this is not a race: I'm prepared to be hosted by Cocoondev until our transformer will mature and
only then choose which one will be best for Cocoon.
As a final remark, let me just tell you that I deem the inclusion of an easy-to-use and
well-documented chart package important for Cocoon now... not in a distant future.
Regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Saturday, January 25, 2003 12:19 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
>
> Luca Morandini wrote:
> > Steven,
> >
> > I'll arrange the donation in a few days :)
>
> In Cocoon we already have a chart transformer, based on Krysalis Wings.
> It has evolved, and now we use JCharts, that is APL compatible.
>
> Wings has the possibility of using different charting packages as
> back-ends, and JFreechart too, but it ships with jCharts as default.
>
> I'd personally prefer that we use a completely APL-compatible system for
> charting. Overmore Wings has been developed with separation of content
> and syle in mind...
>
> Anyway, I really don't want to stop this, but I'd like that we decide
> what we want to do.
>
> The fact is that putting something in Cocoon CVS makes it somewhat
> "standard". If this solution had been there for some time, it would be a
> sure bet, and can be inserted by name.
>
> In this case we have two different charting transformers, which to insert?
>
> IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that
> this transformer be hosted on cocoondev so that it can grow.
> And I'd like that we get to combine efforts, so that we can commit a
> unified version to the Cocoon CVS.
>
> What do you think?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Luca Morandini wrote:
> Steven,
>
> I'll arrange the donation in a few days :)
In Cocoon we already have a chart transformer, based on Krysalis Wings.
It has evolved, and now we use JCharts, that is APL compatible.
Wings has the possibility of using different charting packages as
back-ends, and JFreechart too, but it ships with jCharts as default.
I'd personally prefer that we use a completely APL-compatible system for
charting. Overmore Wings has been developed with separation of content
and syle in mind...
Anyway, I really don't want to stop this, but I'd like that we decide
what we want to do.
The fact is that putting something in Cocoon CVS makes it somewhat
"standard". If this solution had been there for some time, it would be a
sure bet, and can be inserted by name.
In this case we have two different charting transformers, which to insert?
IMHO the best thing at the moment, and I repeat ATM and IMVHO, is that
this transformer be hosted on cocoondev so that it can grow.
And I'd like that we get to combine efforts, so that we can commit a
unified version to the Cocoon CVS.
What do you think?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: ChartTransformer 0.0.4 urge a commiter!
Posted by Luca Morandini <lu...@tin.it>.
Steven,
I'll arrange the donation in a few days :)
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
lmorandini@ieee.org
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Friday, January 24, 2003 8:10 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: ChartTransformer 0.0.4 urge a commiter!
>
>
> Antonio Gallardo wrote:
>
> > Hey commiters, what are you waiting for?
> >
> > This is a very interesting stuff. Please, Hurry up! ;-D
> >
> > http://www.sidimar.ipzs.it/site/
>
> sorry Antonio, that code is copyrighted by IPZS S.p.A, not ASF. Don't
> expect this to be done unless this stuff is effectively donated to the
> ASF
> (http://incubator.apache.org/forms/ASF_Contributor_License_2_form.pdf)
> and the necessary workarounds are there to cope with JFreeCharts license.
>
> One would still need to download jfreechart separately from Cocoon since
> (L)GPL'ed code cannot reside in Apache CVS/dist.
>
> </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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ChartTransformer 0.0.4 urge a commiter!
Posted by Steven Noels <st...@outerthought.org>.
Antonio Gallardo wrote:
> Hey commiters, what are you waiting for?
>
> This is a very interesting stuff. Please, Hurry up! ;-D
>
> http://www.sidimar.ipzs.it/site/
sorry Antonio, that code is copyrighted by IPZS S.p.A, not ASF. Don't
expect this to be done unless this stuff is effectively donated to the
ASF
(http://incubator.apache.org/forms/ASF_Contributor_License_2_form.pdf)
and the necessary workarounds are there to cope with JFreeCharts license.
One would still need to download jfreechart separately from Cocoon since
(L)GPL'ed code cannot reside in Apache CVS/dist.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org