[David Matthew Bond]

Hi
Using MyEclipse 3.8 Beta 1 with eclipse 3.0 RC1
I’ve been really looking forward to the 3.8 Beta 1 especially because of the “Web Project Build Path Deployment Policy” feature, which I need
see https://www.genuitec.com/forums/topic/web-module-project-does-not-pass-classpath-info-to-tomcat5/&highlight=

I have tried this out with a simple WebApp that is dependant on a Java Project X. Using the setting “Use smart deployment for dependant java projects” things worked fine

In another situation I have 2 WebApp projects WA1 and WA2. WA2 is dependant on WA1 so I expected the compiled versions src/**/*.java to be deployed to tomact 5 in the WEB-INF/classes/…. directory. However this is not happening.

Is this because WA1 is a J2EE Web module Project and not just a simple Java Project?

Any ideas

Thanks

Matt

[Scott Anderson]

Matt,

Is this because WA1 is a J2EE Web module Project and not just a simple Java Project?

Yes, that’s exactly why the project is not deployed. If you have one web project dependent on another one, there is really no way a tool can know how to deploy it. What does it do with the multiple WEB-INF directories with duplicate web.xml / struts-config.xml files etc.? As a result, dependent projects are limited to Java projects only since it is then obvious that these are to be treated as libraries.

[navis]

I think the best use of this feature is to compile the jars from another project like (commons / utils) and put them under /WEB-INF/lib before deployment. What else?

<navjot/>

[Scott Anderson]

Navjot,

Actually we do exactly that when you select the ‘jar’ packaging option, but only copy the jars to the lib directories in the deployment areas, not in the workspace itself. This allows you to continue to manage the dependency as a project dependency and keeps the packaging on an ‘as needed’ basis.

[David Matthew Bond]

Scott – You wrote
“is really no way a tool can know how to deploy it. What does it do with the multiple WEB-INF directories with duplicate web.xml / struts-config.xml files etc.? As a result, dependent projects are limited to Java projects only since it is then obvious that these are to be treated as libraries.”

I assumed that you are only interested in code anyway. Why dont you just include stuff checked “Export”s in the “Java Build Path” Dialog, “Order and Export” Tab?

I realized that extracting the common part out into an extra java project was possible – thought that I might be able to avoid it since dependant projects worked fine when we previously used the sysdeo tomact plugin instead of MyEclipse

[Scott Anderson]

I assumed that you are only interested in code anyway.

I obviously didn’t. 😉 Seriously, by code you mean Java only right? Not JSP’s etc?

I realized that extracting the common part out into an extra java project was possible

In fact, I’d recommend it since your final deployment of a packaged product to production will most likely require you to do this anyway, won’t it?

Why dont you just include stuff checked “Export”s in the “Java Build Path” Dialog, “Order and Export” Tab?

Mainly because that could get you looking recursively down the classpath as your dependent project export more projects and libraries etc, etc. For the first release of dependent project support we specifically limited it to directly dependent projects and external libraries (in beta 2) since this was 90%+ of what users were requesting.

[benson_margulies]

Is the situation hopeless in Eclipse 2.1.3, in terms of automating the flow of a dependent project JAR into WEB-INF/lib when deploying the web project.

[Author]

Posts