You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/12/23 17:44:13 UTC
[Proposal] reconsidering external libraries management
Hi team,
I've been using Eclipse for some months and it's now my preferred IDE.
However, creating a Cocoon project under Eclipse isn't a piece of cake :
all source files depending on optional libraries fail to compile,
preventing Eclipse to properly build the project.
So, following Nicola Ken's idea, I wrote mock classes for libraries that
aren't included in Cocoon's CVS. So far so good, the Cocoon Eclipse
project now builds smoothly. But this reveals something that I'm not
comfortable with, even if I have lived with it for years : the Cocoon
build system does not compile all source files, depending on which
libraries that are actually present in the classpath.
This has several consequences :
- some source files are never compiled (how many of you have
phpservlet.jar in their classpath ?)
- uncompiled source files aren't included in the binary distribution
(neither in the jar nor in the javadoc), and are therefore totally
hidden to average users
- worst of all : we may release an official version that contains files
that don't even compile !
So I propose that we _remove all the conditional compilation stuff_ and
write mock classes where needed to ensure that _all_ source files are
always compiled.
Note that mock classes don't prevent the use of the real libraries :
jars in lib/local are placed before the mock classes in the classpath
and are therefore used, if present, to compile the source code.
I have most of this ready on my hard drive, but since this is a change
in the way we handle external dependencies, I'd like to have your
opinion before committing anything.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] reconsidering external libraries management
Posted by Litrik De Roy <co...@litrik.com>.
Sylvain,
Is there any documentation on how to use/build Cocoon in Eclipse. I've
checked the mailing list archives and the Wiki but nothing there.
I managed to get the CVS of Cocoon in Eclipse, but I just can't get it to
compile. I get an error indicating that the javac compiler can't be found,
probably because JAVA_HOME isn't set. But how do I set this environment
variable in Eclipse? And, do I really need to set it?
Litrik De Roy
www.litrik.com
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Monday, December 23, 2002 5:44 PM
Subject: [Proposal] reconsidering external libraries management
> Hi team,
>
> I've been using Eclipse for some months and it's now my preferred IDE.
> However, creating a Cocoon project under Eclipse isn't a piece of cake :
> all source files depending on optional libraries fail to compile,
> preventing Eclipse to properly build the project.
>
> So, following Nicola Ken's idea, I wrote mock classes for libraries that
> aren't included in Cocoon's CVS. So far so good, the Cocoon Eclipse
> project now builds smoothly. But this reveals something that I'm not
> comfortable with, even if I have lived with it for years : the Cocoon
> build system does not compile all source files, depending on which
> libraries that are actually present in the classpath.
>
> This has several consequences :
> - some source files are never compiled (how many of you have
> phpservlet.jar in their classpath ?)
> - uncompiled source files aren't included in the binary distribution
> (neither in the jar nor in the javadoc), and are therefore totally
> hidden to average users
> - worst of all : we may release an official version that contains files
> that don't even compile !
>
> So I propose that we _remove all the conditional compilation stuff_ and
> write mock classes where needed to ensure that _all_ source files are
> always compiled.
>
> Note that mock classes don't prevent the use of the real libraries :
> jars in lib/local are placed before the mock classes in the classpath
> and are therefore used, if present, to compile the source code.
>
> I have most of this ready on my hard drive, but since this is a change
> in the way we handle external dependencies, I'd like to have your
> opinion before committing anything.
>
> Thoughts ?
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>
>
>
>
> ---------------------------------------------------------------------
> 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: [Proposal] reconsidering external libraries management
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Hi team,
>
> I've been using Eclipse for some months and it's now my preferred IDE.
> However, creating a Cocoon project under Eclipse isn't a piece of cake :
> all source files depending on optional libraries fail to compile,
> preventing Eclipse to properly build the project.
>
> So, following Nicola Ken's idea, I wrote mock classes for libraries that
> aren't included in Cocoon's CVS. So far so good, the Cocoon Eclipse
> project now builds smoothly. But this reveals something that I'm not
> comfortable with, even if I have lived with it for years : the Cocoon
> build system does not compile all source files, depending on which
> libraries that are actually present in the classpath.
>
> This has several consequences :
> - some source files are never compiled (how many of you have
> phpservlet.jar in their classpath ?)
> - uncompiled source files aren't included in the binary distribution
> (neither in the jar nor in the javadoc), and are therefore totally
> hidden to average users
> - worst of all : we may release an official version that contains files
> that don't even compile !
>
> So I propose that we _remove all the conditional compilation stuff_ and
> write mock classes where needed to ensure that _all_ source files are
> always compiled.
>
> Note that mock classes don't prevent the use of the real libraries :
> jars in lib/local are placed before the mock classes in the classpath
> and are therefore used, if present, to compile the source code.
>
> I have most of this ready on my hard drive, but since this is a change
> in the way we handle external dependencies, I'd like to have your
> opinion before committing anything.
>
> Thoughts ?
Having used Eclipse myself I know exactly your feeling but didn't have
your patience :)
But IDE aside, I think the concern of shipping code that doesn't even
compile is a good one so here is my +1 for turning *on* compilation for
everything... which will ensure at least more compile-time testing of
our code
(note: these problems will hopefully go away with blocks)
--
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: [Proposal] reconsidering external libraries management
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
> Sylvain Wallez wrote:
>
>>
>> I think I did the main part of the work : add mock classes where
>> needed and tweak the build to handle them. It's also working in the
>> 2.0 branch.
>>
>> The remaining work will be some cleanup in the build.xml files : I
>> admit I don't clearly understand all the details of block build :-/
>
>
> Ask, and it will be replied :-)
> If you put in the mocks, I will cleanup that file. So each does what
> he understands best :-)
Great. That's the OSS power ;-))
> Basically what it does is to get the dependencies from the
> project-info.xml file (the Gump descriptor), resolves dependencies,
> and builds the blocks one after the other, buy invoking the same build
> on each in turn.
>
> Try this: do a build and look in build/cocoon/work/blocks-build.xml
> That's the generated buildfile that compiles all the blocks.
Yeah, I've seen it. But it's not the most readable build file that I
know of ;-)
I need to dig deeper in this descriptor stuff and the associated XSL
(never took the time to do it).
>> One more proposal, also : what JDK are using Cocoon devs ? I
>> personally use 1.4, and so would like to make JDBC 3.0 methods
>> uncommented by default (so that the IDE is happy) and let the build
>> comment them out if needed.
>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] reconsidering external libraries management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>>
>> Sylvain Wallez wrote:
>>
>> [...]
>>
>>> So I propose that we _remove all the conditional compilation stuff_
>>> and write mock classes where needed to ensure that _all_ source files
>>> are always compiled.
>>
>> [...]
>>
>>>
>>> Thoughts ?
>>
>> I agree. +1
>>
>> In fact I added the mocks dir in the blocks to be able to set them
>> there. IMHO that's all that is should take, because all optional stuff
>> is to be in blocks, and in the near future in "/environment/**".
>> This means of course that we remove all conditional compileation as
>> you say.
>
> I also had to add a mocks directory in scratchpad and in src (needed for
> sun.tools.javac.Main, and JaxenProcessorImpl for which I didn't want to
> make a new block).
Ah, ok, gotcha.
>> What is needed in your opinion to make it fully? I can help you make
>> adjustments if necessary :-)
>
> I think I did the main part of the work : add mock classes where needed
> and tweak the build to handle them. It's also working in the 2.0 branch.
>
> The remaining work will be some cleanup in the build.xml files : I admit
> I don't clearly understand all the details of block build :-/
Ask, and it will be replied :-)
If you put in the mocks, I will cleanup that file. So each does what he
understands best :-)
Basically what it does is to get the dependencies from the
project-info.xml file (the Gump descriptor), resolves dependencies, and
builds the blocks one after the other, buy invoking the same build on
each in turn.
Try this: do a build and look in build/cocoon/work/blocks-build.xml
That's the generated buildfile that compiles all the blocks.
> One more proposal, also : what JDK are using Cocoon devs ? I personally
> use 1.4, and so would like to make JDBC 3.0 methods uncommented by
> default (so that the IDE is happy) and let the build comment them out if
> needed.
--
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: [Proposal] reconsidering external libraries management
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Sylvain Wallez wrote:
>
> [...]
>
>> So I propose that we _remove all the conditional compilation stuff_
>> and write mock classes where needed to ensure that _all_ source files
>> are always compiled.
>
>
> [...]
>
>>
>> Thoughts ?
>
>
> I agree. +1
>
> In fact I added the mocks dir in the blocks to be able to set them
> there. IMHO that's all that is should take, because all optional stuff
> is to be in blocks, and in the near future in "/environment/**".
> This means of course that we remove all conditional compileation as
> you say.
I also had to add a mocks directory in scratchpad and in src (needed for
sun.tools.javac.Main, and JaxenProcessorImpl for which I didn't want to
make a new block).
> What is needed in your opinion to make it fully? I can help you make
> adjustments if necessary :-)
I think I did the main part of the work : add mock classes where needed
and tweak the build to handle them. It's also working in the 2.0 branch.
The remaining work will be some cleanup in the build.xml files : I admit
I don't clearly understand all the details of block build :-/
One more proposal, also : what JDK are using Cocoon devs ? I personally
use 1.4, and so would like to make JDBC 3.0 methods uncommented by
default (so that the IDE is happy) and let the build comment them out if
needed.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] reconsidering external libraries management
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> John Morrison wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>> So I propose that we _remove all the conditional compilation stuff_
>>> and write mock classes where needed to ensure that _all_ source files
>>> are always compiled.
>>>
>>> Thoughts ?
>>>
>>
>>
>> +1 in general, my only missgivings are legal - where do we stand
>> creating 'mock' objects of somebody elses code that (I don't know
>> if this is a possibility) might be GPL (or other restricted licensing
>> agreement)?
>>
>>
>
> IANAL, but the mock classes are created without referring to the real
> classes. They just contain the declarations of methods actually used by
> our code, and are made abstract as far as possible.
>
> Only thoses classes that are instanciated by our code need to be
> concrete class, and the methods body is then just a "throw new
> UnsupportedOperationException("this is a mock object);"
>
> So it can be considered as a clean room reimplementation of a subset of
> the class public interface.
>
> Any lawyer out there ?
IANAL neither, but the ASF has a pretty strict internal practice to
*not* to distribute any GPL code whatsoever in whatever form to
explicitly avoid legal issues.
In fact, nobody can even agree on whether calling a GPL java library
using reflections and keeping method names in a configuration file can
be called 'binding' or not. And this is also true for an LGPL library.
I'm sure the FSF would say yes and the library user would say no. But
when RMS comes after you, that's where the fun stops.
In short, moch objects don't change the picture: the ASF doesn't
distribute *GPL java code nor connects to it. (luckily for us, there is
not much GPL java code out there... and it's easy to convince them to
dual-license if we really want to use it because the ASF is a much
bigger than than the FSF on java world)
--
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: [Proposal] reconsidering external libraries management
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
John Morrison wrote:
>Sylvain Wallez wrote:
>
>
>>So I propose that we _remove all the conditional compilation stuff_ and
>>write mock classes where needed to ensure that _all_ source files are
>>always compiled.
>>
>>Thoughts ?
>>
>>
>
>+1 in general, my only missgivings are legal - where do we stand
>creating 'mock' objects of somebody elses code that (I don't know
>if this is a possibility) might be GPL (or other restricted licensing
>agreement)?
>
>
IANAL, but the mock classes are created without referring to the real
classes. They just contain the declarations of methods actually used by
our code, and are made abstract as far as possible.
Only thoses classes that are instanciated by our code need to be
concrete class, and the methods body is then just a "throw new
UnsupportedOperationException("this is a mock object);"
So it can be considered as a clean room reimplementation of a subset of
the class public interface.
Any lawyer out there ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal] reconsidering external libraries management
Posted by John Morrison <jo...@ntlworld.com>.
Sylvain Wallez wrote:
> So I propose that we _remove all the conditional compilation stuff_ and
> write mock classes where needed to ensure that _all_ source files are
> always compiled.
>
> Thoughts ?
+1 in general, my only missgivings are legal - where do we stand
creating 'mock' objects of somebody elses code that (I don't know
if this is a possibility) might be GPL (or other restricted licensing
agreement)?
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal] reconsidering external libraries management
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
[...]
> So I propose that we _remove all the conditional compilation stuff_ and
> write mock classes where needed to ensure that _all_ source files are
> always compiled.
[...]
>
> Thoughts ?
I agree. +1
In fact I added the mocks dir in the blocks to be able to set them
there. IMHO that's all that is should take, because all optional stuff
is to be in blocks, and in the near future in "/environment/**".
This means of course that we remove all conditional compileation as you say.
What is needed in your opinion to make it fully? I can help you make
adjustments if necessary :-)
--
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