geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: Error when running maven
Date Fri, 12 Dec 2003 07:48:15 GMT

On Thursday, December 11, 2003, at 02:34 PM, gianny DAMOUR wrote:

> David Jencks wrote:
>> I have previously had very similar problems with xdoclet templates   
>> using xdoclet 1.2b2 and solved them only by upgrading the xdoclet   
>> version to a custom build (this is why JBoss ships with its own copy  
>> of  xdoclet).  This experience has led me to be extremely wary of   
>> customizing xdoclet, and provides a considerable amount of my   
>> motivation for wanting to eliminate xdoclet from the geronimo build.
> As a matter of fact, I did not hear you the first time and I learn the  
> hard way that XDoclet has some issues.

I haven't said very much about this. I have however been writing and  
recommending getGeronimoMBeanInfo methods rather than an xdoclet  
plugin:-)  I last experienced this problem about 9 months ago and had  
more or less forgotten about it.

Based on that experience I suspect if we could get a more or less  
current version of xdoclet in a maven repository the template would  
work.  However my last few attempts to build xdoclet have failed.
>
>> I've checked my copy of the xdoclet template, and it does not appear  
>> to suffer from the problem claimed in the stack trace.
>>
>> I suspect streams are not being read to the end in the mac jvm due to  
>> bugs in xdoclet.
> What surprise me is that a custom XDoclet template is been used  
> successfully to generate the standard MBean interfaces. However, this  
> template is outside a JAR.
>
> Hence, could you please make me a favour? As I do not have a Mac, I  
> can not reproduce this issue; however I would like to know if you can  
> override the templateFile of the geronimodoclet task in order to have  
> a template outside a JAR.

Do you know how to do this?  I tried changing the etc/maven.xml file  
geronimo doclet definition to

         <geronimodoclet destDir="${destdir}" verbose="false">
           <fileset dir="${srcdir}">
             <include name="**/*.java"/>
           </fileset>
           <mbeaninfo  
templateFile="${project.root}/etc/xdoclet/template/jmx/geronimo- 
mbeaninfo.xdt"/>
         </geronimodoclet>

(and putting a copy of the template there)
but the build is still using the copy from the jar:

Generating output for  
'org.apache.geronimo.tools.xdoclet.GeronimoDocletTaskTest' using  
template file  
'jar:file:/Users/david/.maven/repository/geronimo/jars/geronimo-tools- 
DEV.jar!/org/apache/geronimo/tools/xdoclet/resources/geronimo- 
mbeaninfo.xdt'.

>
> If it still does not work, I assume that I should fix what I have  
> checked in: I will remove this module.

I hope that won't be necessary.  Have you looked at xdoclet2 at all?  I  
have some hope that it will be more maintainable than xdoclet1.

Actually for xdoclet2 I think there is a serious danger that the jelly  
xml-generating scripts are impossible to modify or test.  I think the  
only maintainable system is something like this:

qdox turns your set of source code files into an object tree  
representing the javadoc.

There needs to be some sort of context object representing a position  
in this object tree.

start with a schema for the document you want to generate.

For each choice of multiplicity in the schema, annotate it with a query  
on the object tree, starting at the current context: this query returns  
a collection of objects.

For each bit of content, get the value from the context.

Since this is grammar-driven by the schema, the resulting document has  
to conform to the schema.

But, that's just my opinion, and I haven't figured out how to write  
something like this yet.

thanks
david jencks
>
> Sorry for these problems,
> Gianny
>
> _________________________________________________________________
> Trouvez l'âme soeur sur MSN Rencontres ! http://g.msn.fr/FR1000/9551
>


Mime
View raw message