- This topic has 21 replies, 7 voices, and was last updated 11 years, 10 months ago by
.
-
Posts
-
I recently needed to create an EAR for my web application so I could take advantage of virtual hosting provided with JBoss/Tomcat.
Previously when I deployed WARs to Tomcat I was able to specify the context name, which was used for exploded deployments but I needed to edit the .mymetadata file to change the archive name for packaged views so it used the context name as the archive name rather than the project name as the archive name. This worked well for me.
Now that I am deploying EARs I am running into the same problem only I cannot change the default name of the either the exploded or archived EAR. The default for EARs is to use the project name. As with the WARs I edited the .mymetadata file to change the EAR archive name to something more appropriate but MyEclipse will not use the archive name I specify either for exploded or packaged deployments. In addition, I needed to modify the EAR .mymetadata file to change the included WAR archive name, otherwise MyEclipse would use the Web project name, this does work. To get around the problem with the EAR I am exporting it to my application server rather than deploying it.
I read through the forums and it seems that users have been complaining about this for several years, at least as far back as 2004.
I am sure this convention may have been adopted to provide defaults but could you also provide the ability to override the default, either by using the values specified in the .mymetadata file, or better yet, providing some screens in the project properties that allow modifying the values. I do not want to name my projects something more cryptic than verbose because the tool I use cannot handle it when it comes time to deploy.
I also just thought of another thing. When setting up web projects to include library projects it would be nice to specify the JAR name that is included in the web projects WEB-INF/lib folder. Right now MyEclipse uses the project name converted to lower case.
You are right that the first issues *is* a feature we have been needing to add for a long time, but keeps getting bumped for higher priority items. I’m going to add your comments to the issue and see if we can bump it up. I’m really sorry about this inconvenience.
Developing this feature would really help using MyEclipse for deployment. The way I set it, Eclipse in general is not well suited to making deployments without the assistance of some other build tool, like Ant. MyEclipse brings some new features to support the development life-cycle, the biggest to me is brainless debugging my web app in the app server of my choice. However, there is a gap between using Eclipse for development and for deployment. Within MyEclipse you need to setup your web application source as if you were editing the deployment in place. This is a major drawback and the reason you need something like Ant.
If I have code that changes by environment I cannot swap the code I want in and out of my source tree, well becasue, it needs to be in the source tree as it is source. I have gotten around this using custom Spring placeholder classes and custom context loaders that are environment specific. Using these custom classes I only need to create one build for all environments and then only specify a environment discriminator so that the application only uses properties and context files based on the current environment.
The problem I still have is building different versions of the same source for distribution in dependent projects. For example, my services project provides a well defined interface for clients and the complete implementation of that interface. When deploying the service as a POJO I need to JAR the entire project. When deploying it as a remote service, I only need to deploy the interface. Right now I am forced to deploy the entire service project in all usage cases. The only way around this, that I can currently foresee, is to split my service interface out into its own project. This would allow me to use Eclipse dependencies as I do now at a more fine-grained level (fine-grained here using boulder sized grains).
Let me use those immortal words of death, “It would be nice if…” MyEclipse dependency management was more configurable. I know I have the manual option but I am addicted to the deployment button. I know I can still debug in MyEclipse even if I use Ant to deploy. It just seems like a disconnect to use both Ant and MyEclipse for deployment. I guess Ant would actually give me the added deployment flexibility but then I would basically need to stop using the deploy button.
In the end I guess there are enough ways to get around this issue. However, the ways things are now just feels wrong to me.
+1 for this feature request. It hasn’t been a big deal in previous projects that were smaller and simpler, but we’re working on some more EAR projects and not being able to control the archive name is a headache. Particularly since JBoss uses the archive name as the prefix for the JNDI name of EJBs it deploys.
IronDuck, management marked it for 6.1 and I’m going to try and sit on someone’s head until it gets done if possible.
Can we get an update on how well the head-sitting went? I found a related bug just recently. If a project name contains a period (.) then MyEclipse does not append .ear or .jar or .war to the directory/archive when it performs a deployment. This causes the deployment to fail on JBoss. Our convention is to include the version in the project name (e.g. My Project 1.0) so this is a major issue for us.
IronDuck, I just checked our issue tracker and management has targetted it for 6.5 because I threatened to drown myself in my coffee, if it gets descoped I’ll let you know but I really want to get it in if I can.
I don’t see any obvious way to specify the archive name when deploying in 6.5M1 🙁
Did it get descoped?
It’s still scoped, but I don’t know if it will make the cut or not. The Maven2 work going into the 6.5 release is touching all aspects of packaging, building and project deployment which this change touches as well; management might push it off to focus on the Maven changes exclusively for 6.5 to keep changes more manageable at this point. We also have the GA release in a few weeks to get ready.
Well, I’m glad to hear that you haven’t had to drown yourself in coffee, but I would very much like to see this feature sooner rather than later. I had to put a whole bunch of ant nonsense in my last project to be able to build for deployment and still let MyEclipse do it’s thing on the development side.
