- This topic has 16 replies, 8 voices, and was last updated 20 years, 1 month ago by
.
-
Posts
-
I am using eclipse 3.0 RC1 with MyEclipse 3.8Beta1.
I have an Enterprise project containing an EJB and a Web project. I am using smart deployment and the dependent projects get deployed to the Web Project but NOT to the EBJ project.
Is this expected behaviour or did I find a bug?
Thanks,
Cory WandlingCory,
This is expected behavior at present. Dependent project support is only available for web projects at this time. Part of the issue is that war’s have a designated location for all library files, but ejb jar’s do not. As a result, there is no standards-compliant handling of dependent projects that we can provide and each developer seems to handle them differently. We’re still looking at the requirements for something on this front. What would you like to see?
I am not sure. This is a HUGE hassle. How do you (personally) get around this?
I have a large group of developers and if the MDBs we build have dependancies – this is going to be a nightmare – change a common project and have to go rebuild all the EJB’s that use that project. Yikes!
I suppose that the classes could get deployed and the classpath get set in the meta file.
I am not sure. This is a HUGE hassle. How do you (personally) get around this?
Typically, since the dependent projects are typically frameworks we jar them and output them to the top-level of an enclosing EAR project. Then we modify the EJB project’s MANIFEST.MF file’s Class-Path entry to point to them. This allows us to have control over when we pull new framework versions to build against. The jaring can be made quite trivial by having Eclipse remember the jardesc when it’s done.
I have a large group of developers and if the MDBs we build have dependancies – this is going to be a nightmare – change a common project and have to go rebuild all the EJB’s that use that project. Yikes!
Well, the projects would need to be rebuilt whether we deploy the dependent projects or not, really. In the above scenario, when you run the jardesc the projects will be rebuilt by Eclipse since the jar on the classpath changed. Deployment gets handled because the jar resides within the EAR project and everything there is deployed automatically.
I suppose that the classes could get deployed and the classpath get set in the meta file.
Sure, we could do the ‘Smart deployment’ optoin for exploded deployments and simply copy all the class files into the exploded ejb jar’s tree, but what about packaged deployment? We could jar the projects, but then where do we put them? They could either go in the ear or directly in the ejb jar if the manifest classpath is correct. The problem is that whatever we do automatically, we’ll be ‘wrong’ according to some large percentage of developers since there’s no spec way to do it.
Smart deployment would be a HUGE win during development. If you can’t do the right thing for packaged deployment are you going to cripple those who want to use exploded deployment for development?
It’s not about trying to ‘cripple’ EJB development. We’re simply concerned with solving the ‘total’ problem. If we rolled out exploded deployment only, then people will build projects without thinking about how to solve the ‘real’ problem of how a packaged deployment will work.
Scott,
The solution you mention in the quoted section below is a typical way to handle the problem of dependent jars in J2EE projects. I even believe what you describe is how Webshere Studio Application Developer (WSAD) handles them and it seems to work just fine.
“Typically, since the dependent projects are typically frameworks we jar them and output them to the top-level of an enclosing EAR project. Then we modify the EJB project’s MANIFEST.MF file’s Class-Path entry to point to them. This allows us to have control over when we pull new framework versions to build against. The jaring can be made quite trivial by having Eclipse remember the jardesc when it’s done.”
J.D.
Is there any progress on this topic?
We are currently using ant builds for compiling and jaring our utility/domain projects into the EAR project each time it changes. This is a bit of a hassle, as just a small change in the classes triggers a ant build. The only other option seems to make the developer remember to build the tool projects before deployment, but this would be forgotten all the time.
Any timeframe for when it could be incorporated?
Any Status on this. We are having a similar issue when we have frameworks jars that are used by EJB’s and cannot seem to get those jars to deploy with the EAR. We would like the dependent jars to be placed inside the EAR and a manifest file generated. This is done automatically by tools such as Maven so you might use that as a good model. Today we use MavenIDE within eclipse to bundle and deploy but would prefer to use MyEclipse.
Internally we’ve been discussing future enhancements to to both dependent project support for EJB and EAR projects as well as more flexibility for web projects. We plan on implementing both over time, but from the sounds of this discussion I’d imagine that dependency support for EJB and EAR projects would be more beneficial to larger projects at this point. I’ll forward the comments here to our management because we certainly want to support larger projects as well as we can. I’d expect some improvement on this in 3.9 at the latest and 3.8.3 at the earliest since it is viewed as very high priority after 3.8.2 ships.
So, let’s start a discussion about what you really want. For example, I’d suggest these basic rules:
1) If an EAR project is dependent on a Java project, the Java project should be jar’d and placed at the root of the deployed EAR.
2) If an EJB project is dependent on a Java project, the Java project should be jar’d and placed at the root of the deployed EJB jar.In each case, we could generate a MANIFEST.MF file in the deployment to point to the included libs. Does that do it for everyone? Weigh in here please.
I think this sounds like a great solution and is similar to what Maven does. I would suggest the ability to select which jars get added to the EJB jar and the EAR and for that matter Web projects(WAR). For example if I need some jars from my server in the classpath to be present in order to compile my project I might not want to include those jars in my final EAR or EJB jar since they are provided by the server.
Another example might be an EJB project that needs a jar file to compile however I know I am going to include that EJB project along with others in my EAR project. I might want to place some of the jars that are shared by EJB projects at the EAR level rather than the EJB level to reduce the size of my overall EAR. We might have 2 EJB projects and 2 WEB projects that use a common frameworks jar and we would want to include that jar in the EAR but not in the Web or EJB projects.
Along those same lines I would like to see more flexability in selecting which jars go in my Web App as well for the above stated reasons.
I hope this is clear but if not feel free to post here or contact me at scott@theryansplace.com or (303) 263-3044.
Scott Ryan
Yep, I agree with Scott here (not support 🙂 ).
Our structure is like this:
– 1 WEB project
– 1 EJB project
– 1 EAR project
– 1 utility project
– 1 model projectBOTH the WEB and EJB projects use the model+utility projects, thus they are dependent (Eclipse compile dependent) on these. If I understand what support-scott wrote correctly, the jars would be packaged with both the EJB and the WEB project, when instead (as we do now) we would like to package it within the EAR project.
Anders,
Sounds like how I would like it to work:
Workspace with 5 projects:
EAR PROJECT
EJB1 PROJECT
EJB2 PROJECT
WEB PROJECT
COMMON PROJECTI would like the .ear file to contain:
ejb1.jar, ejb2.jar, web.war, common.jarEach ejb jar file and web war file should contain pointers to the common.jar in their class-path. I would also like the ability to say ejb1 needs common and ejb2 does not so only update ejb1’s class-path. I would like similar functionality for external jar files (log4j, struts, etc…)
Just to pitch in my 2 pence…. I’m with the last two posters. In fact, I’d almost go so far as to say that the defacto standard (at least when EAR’s are involved) is that all util jars go at the top level of the EAR file.
It looks like you’ve already got the WAR file deployers covered, so it’s just a matter of providing additional configuration options for EAR projects that will contain util jars….
