INFO: Some classes refer to other classes that were not found among the sources or on the classpath.
(Perhaps the referred class doesn't exist? Hasn't been generated yet?)
The referring classes do not import any fully qualified classes matching these classes.
However, since no packages are imported, xjavadoc has assumed that the referred classes
belong to the same package as the referring class. The classes are:
D:\scm\src\com\icsaward\award\ConfigProperties.java --> Properties qualified to com.icsaward.award.Properties
Oh, I see now. The error says that the referring class does not import any fully qualified classes matching the Properties class. I have the import listed as follows in ConfigProperties:
import java.util.*;
It seems a little funny but I guess it's a little difficult knowing which wild card to resolve against if there were more than one that matched. But that's not a likely scenario as it is bad practice anyway. I dunno, it just feels wrong to me. I just wanted to bring it up in case anyone else has stumbled across this problem.
Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG 2101 Embassy Drive Lancaster, PA 17603
Phone: 717-295-7977 ext. 621
Fax: 717-295-7683
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Clifton C. Craig wrote:
I don't know what's going on with the mail system but I didn't see my 1st message in this thread come through. Anyhow, I'm taking the liberty to redesign the XJavadoc Ant stuff. I'm thinking now the the filter should be designed as something other than a fileset selector. There is an obvious conflict here. With my latest mods I have classes sneaking through that should not. It's hard to explain what's happening here but I can see the problem. The selection should maybe be done using a Predicate derived from a nested element and should work against the files but rather it should work against the individual classes that come through the getSourceClasses method. Chime in if you know what the devil I'm talking about (...because I don't). It's hard to believe that I just started with this technology the other day and I'm already in chest deep making what seems to me like a pretty involved but useful patch. I've never used the Jakarta commons stuff directly either but this project is forcing me to at least understand what a predicate is.
Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG 2101 Embassy Drive Lancaster, PA 17603
Phone: 717-295-7977 ext. 621 Fax: 717-295-7683 [EMAIL PROTECTED] [EMAIL PROTECTED]
Clifton C. Craig wrote:
This probably belongs on the developer list at this point. Just an update. I made a modification in the logic in the XJavaDocFilter object and it appears to be giving me what I expected. I just want to check and make sure there are no ramifications to this approach. Basically the idea is to restrict the evaluation of the implements and contains-tag parameters against only the root Java class of the .java file. One could argue that the contains tag parameter would miss inner classes and thus incorrectly evaluate some .java files that actually do contain certain tags. This is true but I believe it should be addressed by iterating over only the inner classes of the root class. The main problem in the original logic is that it was incorrectly rejecting classes that actually did meet the criteria by rejecting entire fileswhen it found a reference to a class from the file that did not meet the criteria. It appears to have been created from the mindset of fileset == classset. Please correct me where I am short sighted here.
My code is below: public boolean isSelected(File basedir, String filename, File file) throws BuildException {
if( !filename.endsWith( ".java" ) ) { log(filename + " does not end with .java."); return false; }
_xJavaDoc.reset( true ); log("considering " + filename); try { //validateOptions();
_xJavaDoc.addSourceSet( new FileSourceSet( basedir, new String[]{filename} ) );
String className = filename.substring(0,filename.length() - 5).replaceAll("\\/",".");
//Removed iterator over source classes as they include class files that are irrelevant to the selection.
// for( ClassIterator i = XCollections.classIterator( _xJavaDoc.getSourceClasses() ); i.hasNext(); )
// {
XClass clazz = _xJavaDoc.getXClass(className);
if(null==clazz) log(className + " not found in XJavadoc.");
// XClass clazz = i.next();
Parameter[] params = getParameters();
for( int j = 0; j < params.length; j++ ) { Parameter param = params[j];
if( param.getName().equals( "implements" ) ) { String mandatoryClass = param.getValue();
if( !clazz.isA( mandatoryClass ) )
{
log(clazz + " is not a " + mandatoryClass);
return false;
}
else
log(clazz + " does implement " + mandatoryClass);
}
else if( param.getName().equals( "contains-tag" ) )
{
String mandatoryTag = param.getValue();
if( !clazz.getDoc().hasTag( mandatoryTag ) )
{
log(clazz + " does not have tag " + mandatoryTag);
return false;
}
}
}
// }
}
catch( OutOfMemoryError e )
{
System.err.println( e.getMessage() );
XJavaDoc.printMemoryStatus();
System.err.println( "Try to increase heap size. Can be done by defining ANT_OPTS=-Xmx640m" );
System.err.println( "See the JDK tooldocs." );
throw new BuildException( e.getMessage(), e );
}
catch( Throwable t )
{
t.printStackTrace();
throw new BuildException( "Unexpected error", t );
}
finally
{
//XJavaDoc.printMemoryStatus();
_xJavaDoc.printLogMessages( System.out, XJavaDoc.NO_IMPORTED_PACKAGES );
_xJavaDoc.printLogMessages( System.out, XJavaDoc.ONE_OR_MORE_IMPORTED_PACKAGES );
_xJavaDoc.reset( true );
System.gc();
}
log(filename + " is selected.");
return true;
}
-------- Original Message -------- Subject: I like XJavadoc but... Date: Mon, 22 Mar 2004 11:51:45 -0500 From: Clifton C. Craig <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
The Ant tasks are giving me trouble. The XJavaDocFilter, for example looks like a cool way to filter for just the classes you need. However, it's forcing me to understand it's inner workings. It's not as simple as it seems. It apparently considers files that are referenced by the file given in its isSelected method. In my case, I have an Address session bean that somehow indirectly references a Tester inner class in a lockking object. I extended the filter so I can add some logging to see what was going on. This is my butchered re-implementation:
public boolean isSelected(File basedir, String filename, File file)
throws BuildException
{
if( !filename.endsWith( ".java" ) ) { log(filename + " does not end with .java."); return false; }
_xJavaDoc.reset( true ); log("considering " + filename); try { //validateOptions();
_xJavaDoc.addSourceSet( new FileSourceSet( basedir, new String[]{filename} ) );
for( ClassIterator i = XCollections.classIterator( _xJavaDoc.getSourceClasses() ); i.hasNext(); )
{
XClass clazz = i.next();
Parameter[] params = getParameters();
for( int j = 0; j < params.length; j++ ) { Parameter param = params[j];
if( param.getName().equals( "implements" ) ) { String mandatoryClass = param.getValue();
if( !clazz.isA( mandatoryClass ) )
{
log(clazz + " is not a " + mandatoryClass);
return false;
}
else
log(clazz + " does implement " + mandatoryClass);
}
else if( param.getName().equals( "contains-tag" ) )
{
String mandatoryTag = param.getValue();
if( !clazz.getDoc().hasTag( mandatoryTag ) )
{
log(clazz + " does not have tag " + mandatoryTag);
return false;
}
}
}
}
}
catch( OutOfMemoryError e )
{
System.err.println( e.getMessage() );
XJavaDoc.printMemoryStatus();
System.err.println( "Try to increase heap size. Can be done by defining ANT_OPTS=-Xmx640m" );
System.err.println( "See the JDK tooldocs." );
throw new BuildException( e.getMessage(), e );
}
catch( Throwable t )
{
t.printStackTrace();
throw new BuildException( "Unexpected error", t );
}
finally
{
//XJavaDoc.printMemoryStatus();
_xJavaDoc.printLogMessages( System.out, XJavaDoc.NO_IMPORTED_PACKAGES );
_xJavaDoc.printLogMessages( System.out, XJavaDoc.ONE_OR_MORE_IMPORTED_PACKAGES );
_xJavaDoc.reset( true );
System.gc();
}
log(filename + " is selected.");
return true;
}
Here's my build.xml:
<?xml version="1.0"?>
<project default="test" basedir="." name="Test">
<description>
This is a test script for experimental use.
</description>
<!-- =================================================================== -->
<!-- Basic build targets for the project -->
<!-- =================================================================== -->
<property name="project.base" location="../../"/>
<import file="includes/main-init.xml"/>
<target name="init" depends="main-init" unless="init.already.called">
<property name="init.already.called" value="true"/>
<property name="xdoclet.base.folder" value="xdoclet-1.2"/>
<property name="xdoclet.home" location="${tools.dir}/${xdoclet.base.folder}"/>
<path id="xdoclet.jars">
<fileset dir="${xdoclet.home}" includes="*.jar"/>
</path>
<path id="ics.task.path">
<pathelement location="${ant.ext.dir}/icstasks.jar"/>
<pathelement location="${appserver.jarfile}"/>
<path refid="xdoclet.jars"/>
</path>
<taskdef resource="com/icsaward/award/ant/tasks/taskdef.properties" classpathref="ics.task.path" />
</target>
<target name="test" depends="init">
<typedef name="ejbfilter" classname="xjavadoc.ant.XJavadocFilter" classpathref="xdoclet.jars"/>
<xjavadocupdate destdir="d:/misc"
failonerror="no" deploydesc="ejb-jar.xml,jonas-ejb-jar.xml">
<fileset dir="${project.src}" includes="${neware.path}/server/sb/em/address/*.java">
<or>
<!-- <custom classname="xjavadoc.ant.XJavadocFilter" classpathref="xdoclet.jars">-->
<!-- <param name="implements" value="javax.ejb.EntityBean"/>-->
<!-- </custom>-->
<custom classname="com.icsaward.award.ant.tasks.XJavaDocSelector" classpathref="ics.task.path">
<param name="implements" value="javax.ejb.SessionBean"/>
</custom>
<custom classname="com.icsaward.award.ant.tasks.XJavaDocSelector" classpathref="ics.task.path">
<param name="implements" value="com.icsaward.award.server.sb.common.EntityManagerBean"/>
</custom>
</or>
</fileset>
</xjavadocupdate>
</target>
</project>
When it goes into the isselected method for my AddressEMBean java file it is not selected and I get the following output:
considering com\icsaward\award\server\sb\em\address\AddressEMBean.java
com.icsaward.award.server.sb.em.address.AddressEMBean does implement javax.ejb.SessionBean
com.icsaward.award.server.common.Tester is not a javax.ejb.SessionBean
The com.icsaward.award.server.common.Tester object is an inner class defined in a totally irrelevant Java file located elsewhere in my filesystem. It is not even part of the fileset that I pass to the filter. However, it is causing a rejection of the file that I do want to go through. I'll have to look at this more to see what the issue is. If anyone has any clues why it behaves this way feel free to chime in.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
