- This topic has 11 replies, 5 voices, and was last updated 20 years, 11 months ago by Riyad Kalla.
-
AuthorPosts
-
tauzeroMemberHi,
I’ve got some problem with the way the XDoclet stuff is working with My Eclipse (we are using My Eclipse 2.6.3 with Eclipse 2.1.1 – My Eclipse 2.6.4 has some problem compiling some of our JSP so we are not using it for now.).
First, the build file that is being generated is using absolute <pathelement location=”…”/>. This is a big prblem as we are working in a team environment and we cannot garantee (due to different hardware configuration) that everything refered in these paths will be in the same place. We will also do automated build on Linux so we cannot reuse the generated build script.
The <pathelement /> also refer to the JDK. Why is that, the JDK classpath is already availlable to Ant scripts. Why put it there?
As for the other things that it depends on (xdoclet.modules.ejb.EjbDocletTask) I would prefer to be able to put the Jar containing this class somewere I want (in a project that is in the workspace) and refer to it with a relative path (I already have a project that contains all necessary JAR files to compile a project from an Ant script on the command line).
Second, Whenever I do a change in the MyEclipse-XDoclet tab from the Project Properties, the xdoclet-build.xml get regenerated. So I cannot modify it to use relative paths.
Are there any plan to fix these issues? These are showstoppers for any serious team development.
SeeU!
support-michaelKeymasterThanks for the feedback. We are aware of the need for better XDoclet integration and support and take your concerns very seriously. We have plans to significantly improve the XDoclet integration and support over the next few months. I have added your issues to our issues tracking system to reinforce the need for improvement.
Michael
MyEclipse Support
tauzeroMemberThank’s!
In the mean time, is there a way to prevent My Eclipse to add the XDoctlet external tool definition to a project Build Process?
My Eclipse seem to add this external tool definition each time we access the XDoclet configuration is the project properties.
Any time frame for the enhanced XDoclet support?
Note that we are very please with My Eclipse as of now (even if it still need to mature a bit). We plan to buy somewere like 10 licenses for our current project with more for upcoming projects (in fact, we will replace JBuilder Enterprise with My Eclipse/Eclise for our entire unit – ~60 Java developpers – if everything goes well in our project – awsome savings 😉 ).
SeeU!
Scott AndersonParticipantIn the mean time, is there a way to prevent My Eclipse to add the XDoctlet external tool definition to a project Build Process?
My Eclipse seem to add this external tool definition each time we access the XDoclet configuration is the project properties.
Currently, once you add an XDoclet configuration to a project, it becomes part of the build process. This was done because at any time you can go through and change your EJB’s or web content, which would cause your descriptors to get out of sync. A build is supposed to really build anything that needs it, so regeneration of descriptors is done if the underlying resources have changed. If they haven’t, XDoclet still runs, but nothing is regenerated. We’ll be making this more flexible in the future, as Michael pointed out.
Any time frame for the enhanced XDoclet support?
Not that I’ve heard, really. But our schedules are pretty aggressive (month to month) so I don’t expect it will be too far out, since we’ve said we’re going to do it.
Note that we are very please with My Eclipse as of now (even if it still need to mature a bit).
Thanks. It’s only been out a few months so we know it’s a young product. We’re working very hard to make it better all the time. The fact that you’re already considering it at a replacement for JBuilder (which has been around for years and years) is really positive feedback. As long as our users keep giving us feedback we’ll be able to continue to enhance it in all the right areas.
–Scott
MyEclipse Support
Marcus BeyerMember@tauzero wrote:
The <pathelement /> also refer to the JDK. Why is that, the JDK classpath is already availlable to Ant scripts. Why put it there?
I am also facing that problem, but it’s not the JDK — it’s the JRE:
<pathelement location=”C:/Programme/Java/j2re1.4.2_03/lib/rt.jar”/>
etc.
I have two questions: I installed the JDK (J2SE) into c:/coding/j2se.
1. Why is the included JRE installed into both c:/coding/j2se/jre *and* into c:/Programme/Java/j2re1.4.2_03? [Sorry, this one is perhaps off-topic.]
2. Why is c:/Programme/Java/j2re1.4.2_03 written into xdoclet-build.xml and not the path I’ve chosen (here: below c:/coding/j2se/)? It seems that the two paths contain the same Jars. The way it currently works, we have to install always the same JDK subversion to all developer machines …
thanx!
Marcus
Marcus BeyerMember@mb wrote:
I am also facing that problem, but it’s not the JDK — it’s the JRE:
<pathelement location=”C:/Programme/Java/j2re1.4.2_03/lib/rt.jar”/>
etc.
I have two questions: I installed the JDK (J2SE) into c:/coding/j2se.
1. Why is the included JRE installed into both c:/coding/j2se/jre *and* into c:/Programme/Java/j2re1.4.2_03? [Sorry, this one is perhaps off-topic.]
2. Why is c:/Programme/Java/j2re1.4.2_03 written into xdoclet-build.xml and not the path I’ve chosen (here: below c:/coding/j2se/)? It seems that the two paths contain the same Jars. The way it currently works, we have to install always the same JDK subversion to all developer machines …
I just found the solution myself: When installing the JDK (J2SE) just disable the “extra JRE copy”-thing. That’s it 🙂
Marcus
Riyad KallaMemberThanks for the solution Marcus!
Marcus BeyerMember@mb wrote:
I just found the solution myself: When installing the JDK (J2SE) just disable the “extra JRE copy”-thing. That’s it 🙂
As one side effect, Java Web Start doesn’t work anymore 🙁
When I start C:\coding\j2se\jre\javaws\javaws.exe it complains, that C:\Proramme\Java\j2re1.4.2_03\bin\javaws.exe is not there 🙁Please help!
Marcus
Riyad KallaMemberMarcus,
Please note that my solution only works if you have atleast 1 JRE installed, if not, skip the following answer:1) you need to have atleast 1 JRE installed for Web Start to work. You can check this by viewing:
C:\Programme\Java
and see if you have any full JRE’s installed (make sure the directories aren’t empty). Once you find a JRE that is installed, open up regedit.exe
Start->Run->regedit.exe
Go to:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Web Start
On the right side you should have a field called “CurrentVersion” of type REG_SZ, what you want to do here is change this version number to the version of the JRE you found in the directory when you went looking for it in the 1st step.
To see the available versions you can change this value to, expand the node you have selected (“Java Web Start”), it should have many children nodes.
Riyad KallaMemberMarcus,
I think I’ve got another suggestion for you.1) Reinstalled the entire JDK (1.4.2_03 or whatever you were using)
2) Load up Eclipse
3) Windows->Preferences->Java->Installed JREs
4) Change the directory of this “Installed JRE” from the C:\Programme\… directory that Eclipse picks up automatically, to the JDK installed directory (C:\j2sdk1.4.2_03, or whatever you called it)
5) Restart Eclipse
6) Regenerate the XDoclet file, see if the path its using to point to Java is the JDK, not the JRE.Did this work?
Marcus BeyerMember@support-rkalla wrote:
4) Change the directory of this “Installed JRE” from the C:\Programme\… directory that Eclipse picks up automatically, to the JDK installed directory (C:\j2sdk1.4.2_03, or whatever you called it)
5) Restart Eclipse
6) Regenerate the XDoclet file, see if the path its using to point to Java is the JDK, not the JRE.
Did this work?Yes. That was very helpful 🙂
Thank you for the quick help!
Marcus
Riyad KallaMemberNo problem, I’m glad it worked.
-
AuthorPosts