[jcorbin4607]

I’ve noticed, and its pretty annoying, that the autobuild settings of MyEclipseIDE do not always work for Web Modules. For example, I can delete the source tree under the WEB-INF/classes directory and refresh the project with the Auto Build enabled and it doesn’t rebuild. There have been other instances in the Web Module’s source (JAVA and JSPs) when modified do not get recognized by the MyEclipseIDE (Eclipse?) as having changed, so no build is triggered.

Is this a known issue or is there a setting in MyEclipseIDE that affects the auto build (other than the menu item Build Automatically)?

Verified Environment:

Windows XP Service Crash 2
MyEclipseIDE 3.84
Eclipse 3.0.1
Compile Time: JDK 1.5_01
Run Time: JDK 1.5_01 JRE

Regards,
J.D.

[Riyad Kalla]

JD,
MyEclipse hooks directly into the Eclipse notification framework, so if it gets a modification event, it will rebuild. If you are running Ant scripts and such that run in external processes, Eclipse is not aware of these changes and will not notify MyEclipse of changes so no rebuild will take place.

In the case of erasing your output dir, why not just clean the project? Also try refreshing (right click on project root > Refresh).

[jcorbin4607]

@support-rkalla wrote:

JD,
MyEclipse hooks directly into the Eclipse notification framework, so if it gets a modification event, it will rebuild. If you are running Ant scripts and such that run in external processes, Eclipse is not aware of these changes and will not notify MyEclipse of changes so no rebuild will take place.

In the case of erasing your output dir, why not just clean the project? Also try refreshing (right click on project root > Refresh).

Not sure this isn’t still an issue. I had to delete the compiled source tree under the classes directory for my web project because after I executed a clean on this project (auto rebuild disabled) the class files weren’t removed.

[Riyad Kalla]

If you have autobuild turned on, a clean will erase and immediately rebuild them. If you want them removed until you rebuild later, turn off automatic building under the Project menu. However I would advise against that, as a lot of the nice validation that takes place in ME keys off of the Automatic build cycle.

[jcorbin4607]

Riyad,

I know how it is supposed to work. My point is that I’m not always seeing the environment work as you describe. For example, if I specify that I want to clean the web project but not automatically rebuild, shouldn’t I see the classes directory be removed??? Yes, I did a refresh on the Web project. After cleaning the project with the auto rebuild flag not selected, I still see all the .class files in the web project. Its like the clean option didn’t clean anything.

This goes to a bigger issue. Don’t get me wrong, I am a fan of the IDE but there are a lot of little issues like this that I see on a daily basis with this tool that I imagine would be flushed out with extensive testing of the product.

Here is another oddity that I’ve run into with this tool that ends up taking a long time to resolve.

I created an EJB and named it to end with “EJB”, as in MyEJB.java. I later realized this didn’t fit in with our naming conventions of EJBs so I renamed the EJB to MyBean.java. The old class was deleted in CVS, replaced by the new one. I ensured all the xdoclet tags were correct, deleted my interfaces that xdoclet generates (just to ensure a clean build). I ran the tool which regenerated all my interfaces as you might expect. After the project(s) rebuilt, I successfully re-deployed the EAR (exploded) and then started JBOSS 4.0. The deployment was generating errors that referenced the old bean (one that ended in “EJB” that was removed) so I started looking at the ejb-jar.xml and jboss.xml that was generated by running the xdoclet build. As it turned out, the ejb-jar.xml correctly referenced the newly renamed ejb but the jboss.xml was incorrect in that it had an entry for both the new EJB and the old one that was deleted. I had to manually delete the jboss.xml file and rerun xdoclet to force a clean recreation of the file.

The xdoclet support should recognize and regenerate the ejb-jar.xml and jboss.xml completely when EJBs are added or removed to prevent these kinds of issues.

J.D.

[Riyad Kalla]

shouldn’t I see the classes directory be removed???

No, default Eclipse behavior when treating output folders is to clean their contents, not erase the folder.

I still see all the .class files in the web project. Its like the clean option didn’t clean anything.

Ok I agree THIS is wrong. Can you open up your Java Build Path and double check your output dir is set correctly? If so check your log file (workspace dir)\.metadata\.log for exceptions related to this problem. Is your output dir on a network share? Is it possible a virus scanner or something else could be locking the files stopping them from deletion?

but there are a lot of little issues like this that I see on a daily basis with this tool that I imagine would be flushed out with extensive testing of the product.

=/, certainly not what we want to hear. I would encourage you to run Eclipse/MyEclipse with JRE 1.4.2_07 as Eclipse 3.0.x is not certified on JDK 1.5 platform (3.1 will be). While I don’t think this will make a huge difference, it could count for some of the strangeness. Everyone’s computer is different.

The xdoclet support should recognize and regenerate the ejb-jar.xml and jboss.xml completely when EJBs are added or removed to prevent these kinds of issues.

This is an XDoclet issue and should be filed with the XDoclet developers. Our GUI and editors provide help when using XDoclet but we do not develop our own XDoclet implementation, we use the libraries from http://xdoclet.sf.net to do all the processing, which is what is at fault in this situation. I am sorry you ran into this problem however.

[jcorbin4607]

@support-rkalla wrote:

shouldn’t I see the classes directory be removed???

No, default Eclipse behavior when treating output folders is to clean their contents, not erase the folder.

I still see all the .class files in the web project. Its like the clean option didn’t clean anything.

Ok I agree THIS is wrong. Can you open up your Java Build Path and double check your output dir is set correctly? If so check your log file (workspace dir)\.metadata\.log for exceptions related to this problem. Is your output dir on a network share? Is it possible a virus scanner or something else could be locking the files stopping them from deletion?

but there are a lot of little issues like this that I see on a daily basis with this tool that I imagine would be flushed out with extensive testing of the product.

=/, certainly not what we want to hear. I would encourage you to run Eclipse/MyEclipse with JRE 1.4.2_07 as Eclipse 3.0.x is not certified on JDK 1.5 platform (3.1 will be). While I don’t think this will make a huge difference, it could count for some of the strangeness. Everyone’s computer is different.

The xdoclet support should recognize and regenerate the ejb-jar.xml and jboss.xml completely when EJBs are added or removed to prevent these kinds of issues.

This is an XDoclet issue and should be filed with the XDoclet developers. Our GUI and editors provide help when using XDoclet but we do not develop our own XDoclet implementation, we use the libraries from http://xdoclet.sf.net to do all the processing, which is what is at fault in this situation. I am sorry you ran into this problem however.

Ok I agree THIS is wrong. Can you open up your Java Build Path and double check your output dir is set correctly? If so check your log file (workspace dir)\.metadata\.log for exceptions related to this problem. Is your output dir on a network share? Is it possible a virus scanner or something else could be locking the files stopping them from deletion?

I should have been more clear from the get go that it was the .class files that weren’t being removed in my environment. The only errors I see in the log file are related to com.ibm.etools.validation plugin. It appears to be a stack overflow error. However, it doesn’t seem related to this issue.

=/, certainly not what we want to hear. I would encourage you to run Eclipse/MyEclipse with JRE 1.4.2_07 as Eclipse 3.0.x is not certified on JDK 1.5 platform (3.1 will be). While I don’t think this will make a huge difference, it could count for some of the strangeness. Everyone’s computer is different.

We are using Sun’s JDK 1.4.2_07 for compilation and using JRockit Version 1.5 JRE for the runtime so I think we are in compliance with what you recommend for MyEclipseIDE 3.8.4 running on Eclipse 3.0.1.

This is an XDoclet issue and should be filed with the XDoclet developers. Our GUI and editors provide help when using XDoclet but we do not develop our own XDoclet implementation, we use the libraries from http://xdoclet.sf.net to do all the processing, which is what is at fault in this situation. I am sorry you ran into this problem however.

Yeah, its a little tough for users of this tool to identify whether the issue is truly a MyEclipseIDE issue or reserved for the 3rd party that developed the plugin. As a user of this product, how am I to know if MyEclipseIDE uses a unmodified 3rd party plugin or modified a 3rd party plugin for inclusion into MyEclipseIDE? I would rather not have to go through these kinds of discoveries when using this product. I think it is one downside to companies that implement their products using plugins from 3rd parties. It is very easy to point the finger at the implementors of the plugin which makes it difficult for users to track down and resolve issues. I guess this is a trade-off of any plug and play architecture.

J.D.

[Riyad Kalla]

We are using Sun’s JDK 1.4.2_07 for compilation and using JRockit Version 1.5 JRE for the runtime so I think we are in compliance with what you recommend for MyEclipseIDE 3.8.4 running on Eclipse 3.0.1.

I was referring to what you run Eclipse itself with either by using the -vm argument OR by the default javaw executable in your path. JRE 1.5 is not ceritfied on Eclipse 3.0.x platform (you can see this under their development doc and which platforms will be tested on). While I’m sure it mostly works, our “Best case environment” is running Eclipse with Sun’s 1.4.2_07 release.

Also when you mention “Compilation” you realize that if you are using Eclipse to build your projects then the JDT’s compiler is being used and not the Sun’s JDK correct? If you are using a script, obviously then the JDT’s compiler will not be used. I bring this up because some people do not realize that the JDT includes it’s own compiler whose settings are not effected by changing around their build scripts, so they sometimes get flustered.

Yeah, its a little tough for users of this tool to identify whether the issue is truly a MyEclipseIDE issue or reserved for the 3rd party that developed the plugin.

I would not expect you to know.

It is very easy to point the finger at the implementors of the plugin which makes it difficult for users to track down and resolve issues.

No doubt.

I guess this is a trade-off of any plug and play architecture.

There is a balancing act to be struck between “implement everything our selves so we are always behind the competition and must maintain an ungodly amount of work ourselves” and then the other extreme of “maintain nothing except gluing all plugins together into a single Eclipse install”.

As I hope you would agree, our current model is somewhere right in the middle. We try and integrate when we see benefit to it and create tools that are not available from scratch that add value to our product for our users.

These annoyances and inconsistencies will naturally be smoothed out and refined or removed as the product grows and advances. If you compared MyEclipse of today from MyEclipse of exactly 1 year ago, they are completely different products. Moving forward, we don’t plan on stopping that trend any time soon.

[jcorbin4607]

I was referring to what you run Eclipse itself with either by using the -vm argument OR by the default javaw executable in your path. JRE 1.5 is not ceritfied on Eclipse 3.0.x platform (you can see this under their development doc and which platforms will be tested on). While I’m sure it mostly works, our “Best case environment” is running Eclipse with Sun’s 1.4.2_07 release.

Also when you mention “Compilation” you realize that if you are using Eclipse to build your projects then the JDT’s compiler is being used and not the Sun’s JDK correct? If you are using a script, obviously then the JDT’s compiler will not be used. I bring this up because some people do not realize that the JDT includes it’s own compiler whose settings are not effected by changing around their build scripts, so they sometimes get flustered.

I am aware of this but will confirm just to make sure. 🙂

There is a balancing act to be struck between “implement everything our selves so we are always behind the competition and must maintain an ungodly amount of work ourselves” and then the other extreme of “maintain nothing except gluing all plugins together into a single Eclipse install”.

As I hope you would agree, our current model is somewhere right in the middle. We try and integrate when we see benefit to it and create tools that are not available from scratch that add value to our product for our users.

These annoyances and inconsistencies will naturally be smoothed out and refined or removed as the product grows and advances. If you compared MyEclipse of today from MyEclipse of exactly 1 year ago, they are completely different products. Moving forward, we don’t plan on stopping that trend any time soon.

Yeah, I know what the product was like when you first released it. I’ve been using it for a couple years now and really do like it. If it sounds like I was criticizing the product I apologize as that wasn’t my intention. My intent is to maintain an open communication with the MyEclipseIDE folks so these types of things can be resolved quickly. I realize that there is always a strong push in software development to get functionality out the door and too often it comes with a cost in quality.

Thanks for the quick responses. Bottom line is that I’ve been able to resolve most if not all the issues I run across and it is in big part to the existance of these forums.

[Riyad Kalla]

JD are you part of the QA team or would you be interested in joining? Naturally you’d have to be OK with broken things every once and a while and the ability/tollerence to deal with creating new workspaces/etc… but if you felt that would be something you are interested in we would like to have you banging on our betas to keep us honest 😉

[jcorbin4607]

@support-rkalla wrote:

JD are you part of the QA team or would you be interested in joining? Naturally you’d have to be OK with broken things every once and a while and the ability/tollerence to deal with creating new workspaces/etc… but if you felt that would be something you are interested in we would like to have you banging on our betas to keep us honest 😉

Riyad,

Sorry it has taken me so long to respond to your inquiry. Travel and business has been brisk lately. I’d be happy to join the MyEclipseIDE QA team. I use this product almost exclusively and as you may or may not know convinced my development group to do so as well (instead of WSAD). Let me know what I need to do to join the QA team.

Regards,
J.D.

[Author]

Posts