Vadim Gritsenko wrote:

Unico Hommes wrote:

Vadim Gritsenko wrote:

Unico Hommes wrote:


I'd like to add the ability to use an excalibur DataSourceComponent as the ConnectionProvider for the QuartzJobScheduler's JobStore. However the solution I had in mind results in an additional dependency on the cocoon databases block. Not because of a compilation dependency on the source code of that block but on a jar in its lib directory. Am I correct in assuming that the policy on this is that I move the excalibur-datasource jar to lib/optional?




Just an idea; can we move ALL libraries to lib/optional, and copy them into the WEB-INF/lib on as-needed basis, i.e. if block included which needs a library, only then librariy is copied over? This should be possible using the info from gump.xml...


OK, I started working on this. Actually the changes to the build system were a breeze. The only difficulty I am currently having is with gump.xml because I am not very familiar with it. A lot of blocks project declarations have missing dependency information. In those cases I need to find out the project's gump name. How do I do that?


Another thing is that some external project names may not correspond to the name of the jar in our repository. Should I rename the jar in that case or is there a way to specify an alternative jar name in the descriptor?


I don't like renaming jars... Can we just extend gump.xml with the info we need? In this case, for a block, we need a list of jar files it requires from lib/optional.


The way I have it now is that for each <depend> I add an <include [EMAIL PROTECTED]/> to the <fileset> . We could add a library attribute that overides the project attribute. For instance:

<project name="cocoon-block-axis">
 <depend project="xml-axis" library="axis"/>

On the other hand, I think there are also cases (actually perhaps xml-axis it one) where one project delivers more than one jar. In that case perhaps library attribute must become a comma separated list. On second thought it may be better to create a <library> child element.

Thoughts?

--
Unico



Reply via email to