- This topic has 3 replies, 2 voices, and was last updated 18 years, 4 months ago by
.
-
Posts
-
I would recommend the ability to add custom “capabilities” and not just make do with the supplied ones. At least provide an API for other developers to provide custom capabilities. Even if ME is too busy or doesn’t see the value of XYZ plugin or support — at least the community and/or market place can make the needed adjustments. I hate to ditch a perfectly good tool just because it doesn’t support one or two libraries/features.
For example, I would like to have a new tab for MyFaces 1.1.3 and not mess up my existing/supplied version. For new features, it would be nice to add capabilities like Facelets and Tomahawk/Tobago support. I understand that one cannot expect to drop in the sexy wizards and auto-complete stuff that comes will full feature support — but at least some type or level of support would be nice.
If money’s an issue, just add it to the “pro” version. I’ll poney up for it. 😀
I hate to ditch a perfectly good tool just because it doesn’t support one or two libraries/features.
Given that you couldn’t code complex tasks for the capabilities even if we opened it up, how would this be any different than just adding pre-defined user libraries to your build path? Most times this is exactly what our wizards are doing in addition to adding custom natures to your .project file and some metadata information to the project so the specialized Editors can handle the content from those project types. So assuming you weren’t going to code editors and wizards for a special custom project type, the only step left that you would be trying to do is add custom libraries to your build path, which you can do now. (Maybe I’m misunderstanding your use case?)
For example, I would like to have a new tab for MyFaces 1.1.3 and not mess up my existing/supplied version. For new features, it would be nice to add capabilities like Facelets and Tomahawk/Tobago support. I understand that one cannot expect to drop in the sexy wizards and auto-complete stuff that comes will full feature support — but at least some type or level of support would be nice.
So given that you can do this already with user libraries, is it just the idea that all your libraries would be organized under “Project Capabilities” that appeals to you so it’s all centralized? Or is it just the ability to add/remove libraries from your build path?
OK, I understand what you are saying. I’m looking for more of an organizational/integration type solution. Even if what actually happens “under the hood” is no different than what you can do now — it makes it easier for us to tell the junior guys to just “click on Add XYZ Capabilities” to your project and ME will do all the needed library imports and packaging for you. For fancier stuff that needed a dialog box or wizard, one could use an API if one was provided.
One of our biggest problems it seems in the Java community is that we spend a great deal of time fighting with our IDE — well besides xml configuration file hell.
