- This topic has 10 replies, 5 voices, and was last updated 18 years, 3 months ago by
.
-
Posts
-
I have 3 or more Tomcat installations on my box. Each one associated with a different Eclipse project. I stop/start Tomcat as I am running/debugging/testing in a given project context. What would be nice is if Eclipse could maintain separate configurations for each app server instance. As it stands now, each time I want to switch projects, I have to edit my application server configuration and point the one configurable instance to the configuration settings of the instance I am wanting to run. Having separate configurations that could be configured controlled independently would be nice.
I am running 5.0 M2 on Eclipse 3.2 RC7.
Thank you.
You can do that now, guide here:
http://jroller.com/page/myeclipseblog?entry=creating_a_custom_launch_configurationForgive me, but the “Custom Launch Configuration” seems a little ass-backwards.
In and of itself, if you have a single instance of a server on your machine, then the custom configurations can be a help with managing starting the server with differing environmental variables or such for integration and configuration testing for a single project. When faced with several projects like rtulloh above, creating launch configurations becomes a bother simply because it does not work the way you’d expect it too.
1.) If you want to target a second or more installation of the same server type, each for a different project requiring differing libraries installed in the server itself – not just command-line or argument configuration fragments, you have to rewrite almost every line in the custom configuration to target the new server. Why not just allow a right-click on the server type in the “MyEclipse–>Application Servers” to add a new entry in that list targeting the new location?
2.) I’ve created custom launch configurations – they don’t put themselves in the “Run/Start/Stop MyEclipse Application Servers” drop-down list on the button menu. What’s the use of that button if all you can target are the main server configuration names and not the custom configurations developers will actually be using?
3.) You cannot change whether or not a custom configuration runs in debug mode or not. Granted, this isn’t that important, but it would help if, say, you were running three JBoss Cache servers and were interested in attaching to only one of them for run-time debugging.
4.) Ok – you’ve created a custom launch configuration. Now try to target it with a deployment configuration. Oh wait – you can’t. If I missed something and you actually can target one, then it’s definitely in the wrong place because it’s not in the first place anyone creating a custom deployment will look – in the custom deployment wizard.
I am probably missing more quirks, but these are the ones sticking in my craw right now. Are these problems being “looked at” or do they {cringe} “work as designed”, in which case you may show me to the source code where I can fix it.
astrien,
We have to back up a second and explain the motivation behind the current implementation.What we originally intended for 5.0 to do was still offer our connectors and launch configurations as a legacy mode and fully adopt the WTP connectors. Unfortunately the WTP connectors and deployment model wasn’t where we needed it to be, so we didn’t adopt them at all. We had a lot of users requesting the ability to fire up multiple configs of the same app server so we addressed that issue temporarily until the WTP model gets where we need it to get, so implemently an expensive/timely full solution to the problem doesn’t make sense as the writing is on the wall that at some point (WTP 2.0?) we plan on augmenting what we have now with what WTP will provide to futher normalize when it’s available.
When we designed it, the current solution seemed to fill the bill for the handful of users that needed it, based on their usage scenarios in other posts. However, with the additional 5.0 features, like the Servers View, proper integration is definately lacking as you’ve outlined.
So, the server launch configurations provide the capability that were planned for the 5.0 release. But, please know that this was a “first cut” and we plan on enhancing the capabilities in subsequent releases to address the shortcomings you’ve listed. It wasn’t that we didn’t think of them, it was simply that we were over committed on the 5.0 timeline and we didn’t have time to fully tie everything in as well as we would have liked. We will get to it, however, just like we incrementally improve everything in the toolset with each release.
That wasn’t a poor answer at all, and it’s one I can undestand fully. Another question does present itself, however. Should we (I will humbly speak for all other developers for a second here) assume that any functionality currently being addressed by the WTP which duplicates functionality in MyEclipse will surplant the MyEclipse version at some point? And leaving that thought aside, is there somewhere where I could have read about what you describe above so that I’ll know when I can take the devs to task and when I would be wasting time – mine and yours? The roadmap doesn’t exactly declare which features are near EOL and whom will be taking their places.
Astrien,
Thank you for taking the time to give us some constructive criticism on the limitations of the new Launch Configuration feature we just added for our servers. I’ll try to help out and give feedback / workarounds to the issues you raised specifically.
1.) If you want to target a second or more installation of the same server type, each for a different project requiring differing libraries installed in the server itself – not just command-line or argument configuration fragments, you have to rewrite almost every line in the custom configuration to target the new server.
That’s one way to do it. Or, you could reconfigure the preference page then hit Create Launch Configuration and have it generate a correct one for you. Then, repeat that process for each custom server. Think of it as a form that acts like a factory for server launch configurations. That way, hand editing should be minimal.
Why not just allow a right-click on the server type in the “MyEclipse–>Application Servers” to add a new entry in that list targeting the new location?
That would require effectively generating and laying out a preference page in memory and saving its state persistantly. Unfortunately, doing this dynamically in Eclipse is far from straightforward and actually may not even be possible since preference page generation is done by the internal (ie. not for public use) frameworks when extension points are read.
2.) I’ve created custom launch configurations – they don’t put themselves in the “Run/Start/Stop MyEclipse Application Servers” drop-down list on the button menu.
No, but you can add them to the Debug button’s dropdown menu in the main toolbar, if you like. However, I can see that this would be a nice enhancement and filed it as such.
3.) You cannot change whether or not a custom configuration runs in debug mode or not. Granted, this isn’t that important, but it would help if, say, you were running three JBoss Cache servers and were interested in attaching to only one of them for run-time debugging.
That’s true. Currently you have to set the Run/Debug option at the time you create the launch configuration.
4.) Ok – you’ve created a custom launch configuration. Now try to target it with a deployment configuration.
You’re absolutely correct because the original usage scenarios were for starting the same server instance in different configuration (ie. with or without security enabled). They weren’t really designed to support 9 unique instances of Tomcat 5, for example. However, this is a reasonable grow area for them and enabling deployment for them under that scenario would naturally make sense. I’ve filed that as an enhancement request as well.
Another question does present itself, however. Should we (I will humbly speak for all other developers for a second here) assume that any functionality currently being addressed by the WTP which duplicates functionality in MyEclipse will surplant the MyEclipse version at some point?
We’ve got a representative in the WTP Requirements group and work toward driving the project in a direction that makes it possible for us to more fully adopt various features, but only once we believe that it has reached parity with what is provided already in MyEclipse.
And leaving that thought aside, is there somewhere where I could have read about what you describe above so that I’ll know when I can take the devs to task and when I would be wasting time – mine and yours? The roadmap doesn’t exactly declare which features are near EOL and whom will be taking their places.
Strangely, I could no longer find our original design document on the WTP website. I don’t know if that’s because it was removed or what, but I’ll attach it here since you’re interested.
Thank you for posting the document. Having access to this kind of information is helpful. I agree with all the comments made by astrien above and appreciate your taking the time to explain what is going on and what we can expect going forward. Keep up the good work!
Assume another solution to this is you could create separate workspaces for each project/server combo. Obviously that makes it difficult to switch back and forth between projects, but at least you can run separate servers this way….
Craig,
Actually, that’s a very interesting idea. Particularly if you don’t save the projects themselves in the workspace directory (which is the default). If you create a new workspace, you can “Import existing projects” and *not* copy them into the workspace directory. That will leave the projects in a central shared location, but all the workspace state will remain associated with and saved in the workspace. With this method, you could do as you suggest and easily share projects between workspaces for different testing scenarios.
