This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 305528 - xdoclet does not seem to get triggered.
Summary: xdoclet does not seem to get triggered.
Status: RESOLVED FIXED
Alias: None
Product: WTP EJB Tools
Classification: WebTools
Component: jst.ejb (show other bugs)
Version: 3.2   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P1 major (vote)
Target Milestone: 3.2 M6   Edit
Assignee: Kaloyan Raev CLA
QA Contact: Kaloyan Raev CLA
URL:
Whiteboard:
Keywords:
Depends on: 275741
Blocks:
  Show dependency tree
 
Reported: 2010-03-11 11:31 EST by Dimitar Giormov CLA
Modified: 2010-03-12 02:51 EST (History)
2 users (show)

See Also:


Attachments
patch (3.03 KB, patch)
2010-03-11 15:30 EST, Kaloyan Raev CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitar Giormov CLA 2010-03-11 11:31:34 EST
Xdoclet annotated artifacts are not registered in DD xml file.

Reproduce:
setup xdoclet version 1.2.3 in prefererecnces Java EE  > Xdoclet
create dynamic web project.
Create annotated servlet.

or 

create ejb 1.4 project with xdoclet facet and create xdoclet enterprise bean

result no entries in ejb-jar.xml or web.xml are recorded.
Comment 1 Kaloyan Raev CLA 2010-03-11 14:14:08 EST
Reproduced on Vista as well. 
The XDoclet Builder just does not execute. 
Manually calling the Run XDoclet command from the project context menu does not help, too. 
There is no error in the Error Log.
Comment 2 Kaloyan Raev CLA 2010-03-11 15:14:33 EST
This problem is because of the recent fix of bug 275741 done in the Platform. We call the LaunchConfigurationType.newInstance() by passing the absolute path of the ant file as name. This is not accepted any more. I will prepare a patch that adapts to this change. 

There is another issue in the XDoclet Logger classes - the plugin id is wrongly specified and therefore there was no error in the Error Log. I will fix this, too.
Comment 3 Kaloyan Raev CLA 2010-03-11 15:30:54 EST
Created attachment 161811 [details]
patch

This patch changes the way the LaunchConfigurationType's name is generated. Instead of the old deprecated generateUniqueLaunchConfigurationNameFrom() we now call the new generateLaunchConfigurationName() that guarantees that the return name is unique and valid.
Comment 4 Kaloyan Raev CLA 2010-03-11 15:36:37 EST
Committed to HEAD and released to build.
Comment 5 David Williams CLA 2010-03-11 15:45:31 EST
(In reply to comment #2)
> This problem is because of the recent fix of bug 275741 done in the Platform.
> We call the LaunchConfigurationType.newInstance() by passing the absolute path
> of the ant file as name. This is not accepted any more. I will prepare a patch
> that adapts to this change. 
> 

So ... is this a change in API behavior? Something internal we shouldn't be using anyway? In either case, I bet they'd appreciate knowing about the breaking behavior, so others could be warned?
Comment 6 Kaloyan Raev CLA 2010-03-12 02:51:58 EST
Yes, this is change in API behavior. I linked this bug to their bug, but I will also write a comment, so they are better notified.