- This topic has 8 replies, 4 voices, and was last updated 20 years, 9 months ago by b0rg.
-
AuthorPosts
-
mercatorgeoMemberWhen setting project properties, whenever I’ve (accidentally) viewed the XDoclet configuration page, an entire XDoclet configuration is added to the project (.xdoclet file , .ExternalToolBuilders directory etc.)
Also, XDoclet is automatically added to the builders list.This happens even if no actual XDoclect configuration is set (the entire list is empty).
I find that it is very risky if XDoclet is added unwantedly.
I have an EJB project of which I’d like to manage all classes and the ejb-jar.xml manually, without using XDoclet.
If, accidentaly I add an XDoclet builder to the project, XDoclet is run upon rebuilding the project. This will overwrite my existing EJB java files, which have been created manually, with invalid ones. Thank god for “Replace with > Latest from HEAD”!Would it be possible to remove all XDoclet files, and especially the builder, whenever MyEclipse determines that no XDoclet settings are needed? Otherwise I need to be very paranoid about setting project properties and rebuilding a project, making sure, every time, that it won’t suddenly run away with my code. 😥
Riyad KallaMemberThis is a good point, I will pass your request on ASAP.
Scott AndersonParticipantI’ve submitted an enhancement request so that the XDoclet builder will be removed from a project when no modules are configured.
[quote
Otherwise I need to be very paranoid about setting project properties and rebuilding a project, making sure, every time, that it won’t suddenly run away with my code.You shouldn’t worry too much. XDoclet only does something when you explicitly add and configure an XDoclet module on your project. If you later remove all the configured modules, the empty XDoclet task that does get run won’t do anything. If you’d like to keep the builder from running at all, you can manually remove by right-clicking on your project and selecting Properties > External Tools Builders, highlighting the builder and selecting remove.
mercatorgeoMemberXDoclet only does something when you explicitly add and configure an XDoclet module on your project
That is not what I’ve experiienced. I have an imported EJB project from JBuilder which absolutely does not have any XDoclet configuration either in the javadoc or in the project properties.
If I run XDoclet on this project, it will (re)generate a lot of files automatically (overwriting stuff that was created by JBuilder with illegal files). That was why I submitted this as a bug (even if I find the unnecessary Xdoclet files annoying)
This was happening to me this afternoon on Suse 8.2, Eclipse 3.0M7.
I’ll try to reproduce it on WinXP tonight or, more probably, tomorrow. (GMT+1 here. Btw, are you guys actually supporting me at 4:00 AM !?)
Riyad KallaMemberWe try not to sleep, it gets in the way of work 😉
Scott AndersonParticipantWe try not to sleep, it gets in the way of work
True. Sleep is for the mentally weak. I’ve been awake for 9 years at this point. 😉
That is not what I’ve experiienced. I have an imported EJB project from JBuilder which absolutely does not have any XDoclet configuration either in the javadoc or in the project properties.
If I run XDoclet on this project, it will (re)generate a lot of files automaticallyWhat does the xdoclet-build.xml file have in it?
mercatorgeoMemberhmmmm.. I’ve found the following entry in the xdoclet-build.xml file on my workplace (I’ve removed the enormous amounts of whitespace between empty tags):
<target name=”_generation_” depends=”N400004″/>
<target name=”N400004″ description=”Standard EJB”>
<taskdef classpathref=”xdoclet.classpath” classname=”xdoclet.modules.ejb.EjbDocletTask” name=”ejbdoclet”/><ejbdoclet ejbSpec=”2.0″ excludedTags=”@version,@author,@todo” destDir=”src” verbose=”true” addedTags=”@xdoclet-generated at ${TODAY},@copyright The XDoclet Team,@author XDoclet,@version ${version}” >
<fileset dir=”src” includes=”**/*.java” >
</fileset>
<packageSubstitution packages=”ejb” substituteWith=”interfaces” >
</packageSubstitution>
<remoteinterface>
</remoteinterface>
<localinterface>
</localinterface>
<homeinterface>
</homeinterface>
<localhomeinterface>
</localhomeinterface>
<dataobject>
</dataobject>
<valueobject>
</valueobject>
<entitypk>
</entitypk>
<entitycmp>
</entitycmp>
<entitybmp>
</entitybmp>
<session>
</session>
<dao>
<PackageSubstitution packages=”ejb” substituteWith=”dao” >
</PackageSubstitution>
</dao>
<utilobject includeGUID=”true” cacheHomes=”true” >
</utilobject>
<deploymentdescriptor validateXML=”true” destDir=”src/META-INF” >
</deploymentdescriptor>
</ejbdoclet></target>
</project>This task does not appear in the config that is automatically generated when saving the project properties without any XDoclet tasks. Here at home XDoclet does indeed run, but no files are modified.
Above task is the task that I added manually when I added the “Standard EJB” XDoclet configuration to the project to experiment.
If this task is run, it does (re)generate code, which for my existing project was a problem.However, here at home (WinXP), the task is correctly removed from the xml file if I remove it in the XDoclet properties. No problems there, it seems, so I think I may have caused the actual code loss problem myself. I must have checked the xdoclet-build.xml containing the task into cvs.
As an experiment, I manually added the task to my xdoclet-build.xml file.
If I do that, it does not show up in the XDoclet project properties page, but it IS started on a project rebuild.In conclusion, under rare circumstaces, XDoclet might actually start doing things that don’t show up in the XDoclet configuration, unless all XDoclet configuration files are automatically deleted if no task is present.
It seems you need a user error (me!) to cause this behaviour, but I’d still like the files to be removed anyway.
Thanks for the help!
Scott AndersonParticipantThanks for the full accounting and explaination. At least I feel a bit better how this can happen. I think the key was checking the build file into CVS. In any case, the enhancment request to remove the xdoclet metadata, build file, and builder still makes sense if no xdoclet tasks are selected in a project.
b0rgMemberPlease remember that some weeks ago I’ve asked for a switch/option for disabling XDoclet completely…
Victor
-
AuthorPosts