Bug 255349 - Customized EAR/WAR deployment
Summary: Customized EAR/WAR deployment
Status: NEW
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: Future   Edit
Assignee: jst.j2ee CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2008-11-14 08:38 EST by Alvaro Romero CLA
Modified: 2008-11-25 10:35 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alvaro Romero CLA 2008-11-14 08:38:38 EST
We have to migrate a legacy JBuilder structure to Eclipse, and this structure has an "special" layout that we must maintain for compatibility reasons with our customers (and easy updating too). I posted a message some days ago:

http://www.eclipse.org/newsportal/article.php?id=17698&group=eclipse.webtools#17698

Using this layout makes easy updating to our customers, because our app is a modular ERP (about 250 megs whith all the modules!!!) and most of our customers doesn't use all the modules. We only need to update specific JAR files, and all customers maintain the legacy structure. 

Eclipse doesn't allow to customize the EAR layout as we used to do; editing the file org.eclipse.wst.common.component and changing the deploy-path property only works for EJB modules, and copy the modules in the EAR root too (why?). And Eclipse doesn't update the file after editing it, if, for exaple, we add a n ew module to the project.

We changed the JBoss deployer script - see my replies to the message -, but WAR projects remained compressed in the structure when we call the "publish" option in the server... And the builders cannot be configured (as far as I know). 

Other option is to make ant scripts for each project to produce the jars and the structure, but we don't know if we can debug server-side libraries from Eclipse if we do it. I think it's a waste, because Eclipse has good J2EE tools for not using them. 

The Eclipse EAR project approach is enough good to small and medium sized projects, but is too inflexible (why I cannot put my utility modules in other place than the root of the EAR, for example? ). It's good to keep the standard EAR structure as far as you can, but putting all the files in the root with 50+ ejb files, own libraries and third party libraries is a real mess.

And updating 100-200-250 megs for only 10 meg module is a real waste of time and resources, I think.

Thanks for the good job !!! WTP are aproaching to a winner project :-).
Comment 1 Carl Anderson CLA 2008-11-18 12:48:53 EST
Alvaro, the write up in this feature does not specify exactly what you want enhanced.  Could you please give clear details on the enhancements that you need?  (And you may want to open more than one enhancement, perhaps using this one as an umbrella to cover them all/bring them together.)

Also, you may want to provide patches to our code to implement your desired functionality.  (Especially since this seems to be something moreso limited to your specific set up.)  For this reason, I am marking this as helpwanted for now.
Comment 2 Alvaro Romero CLA 2008-11-25 10:35:22 EST
First of all: thanks for your response, Carl :).

As I told in the first post, we must migrate a JBuilder project structure to Eclipse because we use JBuilder 2005 cannot manage a series of new web service projects...Specially with java 1.5/1.6, so a migration to other tools was planned, specially Eclipse... Even Borland migrated to Eclipse :D.

JBuilder 2005 allows you to make a "mega-project" to produce EJB's, server business libraries for EJB's, web services, and so on in only one project, with enormous flexibility - JBuilder uses ant scripts, highly configurable-.

We splitted the server side projects into EJB projects, utility projects, etc, and some web applications including clients, to comply with the Eclipse projects philosophy... A long and boring job, but not too difficult.

In the first post I exposed our deployment structure, based on directories instead of compressed files - JBoss can deploy directories or compressed files -, so we can update easily our application, and programmers don't have to wait for a full deployment to test their modules. After some experiments, we "learned" that Eclipse allows to debug on server without building the full app, but, of course, the app must be deployed before on the server :). We created an EAR project with the same organization of JBuilder's one, and we "recreated" the same folder structure, copying the third party libs to the EAR project content, and leaving the others empty.

In the first runs, the EAR builder put all the EJBs and utility modules in the root folder of the file, mixing the jars in a real mess... After editing the application.xml, the builder put the ejb jars in the EJB folder of the structure, bu the others remained in the root, and the web projects were compressed too. The next step was deployer modification, and we customized the JBoss deployment script to copy the files in the "correct" place. This modification is lost after each WTP update, and doesn't allow us to develop more EAR projects without changing the file again. And the WAR clients remained as compressed files, so the modification is unuseful to our current distribution system.

As a final solution, we created ant scripts in each project that generate the jars into a folder that has the same structure as the one we want to deploy. After building, we copy the folder to JBoos deploy folder to run and test the app.

I posted the bug because Eclipse has a rigid project structure for EARs and WARs, and doesn't allow to customize the deployments without "tricks"; even it doesn't allow to choose if we want a compressed EAR file or a directory... As I said before, Eclipse WTP works very well with small and medium projects, but is not enough good to manage big projects - the libraries must be better organized , for example -.

And today I have no time to learn eclipse programming... :( Too much time is needed, and my job - and girlfriend - go first xD. In the "wishlist" of features for the 4.0 Eclipse release I posted ideas, some of them related with this bug and others related with usability.

P.D. : again, sorry for my VERY bad english :-)