cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Velychko <v_pe...@ukr.net>
Subject [Solution]: cocoon build system
Date Fri, 18 Jul 2003 11:24:08 GMT
Hello Peter,

Friday, July 18, 2003, 2:03:02 PM, you wrote:

PV> Hello Stephan,

PV> Friday, July 18, 2003, 1:25:36 PM, you wrote:

PV> Another problem.
PV> My classes have the package name beginning not with "org.*"
PV> But building temporary file "blocks-build.xml" contains in the target
PV> <target ... name="fins-compile"> the following instruction:

PV>                 <jar jarfile="${build.blocks}/fins-block.jar">
PV>                         <fileset dir="${build.blocks}/fins/dest">
PV>                                 <include name="org/**"/>
PV>                                 <include name="META-INF/**"/>
PV>                         </fileset>
PV>                 </jar>
PV> where "fins" is the name of my block.
                
PV> So the resulting jar is empty.

To solve my problem I've changed the
[$COCOON_HOME]/tools/src/blocks-build.xsl.

I've added the following variable:
<xsl:variable name="block-package" select="translate(package, '.', '/')"/>

into
<xsl:template match="project">...</xsl:template>

and use
<include name="{$block-package}/**"/>
instead of
<include name="org/**"/>

in
<jar jarfile="{string('${build.blocks}')}/{$block-name}-block.jar">
    <fileset dir="{string('${build.blocks}')}/{$block-name}/dest">
        <include name="{$block-package}/**"/>
        <include name="META-INF/**"/>
    </fileset>
</jar>

My classes begin with "it.ipzs.charts.*" (it is for "fins" project at
http://www.cocoondev.org/) and the resulting jar
"cocoon-fins-block.jar" is ok.

>>> >> I han't found any means to add "third part" jars to
>>> >> {$my_block}.classpath for block sources compiling.
>>> >>
>>> >> Does the possibility exist?
>>>
>>> SM> local.build.properties:
>>> SM> validate.jars=false
>>>
>>> SM> Stephan.
>>>
>>> Thank you. That's really simple :-).
>>>
>>> What is the global reason to validate "jar"-libraries?

SM>> To validate name of the jars, and if there exist
SM>> a description from where the lib comes, where it is
SM>> used.

SM>> We have approximately 100 jars, this target helps to
SM>> get the overview.

>>> Also I added the new element "dependjar" for "project" into the
>>> "gump.xml" and changed "blocks-build.xsl" to process the added
>>> element and it work also.

SM>> Fine :)

SM>> Have fun, Stephan.


SM>> ---------------------------------------------------------------------
SM>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
SM>> For additional commands, e-mail: users-help@cocoon.apache.org

-- 
Best regards,
Peter Velychko                            
v_peter@ukr.net


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message