[KionCineca]

MyEclipse 20050829-4.0.0-GA
Eclipse 3.1.0
OC4J 10.1.3 developer preview 4

My workspace is composed by several projects, which have their own META-INF folder.
There is an Enterprise Application Project which references a Web Project and an EJB Project.
The EAR project is deployed to OC4J.
In the MyEclipse-EJB configuration tab, the option “Merge into EJB output folder” is selected.
When the EAR archive is created, the META-INF directory of the EJB JAR does is not the right one.
In fact, MyEclipse doesn’t choose the “right” META-INF directory (which should be the one of the EJB project), but it takes the META-INF directory of another project.
The only one solution is deleting all the META-INF directories of the other projects, except the one of the EJB project; in this way there’s only one choice and obviously that’s the right one.

[Riyad Kalla]

KionCineca,
Please describe the project build relationships you have setup. For example, does the EJB project rely on any Java projects in it’s build path? Also where is your META-INF directory? Is it in your /src directory, or in the root of the project?

[KionCineca]

Hi,
I’m KionCineca (which is my office account), now I’m using my home account; I hope that this is not a problem.
The EJB project relies on several java projects in the build path and they have their own META-INF directory. These META-INF directories must all be deleted, because their presence cause the error which is described in the preovious message.
For all the projects, the META-INF directory is in /src.
Thanks in advance.

[Riyad Kalla]

Ok, so your setup looks something like this:

EJB Project: src/META-INF (good dir)
Java Project 1: src/META-INF (bad dir)
Java Project 2: src/META-INF (bad dir)
Java Project 3: src/META-INF (bad dir)

And when you deploy EJB Project, the only META-INF dir you want kept, is that one, but the META-INF dirs inside of the Jva Projects are still being maintained inside of the packaged JARs that represent each project. Is this an accurate description of the problem?

[KionCineca]

The situation of the projects that you’ve depicted is right, BUT I use this configuration option:

Project Properties/MyEclipse EJB

“Dependent Java Project Deployment Policy” = “Merge into EJB Project output folder”

So “Java Project 1”, “Java Project 2” and “Java Project 3” are not packaged as JARs, but their classes are all inside the EJB Jar.
The problem is the the META-INF directory of the EJB JAR is not:

EJB Project: src/META-INF (good dir)

BUT MyEclipse takes (for example):

Java Project 2: src/META-INF (bad dir)

Suppose that Java Project 1 has the following structure:

src/META-INF/Manifest.MF
src/META-INF/JavaOneResource.properties
src/it/kion/Foo.java

And EJB Project contains:

src/META-INF/Manifest.MF
src/META-INF/EJBResource.properties
src/it/kion/Bar.java

EJB Project relies on Java Project 1. This is the content of the generated EJB JAR:

META-INF/Manifest.MF
META-INF/JavaOneResource.properties
it/kion/Foo.class
it/kion/Bar.class

MyEclipse must decide which META-INF directory has to be included inside the EJB JAR and the wrong one is taken.
Thank you very much for your help.

[Riyad Kalla]

Hmm yes I see the problem, MyEclipse, when using the “merge” deployment option, simply copies the resources from your dependent projects ontop of the resources in the main project. So likely the META-INF dir of the last project listed for the EJB as a dependent project is the META-INF dir you are ending up with. However this isn’t a bug, this is how the deployment tool was designed.

I will ask if there is a workaround for you at this time to one of the developers.

[KionCineca]

Ok, it’s not a bug, but a nice improvement to the deployment tool design could be this (according to me): if dependent Java Projects have a META-INF directory, the META-INF directory of the EJB Project should have the prcedence on the other project.

Thank you very much for your help and assistence.
I wait for your suggestions.

[Riyad Kalla]

tassoc,
I agree there is room for improvement here, out of curiosity why do you need individual META-INF dirs in each of your Java Projects?

[KionCineca]

Well, your question is very good. More than one META-INF directory would be necessary when dependant projects are packaged as JARs, and the JARs are included in the EJB JAR.
But, development world is not always so simple and I’m a very unlucky developer. 🙂
Let me explain.
Our software factory is developing an application using a framework which is not developed by us, but it’s currently developed by the italian division of IBM.
We use MyEclipse as IDE and OC4J as AppServer.
The framework is developed using WebSphere develpment tools.
We have the sources, but we can’t modify them. Our EJB projects rely on the framework projects.
Each framework projects contain a META-INF directory
Every time we make the checkout of the framework sources (which happens frequently, because there are many revisions of the framework), we must manually delete the META-INF directories.
Yes, I know that I could automate checkout and deleting, BUT I would be happier if my development tool would be so smart to understand which is the right META-INF directory.
I hope that your curiosity is satisfied.

Thank you very much for your support.

[Scott Anderson]

Yep, that answers the question quite well. Here’s another idea. Since you can’t modify the source of the dependent projects anyway, how about jar’ing them into your EAR and allowing your EJB projects to reference the common copy? You can do that by making your EAR project dependent on the Java library projects and then setting Window > Preferences > MyEclipse > J2EE Project > EAR Project > Jar dependent java projects. That will create jars of the libraries and place them in the root of your EAR project at deployment. You can then have MyEclipse update your module manifests so you can use them by right clicking on the EAR project and selecting MyEclipse > New Module Manifests. More information on how to set this up is in the Advanced section of the Enterprise Project quickstart in the Documentation section here: http://www.myeclipseide.com/ContentExpress-display-ceid-67.html
The last step is you’ll need to reset your EJB projects so that it ignores dependent projects on deployment, rather than merge them, since you’ll now be using the common libraries in the EAR.

[KionCineca]

If I use the procedure that you are suggesting to me, is it still possible run-time synchronization of source code modifications with the compiled code?
When I’m running OC4J in debug mode, I can modify the source code, save it and (without restarting the server) I can immediatly see the changes I made in the running application.
If I use the deployment strategy that you depicted, does this extremly useful feature still work?

Thank you very much for your support.

[Scott Anderson]

If I use the deployment strategy that you depicted, does this extremly useful feature still work?

Yes, and no. 🙂 Here’s what will happen. When your application is running and you modify your Java classes and save them, the debugger will still hot sync the classes to the running server application in memory so you’ll be able to see your changes immediately. However, what will *not* happen in this model is updating your remote deployment physically. What I mean is that the deployed jar file will not be updated with the new code and the deployment will become “out of date”. The reason for this is that rejaring and deploying for each code change would be prohibitively expensive so entire jars are never recreated automatically. What this means to you is that your application will continue to update while you edit your code, but if you shut down the server and restart, your original application state will be restored because the deployment was only changed in memory, not on disk. In short, if you shutdown the server you’ll need to manually hit the ‘Redeploy’ button in the Deployment Manager dialog to update deployment before restarting the server.

[Author]

Posts