The following comment has been added to this issue:
Author: Paul Stath
Created: Fri, 13 Feb 2004 7:38 AM
Body:
I have also run across this problem in my build.
In my build, I use the ejbdoclet task multiple times to build seperately deployable
JAR files, that get packaged into the same EAR.
I call the ejbdoclet task in a sub-build, and pass in references to the classpath,
sources, etc. to be used in that sub-build.
I would prefer not to perform the ejbdoclet taskdef in each sub-build to get the
classpath issues correct.
Please put the <classpath> subelement back in the <ejbdocklet> task!!
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/xdoclet/secure/ViewIssue.jspa?key=XDT-785
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XDT-785
Summary: Lack of classpath attribute in ejbdoclet task
Type: Bug
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: XDoclet
Components:
EJB Module
Versions:
1.2
Assignee: xdoclet-devel (Use for new issues)
Reporter: Kevin Seal
Created: Wed, 28 Jan 2004 12:27 PM
Updated: Fri, 13 Feb 2004 7:38 AM
Environment: XDoclet 1.2, Ant 1.6, J2SDK 1.3.1, Windows 2000
Description:
Perhaps I've misinterpreted the examples or bodged porting my previous ejbdoclet
tasks...
It appears that the required support classes for EJBs now need to be specified in the
taskdef for ejbdoclet rather than in the task itself as was previously possible:
CURRENT:
<taskdef name="ejbdoclet" ...>
<classpath>
<fileset dir="${xdoclet.lib.dir}"/>
<path refid="local.path"/>
</classpath>
</taskdef>
PREVIOUS:
<ejbdoclet ...>
<classpath>
<path refid="xdoclet.path"/>
<path refid="local.path"/>
</classpath>
</ejbdoclet>
For a build, such as the one I'm working on, which generates a set of JARs in
dependency order, this results in the various JARs becoming locked - presumably by
Ant's class loader believing them to be necessary for its configured tasks rather than
simply for the duration of each task.
This doesn't pose a problem during the initial generation/compilation of each project
JAR as the build is in dependency order.
However, this does result in some of the later deployment/release tasks failing as
they cannot move/rename/update/delete the various JARs.
This has been experienced when each of the ejbdoclet taskdefs is contained in its own
build file and is nested within a dedicated code-generation target.
I view this as a major limitation as it seems opposed to the modularity introduced in
Ant 1.6 (but hope I've simply got the wrong end of the stick!).
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
