Are you using xdoclet from xdoclet cvs? Does it build jboss correctly? I
would like to upgrade the jboss copy soon and when an xdoclet version is
released.
I think there is also a plan to move jboss specific code from xdoclet to
jboss. There is already an xdoclet include file for mbeans.
Thanks for investigating these duplicate jar problems. Can you build jboss
ok using only the jars from thirdparty (having removed the duplicates from
tools/lib)?
thanks
david jencks
On 2002.06.02 20:44:14 -0400 Frederick N. Brier wrote:
> In attempting to use a modified xdoclet.jar local to a sub-project
> (jboss.net) so we could slowly develop new XDoclet templates and later
> submit them, I discovered that the "ant" shell script in ./tools/bin is
> generating a classpath that is including all of the .jar(s) in
> ./tools/lib. It was pre-empting path-wise, the path I was specifying in
> my
> build script.
>
> So even though there is all this code in all the build scripts specifying
>
> the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually
> getting used is in ./tools/lib. There are classes overlapping in
> ./thirdparty/apache/log4j/lib/log4j.jar and ./tools/lib/log4j-core.jar.
> In
> the jmx sub-project build.xml, sax2.jar and sax2-ext.jar, located in
> ./thirdparty/xml/sax/lib are used which have overlapping classes with
> crimson.jar in ./tools/lib. Further, there additional copies of
> crimson.jar, jaxp.jar, and xalan.jar in both ./tools/lib and
> ./thirdparty/sun/jaxp with different dates and sizes. These files are
> referenced in the top level build.xml.
>
> There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it
> doesn't seem to be used anywhere.
>
> If this really is a problem, several of us could be banging our head
> against the wall trying to solve a bug in an old .jar. Perhaps we should
>
> remove any .jar that appears in the thirdparty directory from
> ./tools/lib,
> and only keep Ant required files there. I would like the xdoclet .jars
> moved into the thirdparty. That way, as we develop new xdoclet templates
> for generating deployment descriptors and code generators, we can evolve
> them, before submitting them to be included in the XDoclet codebase.
> The
> relevant shell script was in ./tools/bin/ant:
>
> # add in the dependency .jar files
> DIRLIBS=${ANT_HOME}/lib/*.jar
> for i in ${DIRLIBS}
> do
> # if the directory is empty, then it will return the input string
> # this is stupid, so case for it
> if [ "$i" != "${DIRLIBS}" ] ; then
> if [ -z "$LOCALCLASSPATH" ] ; then
> LOCALCLASSPATH=$i
> else
> LOCALCLASSPATH="$i":$LOCALCLASSPATH
> fi
> fi
> done
>
>
>
> Frederick N. Brier
> Sr. Software Engineer
> Multideck Corporation
>
> <html>
> In attempting to use a modified xdoclet.jar local to a sub-project
> (jboss.net) so we could slowly develop new XDoclet templates and later
> submit them, I discovered that the "ant" shell script in
> ./tools/bin is generating a classpath that is including all of the
> .jar(s) in ./tools/lib. It was pre-empting path-wise, the path I
> was specifying in my build script.<br>
> <br>
> So even though there is all this code in all the build scripts specifying
> the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually
> getting used is in ./tools/lib. There are classes overlapping in
> ./thirdparty/apache/log4j/lib/log4j.jar and
> ./tools/lib/log4j-core.jar. In the jmx sub-project build.xml,
> sax2.jar and sax2-ext.jar, located in ./thirdparty/xml/sax/lib are used
> which have overlapping classes with crimson.jar in ./tools/lib.
> Further, there additional copies of crimson.jar, jaxp.jar, and xalan.jar
> in both ./tools/lib and ./thirdparty/sun/jaxp with different dates and
> sizes. These files are referenced in the top level build.xml.<br>
> <br>
> There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it
> doesn't seem to be used anywhere.<br>
> <br>
> If this really is a problem, several of us could be banging our head
> against the wall trying to solve a bug in an old .jar. Perhaps we
> should remove any .jar that appears in the thirdparty directory from
> ./tools/lib, and only keep Ant required files there. I would like
> the xdoclet .jars moved into the thirdparty. That way, as we develop new
> xdoclet templates for generating deployment descriptors and code
> generators, we can evolve them, before submitting them to be
> included in the XDoclet codebase. The relevant shell script was in
> ./tools/bin/ant:<br>
> <br>
> <font face="Courier, Courier"># add in the dependency .jar files<br>
> DIRLIBS=${ANT_HOME}/lib/*.jar<br>
> for i in ${DIRLIBS}<br>
> do<br>
> # if the directory is empty, then it will return the
> input string<br>
> # this is stupid, so case for it<br>
> if [ "$i" != "${DIRLIBS}" ] ;
> then<br>
> if [ -z "$LOCALCLASSPATH" ] ;
> then<br>
> LOCALCLASSPATH=$i<br>
> else<br>
>
> LOCALCLASSPATH="$i":$LOCALCLASSPATH<br>
> fi<br>
> fi<br>
> done<br>
> <br>
> </font><br>
> <br>
> <div>Frederick N. Brier</div>
> <div>Sr. Software Engineer</div>
> <div>Multideck Corporation</div>
> </html>
>
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
