Feedback on enterprise application development is needed!
Hi All,
We really need your feedback on all aspects of enterprise application
development in IDEA. This includes (but not limits to) development with
J2EE platform, various J2EE-related frameworks (Strungs, Hibernate,
Spring, etc.), web services and so on.
We would like to here every idea/problem/annoyance you can think of. You
can even just post links to JIRA issues, if there any, which are most
relevant for you. If you can say just "I wish you had..." it's also ok
for us.
In order to make all you wishes/discussions more categorized I'm posting
additional sub-topics for this message with narrower scope. Please post
all your ideas into them. (The discussion of this post should be
obviously done right beneath of it).
While we can't promise to implement every feature/idea you'll mention,
we will read and analyze every post. Let's shape the future IDEA version
together!
Please sign in to leave a comment.
I would say JSF first.
I'm sure there are more ongoing Struts projects right now, but I hope and believe there are more JSF projects developed from scratch today than Struts, and that's where IDE support will give most benefits.
Better handling of resource files in modules.
Currently IDEA does not allow resource directories, only resource patterns in source folders
Also, the current setting is per project, which is clearly not enough in projects with many modules.
What I would like to be able to do:
1) Define a directory, where all of the files are handled as resource files
2) Define those directories just like source/test source directories
3) Separate test-resource directories
4) Maybe allow following style resource patterns in current system: .\.((?!java).) <--Match anything but *.java
+1 for Spring
+1 for Hibernate
Also, do a check in common locations relative to a library to add the src and doc/api for that library. This would be great as part of the module wizards when setting up a new project.
Not yet. We want to use JSF, but it does not appear mature enough.
Hopefully, all the problems will be worked out by J2EE 5.
What about all the code that is out there that uses Struts now. That
code isn't going anywhere anytime soon. It still has to be supported.
Sakke Wiik wrote:
>
Geronimo integration would be really worthwhile for me
O
On 2005-10-07 14:58:10 +0200, "Mike Aizatsky (JetBrains)"
<mike.aizatsky@jetbrains.com> said:
+1
TH> http://www.jetbrains.net/jira/browse/IDEA-1651
TH>
On request of Mike Aizatsky I'm reposting my original message from topic
"IDEA Roadmap (esp. Java EE 5)?" here (with a few additions and
corrections):
Could you please at least provide extensions/fixes (it should only be disabling some validations (?)) for the packaging problems with some of the next EAPs? This would mean (at least): 1) Being able to package arbitray archives into an EAR, either flagging them as "main" or "library" ("main" would be J2EE archives which are "deployed") - libraries should optionally go into a special subdirectory (the new "library-directory") - mainly needed for .par (and .rar?) - this would bring compatibility with both Java EE 5's "library directory" as well as Weblogic's proprietary "APP-INF/lib" (if I remember correctly it uses this as "fixed" library-dir) A request for "packaging arbitrary archives" already exist (in support of RARs) in JIRA (http://www.jetbrains.net/jira/browse/IDEA-4866) - only added the main/library flag request here. 2) Package the libraries a "main" module depends on (optionally) directly into the EAR (as explained in (1) optionally into a subdirectory of the EAR), (again optionally) enter them into the "main-module"'s jar manifest.mf (as Class-Path entries) ]]>this is specified in both Java EE 5 and J2EE 1.4 spec and
works with many (if not all) J2EE 1.4 application servers.</addition>
3) (For now) Allow to remove even "mandatory" DD's (e.g. "ejb-jar.xml")
without IDEA automatically re-creating them - the only workaround
currently seems to be renaming it (to e.g. ejb-jar-dummy.xml), IDEA
seems to "dislike" this, however (some strange behavior, flagging
modules red, no more showing their content in J2EE view etc.)
4) Optionally at least show classes flagged with @Stateful, @Stateless
and @MessageDriven in the J2EE view as EJBs (would be a first, major
step to Java EE 5 "support" - J2EE view useful again)
5) Even a step further would be introducing the .par archive (by icon
and by showing it in J2EE view with @Entity annotated classes shown as
beans)
These would be the first steps to make IDEA useable for Java EE 5
development, most other things ("better support") would really be
optional since IDEA's default, great sourcecode editing capabilities are
sufficient (most times) - except support for EJB3 XML-DDs of course.
Is it possible to include these features in one of the next EAP builds,
maybe as an optional plugin - it would really help us further using IDEA
without needing to wait for "full" Java EE 5 support - also I guess
these things should be implementable (at least in alpha/beta quality,
i.e. "untested"/EAP) in a day or so (for someone who knows the specific
points in sourcecode) and would save us lots of time (probably more than
a day in three or four days ;) - if I can, I'll gladly help!
</MESSAGE>
"Factoring out" things related to a partial or full EJB3 implementation
only points 1 and 2 are "real" feedback/RFEs, i.e. I'd specifically
request enhancements to the packaging system that are not only
necessary for JEE 5 but would also be very useful for J2EE 1.4
development.
As an addition (not sure whether this is the right sub-thread, but think
so) it would be great to be able to automatically convert modules from
one type to another - at least we should be able to convert a "normal"
(Java) module to a "special" one (e.g. EJB module), which should be
rather easy (so that, when I create a "normal" Java module "now" to
develop a JCA RAR or EJB3 JAR, I can later convert to an archive of this
specific type without re-creating the module manually).
kind regards,
Messi
I'm currently working on a geronimo integration plugin. If everything goes as expected a first preview version should be available in a couple of days.
+1
On 2005-10-12 23:12:56 +0200, Martin Fuhrer <mf@fuhrer.com> said:
>> Geronimo integration would be really worthwhile for
>> me
that's great to hear ;) thanks!
It is now resolved as "Fixed"!
I can't wait for it to be made available...
Venkat Sonnathi wrote:
Recycling....
I'd like to see Spring + iBatis SQL Maps.
Not that I am advocating that particular setup, but I am currently on assignment at a site
that has chosen to use StrutsSpringiBatis SQL Maps and it would be nice if my favorite IDE
supported it.
Eclipse like "Problems" view, listing project wide problems continuously and automatically without having to run inspection analysis.
It should be available in next 5.0 EAP build.
fix the little details.
would be enough for me for IDEA 6.0
rememeber often the last 1% takes half of the time :)
example: create new ant target from intention: add the closing tag instead of ]]>
Even as someone who's never used the API, this is something that makes me
scream in frustration every time. It just seems like it has to be obvious
that prioritising plugin development has to be critical. There is always
going to be more development ability in the community than within
JetBrains, and IDEA will suffer (and is suffering) for not leveraging that
potential or for making it difficult to do so. This is the one area where
Eclipse really has the advantage. Lots of the plugins are crap, but lots of
them aren't, as well.
Robert Sfeir wrote:
lots of good stuff about Spring XML
A lot of the work going into supporting this would also be reusable for JSF,
I imagine. +5
Whew.. too many messages to read through and see if this has already been mentioned.
1. I would love to have refactoring consider Spring files. For example, if I rename a property (getter/setter pair), then rename all references in my Spring configs as well. Same with other refactorings (rename class, delete, etc).
2. I would also love to be able to ctrlclick or ctrlB over a bean ref and jump directly to that bean.
3. While I'm at it, I would love for IDEA to highlight errors in red (no such bean, no such property, etc).
For IDEA to support ctrl+B and the like, it will obviously have to provide some way for me to group a set of Spring .xml files together into a single unit (since my Spring configs tend to be spread across several files).
So Spring is supported?
here's an old backlog for spring support:
Also, there's a Spring plugin started already, maybe incorporate that as a start...
http://www.jetbrains.net/jira/browse/IDEABKL-2804
copied comments:
1. Refactoring support - renaming of properties being the most blatant, since you can sort of have class renaming (search in strings). Method and constructor changes would go in here.
2. Usages indications - maybe an "injected" category, with navigation to the class it's injected into, as well as the application.xml, or from an class that has multiple injections to each injection class (similar to interfaces and their implementations navigation).
3. Documentation - BeanDoc has a good start on that, maybe a dynamic generation of it, or parts of it. http://opensource.atlassian.com/confluence/spring/display/BDOC/Home
4. Java to spring - right click a class (or property), and generate the xml stubs for injecting implementations, maybe tab targets for each injection point.
5. Inline/extract bean definitions - Spring has inner/anonymous beans
6. Also, refactoring/wizards like making a bean definition automatically into a TargetPool, where the original class is "wrapped" with a pooling implementation or proxy.
I'll come up with more tomorrow, when I have some free time.
--pete
reposted from above, under the right thread...
here's an old backlog for spring support:
Also, there's a Spring plugin started already, maybe incorporate that as a start...
http://www.jetbrains.net/jira/browse/IDEABKL-2804
copied comments:
1. Refactoring support - renaming of properties being the most blatant, since you can sort of have class renaming (search in strings). Method and constructor changes would go in here.
2. Usages indications - maybe an "injected" category, with navigation to the class it's injected into, as well as the application.xml, or from an class that has multiple injections to each injection class (similar to interfaces and their implementations navigation).
3. Documentation - BeanDoc has a good start on that, maybe a dynamic generation of it, or parts of it. http://opensource.atlassian.com/confluence/spring/display/BDOC/Home
4. Java to spring - right click a class (or property), and generate the xml stubs for injecting implementations, maybe tab targets for each injection point.
5. Inline/extract bean definitions - Spring has inner/anonymous beans
6. Also, refactoring/wizards like making a bean definition automatically into a TargetPool, where the original class is "wrapped" with a pooling implementation or proxy.
I'll come up with more tomorrow, when I have some free time.
--pete
please don't tie us down to one stack, like axis. Let us chose. There are others, like xfire, activesoap, jibxsoap, jax-ws...
--pete
+1
We're using XFire right now...
Tobin
Andy DePue wrote:
This is pretty much what the idea-spring plugin does, I think...
besides the property-refactoring, that is, and it would be very nice if
the integration between the plugin and IDEA could be tighter.
I guess there are limits to what you can do with the current OpenAPI - I
very much agree with what has been said in one of the other threads:
more and beter documentation of the OpenAPI, and more functionality of
the OpenAPI itself is far more important than functionality like this in
the core of the product.
Peter Morelli wrote:
This already accessible in 5.0.2 eap builds.
--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
Performance and stability of deployment of J2EE applications would be a good start.
JIRA entries that impact us currently, from a J2EE perspective:
- http://www.jetbrains.net/jira/browse/IDEA-4321
- http://www.jetbrains.net/jira/browse/IDEA-4444
- http://www.jetbrains.net/jira/browse/IDEA-4839
- http://www.jetbrains.net/jira/browse/IDEA-5078
- http://www.jetbrains.net/jira/browse/IDEA-4345
- http://www.jetbrains.net/jira/browse/IDEA-208
- http://www.jetbrains.net/jira/browse/IDEA-4277
- http://www.jetbrains.net/jira/browse/IDEA-5455
Dmitry Jemerov (JetBrains) wrote:
For a start, this one is 100% reproducible and probably easy to fix as well. Yet it's
still around since the early EAP 5.0 days:
http://www.intellij.net/tracker/idea/viewSCR?publicId=55417
Sascha
Just want to add my two cents in support of EJB3 persistence
annotations.
You would enhance both the EJB3 support and the stand-alone
Hibernate support with a single new feature.
We even use annotations now with the Hibernate release candidate
and have not found any issues with the implementation.
Without any better support in Idea, it's just troublesome to
prevent any typos in the field/property references.
Then if you start to refactor classes you have to adjust all
property references yourself - oh my that feels like stone age.
This will be one of the first Demetra features.
Stephen Kelvin wrote:
--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"