[build system] - Fine grain inclusion of optional libs?

[Antonio Gallardo <ag...@agssa.net>]

Hi:

Currently, the optional libs always are copied to the resulted build.
Seems like it is the same as puting them in lib/core dir. That apporach is
not good at all. I would like to see an extension of the current Cocoon
build system that will check if every optional lib need to be included or
not.

WDYT?

Best Regards,

Antonio Gallardo

Re: [build system] - Fine grain inclusion of optional libs?

[Antonio Gallardo <ag...@agssa.net>]

Joerg Heinicke dijo:
> On 05.04.2004 02:41, Antonio Gallardo wrote:
>
>> Hi:
>>
>> Currently, the optional libs always are copied to the resulted build.
>> Seems like it is the same as puting them in lib/core dir. That apporach
>> is
>> not good at all. I would like to see an extension of the current Cocoon
>> build system that will check if every optional lib need to be included
>> or
>> not.
>>
>> WDYT?
>
> Based on what information? At the moment libs are added in dependency on
> selected blocks. The optional libs are in use in different blocks. So
> you either have to double them by putting one jar in block 1 and block
> 2, or only in block 1 and let depend block 2 on block 1 (which is
> completely painful as there is mostly no need for this
> inter-block-dependency), or put each optional jar in its own block and
> let the blocks needing this jar depend on the jar's block. Some optional
> jars are not even tight to any block, e.g. servlet.jar or pizza
> compiler, they are just optional (chosen environment, chosen compiler).
> Furthermore these are only 13 jars. IMO it's not worth any of the effort.

Since I am from the "old school" each byte is a worth to me. But, in this
case we are talking about 13 jars and this is a "lot" to me. Also, why we
need to choose and remove then manually when a the machine can do it for
us?

The information can be easily stored in the current lib.xml. AFAIK, there
is a very loosely information of what block use this jar <used-by/>. So we
can "format" this info and use it. Here a snip of a shared lib in current
lib.xml:

<file>
    <title>Jakarta Commons Logging</title>
    <description>The Logging package ...</description>
    <used-by>Jakarta Commons HttpClient, Chaperon</used-by>
    <lib>optional/commons-logging-1.0.3.jar</lib>
    <homepage>http://jakarta.apache.org/commons/logging.html</homepage>
  </file>

By defining a format for <used-by/> we can take advantage of them.

WDYT?

> BTW, jstyle.jar might be only be of interest for the xsp block, so it
> can possibly be moved to this block.

A big +1 if only XSP block use it! :-D

Best Regards,

Antonio Gallardo

Re: [QVote] remove JStyle

[Antonio Gallardo <ag...@agssa.net>]

gounis@osmosis.gr dijo:
>
>
> hi joerg
>
> sorry for the delay (i was out of the office)
> yes you have right, Jstyle is commented in all cocoon instances i use, but
> xsp/java generated code is nicely idented. So there is no objection from
> me.

Nice! So lets remove it! :-D

Best Regards,

Antonio Gallardo

Re: [QVote] remove JStyle

[go...@osmosis.gr]

hi joerg

sorry for the delay (i was out of the office)
yes you have right, Jstyle is commented in all cocoon instances i use, but 
xsp/java generated code is nicely idented. So there is no objection from 
me.

--stavros

On Wed, 7 Apr 2004, Joerg Heinicke wrote:

> > > > It does not provide much value - how many times have you looked into the 
> > > > generated XSP code? And how important for you was formatting of this 
> > > > generated code? I'm ok with keeping it, but, for myself, I have it 
> > > > disabled (and jstyle.jar removed).
> > > 
> > > So let's start a quick vote: If anybody has objections when removing 
> > > jstyle.jar, the JStyleFormatter and its conf, please comment.
> 
> <gounis <at> osmosis.gr> writes:
> 
> > i think that they are users (i'm one of those) that use to take a quick 
> > look at gennerated from xsp .java files. For me is the best way to debug 
> > this code.
> 
> Of course, but are you sure you have jstyle in use? Have a look into your
> cocoon.xconf and search for "JstyleFormatter". Is it activated or in comments?
> If it is activated, your objection will count of course and I will not remove it.
> 
> The generated Java code is most probably more or less nicely indented because it
> is already indented in the XSP.
> 
> Joerg
> 
> 

Re: [QVote] remove JStyle

[Joerg Heinicke <jo...@gmx.de>]

> > > It does not provide much value - how many times have you looked into the 
> > > generated XSP code? And how important for you was formatting of this 
> > > generated code? I'm ok with keeping it, but, for myself, I have it 
> > > disabled (and jstyle.jar removed).
> > 
> > So let's start a quick vote: If anybody has objections when removing 
> > jstyle.jar, the JStyleFormatter and its conf, please comment.

<gounis <at> osmosis.gr> writes:

> i think that they are users (i'm one of those) that use to take a quick 
> look at gennerated from xsp .java files. For me is the best way to debug 
> this code.

Of course, but are you sure you have jstyle in use? Have a look into your
cocoon.xconf and search for "JstyleFormatter". Is it activated or in comments?
If it is activated, your objection will count of course and I will not remove it.

The generated Java code is most probably more or less nicely indented because it
is already indented in the XSP.

Joerg

Re: [QVote] remove JStyle

[go...@osmosis.gr]

i think that they are users (i'm one of those) that use to take a quick 
look at gennerated from xsp .java files. For me is the best way to debug 
this code.

--stavros

On Tue, 6 Apr 2004, Joerg Heinicke wrote:

> On 06.04.2004 13:52, Vadim Gritsenko wrote:
> 
> > It does not provide much value - how many times have you looked into the 
> > generated XSP code? And how important for you was formatting of this 
> > generated code? I'm ok with keeping it, but, for myself, I have it 
> > disabled (and jstyle.jar removed).
> 
> I think so too, but I have never really used XSP. Only some tests for 
> some bugs. And there the code looked not that bad when you have it 
> already formatted in the XSP.
> 
> So let's start a quick vote: If anybody has objections when removing 
> jstyle.jar, the JStyleFormatter and its conf, please comment. IMO a 
> deprecation phase is not really needed as this feature was never (?), at 
> least since a long time not activated by default.
> 
> Joerg
> 

[QVote] remove JStyle

[Joerg Heinicke <jo...@gmx.de>]

On 06.04.2004 13:52, Vadim Gritsenko wrote:

> It does not provide much value - how many times have you looked into the 
> generated XSP code? And how important for you was formatting of this 
> generated code? I'm ok with keeping it, but, for myself, I have it 
> disabled (and jstyle.jar removed).

I think so too, but I have never really used XSP. Only some tests for 
some bugs. And there the code looked not that bad when you have it 
already formatted in the XSP.

So let's start a quick vote: If anybody has objections when removing 
jstyle.jar, the JStyleFormatter and its conf, please comment. IMO a 
deprecation phase is not really needed as this feature was never (?), at 
least since a long time not activated by default.

Joerg

Re: [build system] - Fine grain inclusion of optional libs?

[Vadim Gritsenko <va...@reverycodes.com>]

Joerg Heinicke wrote:

> On 05.04.2004 14:35, Vadim Gritsenko wrote:
>
>>> BTW, jstyle.jar might be only be of interest for the xsp block, so 
>>> it can possibly be moved to this block.
>>
>>
>> You can safely drop jstyle.
>
>
> What about
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/conf/xsp-program-language.xconf?annotate=1.2#24 
>
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/JstyleFormatter.java 
>
> ??
> Really simply remove it?


It does not provide much value - how many times have you looked into the 
generated XSP code? And how important for you was formatting of this 
generated code? I'm ok with keeping it, but, for myself, I have it 
disabled (and jstyle.jar removed).

Vadim

Re: [build system] - Fine grain inclusion of optional libs?

[Joerg Heinicke <jo...@gmx.de>]

On 05.04.2004 14:35, Vadim Gritsenko wrote:

>> BTW, jstyle.jar might be only be of interest for the xsp block, so it 
>> can possibly be moved to this block.
> 
> You can safely drop jstyle.

What about
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/conf/xsp-program-language.xconf?annotate=1.2#24
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/JstyleFormatter.java
??
Really simply remove it?

Joerg

Re: [build system] - Fine grain inclusion of optional libs?

[Vadim Gritsenko <va...@reverycodes.com>]

Joerg Heinicke wrote:

> On 05.04.2004 02:41, Antonio Gallardo wrote:
>
>> Hi:
>>
>> Currently, the optional libs always are copied to the resulted build.
>> Seems like it is the same as puting them in lib/core dir. That 
>> apporach is
>> not good at all. I would like to see an extension of the current Cocoon
>> build system that will check if every optional lib need to be 
>> included or
>> not.
>>
>> WDYT?
>
>
> Based on what information? At the moment libs are added in dependency 
> on selected blocks. The optional libs are in use in different blocks. 
> So you either have to double them by putting one jar in block 1 and 
> block 2, or only in block 1 and let depend block 2 on block 1 (which 
> is completely painful as there is mostly no need for this 
> inter-block-dependency), or put each optional jar in its own block and 
> let the blocks needing this jar depend on the jar's block. Some 
> optional jars are not even tight to any block, e.g. servlet.jar or 
> pizza compiler, they are just optional (chosen environment, chosen 
> compiler). Furthermore these are only 13 jars. IMO it's not worth any 
> of the effort.
>
> BTW, jstyle.jar might be only be of interest for the xsp block, so it 
> can possibly be moved to this block.


You can safely drop jstyle.

Vadim

Re: [build system] - Fine grain inclusion of optional libs?

[Joerg Heinicke <jo...@gmx.de>]

On 05.04.2004 02:41, Antonio Gallardo wrote:

> Hi:
> 
> Currently, the optional libs always are copied to the resulted build.
> Seems like it is the same as puting them in lib/core dir. That apporach is
> not good at all. I would like to see an extension of the current Cocoon
> build system that will check if every optional lib need to be included or
> not.
> 
> WDYT?

Based on what information? At the moment libs are added in dependency on 
selected blocks. The optional libs are in use in different blocks. So 
you either have to double them by putting one jar in block 1 and block 
2, or only in block 1 and let depend block 2 on block 1 (which is 
completely painful as there is mostly no need for this 
inter-block-dependency), or put each optional jar in its own block and 
let the blocks needing this jar depend on the jar's block. Some optional 
jars are not even tight to any block, e.g. servlet.jar or pizza 
compiler, they are just optional (chosen environment, chosen compiler). 
Furthermore these are only 13 jars. IMO it's not worth any of the effort.

BTW, jstyle.jar might be only be of interest for the xsp block, so it 
can possibly be moved to this block.

Joerg