[bseib]

I am using eclipse-3.0.1, MyEclipse 3.8.2, and targeting Tomcat 5.0.28.

Here’s what I have:
Web Project named “FooWeb”
Java Project named “CommonLib”

– In FooWeb Properties > Java Build Path > Projects, I have “CommonLib” checked.

– In FooWeb Properties > Project References, I have “CommonLib” checked. (Is this necessary?)

– In FooWeb Properties > MyEclipse-Web > Web Project Dependent Project Deployment Policy, I have selected “Use Smart deployment for dependent Java projects”.

When I do a deploy, it does not “merge” the class files from CommonLib into my FooWeb WEB-INF/classes directory as the footnote states. In fact the “CommonLib” class files do not show up anywhere in the Tomcat tree. Naturally, I get class not found errors.

I tried using the option “Always jar referenced Java Projects and place in the ‘lib’ directory when deploying”, but it costs too much time upon reloads, and futhermore, it requires manual re-deployment *way* too often to be practical.

A solid, functioning hot-deploy feature is critical to this tool being useful for our development. Thank you for your attention to this.

[Riyad Kalla]

bseib,
Can you navigate to Window > Preferences > Java > Debug and see if you have any of the “Show warning” checkboxes unchecked?

Depending on the types of changes you make to your Java library, some of the hotdeployed files will not be successfully reloaded (for example if the structure of the class file changes it won’t reload).

However, I just tried to recreate the problem you described here and everything worked as expected (the Java Project changes were copied out to the Tomcat install).

[bseib]

Hi rkalla,

I went to Window > Preferences > Java > Debug and confirmed that all the checkboxes are still checked.

Let me check for understanding of the behavior I am expecting:

If I select “Use Smart deployment for dependent Java projects”, then I should see the contents of my “CommonLib” jar project get “exploded” out into the directory: {TomcatHome}/webapps/FooWeb/WebRoot/Web-INF/classes ?

Is this the behavior I should get?

[Riyad Kalla]

Yes absolutely right, it should be copied out to the classes dir just as you expected it to be in your original post… can you check your log file for any errors that might hint at what is going on?

(workspace dir)\.metadata\.log

[bseib]

Hmmm, not seeing anything useful in the log file….

Can you clarify this detail even further for me:

By merely doing a deploy (and never starting Tomcat), should I see my CommonLib class files show up in {TomcatHome}/webapps/FooWeb/WebRoot/Web-INF/classes ?

I’m guessing “yes”, as I would like to eliminate starting/stopping the server as a variable in my experiments. But I’d like to confirm with you if this is really true.

-broc

[Riyad Kalla]

Yes

[bseib]

Ok good. I don’t need to bother with starting/stoping tomcat.

Still, it is still not working correctly. I exported my two projects and zipped them up to share with you. This zip file is (temporarily) at: http://vyking.com/SmartDeployProblem.zip

Here’s exactly what I do to reproduce the problem:

1) Extract all files from SmartDeployProblem.zip to C:\
2) Open eclipse-3.0.1 (with MyEclipse 3.8.2) installed.
3) I choose a brand new workspace, “c:\space2”
– (i dismiss the Welcome screen)
4) File > Import… > Existing Project into Workspace
– Next >
– Project Contents: C:\SmartDeployProblem\CommonLib
– Finish.
5) File > Import… > Existing Project into Workspace
– Next >
– Project Contents: C:\SmartDeployProblem\FooWeb
– Finish.
6) Right-click “FooWeb” project.
– confirm Java Build Path refers to CommonLib.
– confirm Project References refers to CommonLib (is this necessary?)
– in MyEclipse-Web, select “Use Smart deployment …”
– OK.

I must first setup my Tomcat appserver prefs, before deploying is allowed.

7) Window > Preferences > MyEclipse > Application Servers > Tomcat 5
– select “Enable”
– set Home Directory: “C:\Program Files\Apache Software Foundation\Tomcat 5.0”. (the other two auto-fiill with the similar values.
8) Window > Preferences > MyEclipse > Application Servers > Tomcat 5 > JDK
– add my JDK (not JRE) as “C:\j2sdk1.4.2_05”
– name it “j2sdk1.4.2_05”
9) click OK on the Window> Preferences dialog to dismiss.

Ok, now setup and do a deploy:

10) right-click “FooWeb” project
11) select MyEclipse > Add and Remove Project Deployments…
– project reads “FooWeb”
12) click “Add”
13) select Server: “Tomcat 5”
14) select “Exploded Archive”
– deploy location is: C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\FooWeb
15) click Finish.
16) by highlighting the new entry, you see the status says “Successfully deployed.”

Ok, now check the filesystem for classfiles from CommonLib. Specifically, I should see a Hello.class file somewhere.

17) In windows, navigate to C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\FooWeb\WEB-INF\classes

I found this directory to be empty, but expected to see “common/lib/Hello.class” here.

Can you try to reproduce this using my example code and above steps?
-broc

[Riyad Kalla]

Broc,
First let me thank you for the outstanding walkthrough and details… I have figured otu the problem and why I can’t reproduce this… you are using your commonLib project root as the source root… once you add a source folder, like /src, exporting the classes works as expected.

I will file this as a bug and see if we can get it fixed soon, in the mean time maybe this can help you work around the problem?

[bseib]

Aha!

Yes, when I create a Java Project in eclipse, if I select “Create separate source and output folders” (instead of the default “Use project folder as root for sources and class files”), then everything works. Thanks.

I have one more minor detail I am curious about:

In (right-click FooWeb project) > Properties > Project References, what does this do? I unchecked these and the deploy still works, presumably based on the Java Build Path information. Just curious.

Thanks for your help & filing the bug. The deploy workaround will be fine for now.
-broc

[Riyad Kalla]

In (right-click FooWeb project) > Properties > Project References, what does this do?

I’ve seen you ask this twice, and BOTH times I mentally tell myself ‘That’s a good question, I’ll answer that’ and then I end up typing the first part of my message and hitting “Submit” without ever answering that question… sorry about that.

I honestly don’t know if the Project References checkbox is necessary, if deployment works without it… then screw it 😀

Thanks for your help & filing the bug. The deploy workaround will be fine for now.

I should be thanking you, this was a very hard to track down problem and your steps to reproduce were very detailed.

[rjst]

Hi,

I have the same problem as above, but with a slight difference. I have separate folders for src and classes.

I have a web project that depends on 2 projects. One of them is correctly merged, the other is not.

The only differences between them are that the one that doesn’t work is a myeclipse ejb project, and has a similar package structure to the web project (for example share the the com.foo package, and have classes in packages with similar names)

Any help apreciated, this is grinding our productivity…

thanks
Ricardo

[rjst]

I forgot to mention that the external classes are copied to the classes dir of the web project, they just aren’t deployed

thanks
Ricardo

[Riyad Kalla]

Ricardo,
We do not support deployment of a Web Project depending on a EJB project; EJB and Web Projects are at the same level in the “Project” hierarchy, both can rely on a Java Project, but cannot rely on eachother (during dpeloyment). That is the purpose of the Enterprise App Project; you define one of these projects, and defined your WEb and EJB Projects as modules of it; then when it is deployed, it will package the projects correctly and deploy them to your J2EE server.

[rjst]

ok, it’s working now, but I need to have 4 projects defined.

Wouldn’t it make sense in future versions to support all features in the same project, and allow the project to produce multiple deployments ?

thanks
Ricardo

[Riyad Kalla]

Ricardo,
Your thinking is inline with some of the more cutting edge things we are thinking about for future project structure/deployment overhaul. I will add your comments to our internal dialog as I think they are all good user feedback for us to consider.

[Author]

Posts