Open-Source Integration

It is hard enough to keep up with rapidly evolving Java specs, so I do not expect IDEA to keep up with every open-source tool that comes out. Then again, some open-source tools emerge (e.g. Spring, Hibernate, Facelets) that become so popular that support would be a huge convenience.

I am aware of the Plugin API, but I wonder if there is some fervor for a mechanism support for open-source tools. Perhaps if x number of licensed users vote for something then it could be a feature in the next release. Is such a thing plausible?

Thanks.


19 comments

Hello Neil,

NC> It is hard enough to keep up with rapidly evolving Java specs, so I
NC> do not expect IDEA to keep up with every open-source tool that comes
NC> out. Then again, some open-source tools emerge (e.g. Spring,
NC> Hibernate, Facelets) that become so popular that support would be a
NC> huge convenience.
NC>
NC> I am aware of the Plugin API, but I wonder if there is some fervor
NC> for a mechanism support for open-source tools. Perhaps if x number
NC> of licensed users vote for something then it could be a feature in
NC> the next release. Is such a thing plausible?

We definitely take user feedback into account when planning features for
new versions of IDEA, but I'm afraid that a strict mechanism "X votes means
that a feature will definitely be implemented" is not possible. The license
of a tool which can be supported by IDEA (open-source or commercial) is not
a factor at all in our decisions to implement support for it.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

In that case, where can a user provide meaningful feedback? I believe, for example, that Spring support would be really useful, and I doubt too many developers out there would disagree. How does the analysis work among the IDEA developers as far as deciding what tools to support? How difficult is it to implement Spring support in future releases?

Thanks for the prompt response. I know you are very busy.

Neil

0

One of the problems of investing in directly supporting such
libraries/frameworks/toolkits is that there are just so many of them and
they come and go very frequently.

Personally I value the core support for Java and generic technologies
that have proved to be stable and evolving (XML, JavaScript, Java, HTML,
application servers, JUnit, etc.), and not turn JetBrains into a large
organization that chases the trend of the day.

I'll give you an example from our application - We use a rich web UI
toolkit called Bindows. It allows for a UI that is as complex and
identical to Swing, MFC, Delphi, etc. UIs on all accounts -
communication, layout, widgets, server abstraction, etc. I don't expect
IntelliJ to directly cater for Bindows, but what I did request (and got
fulfilled) was JavaScript and XML support (which Bindows and Bindows UIs
are written at), in 5.1 and Demetra. Now our development is greatly
streamlined not because JetBrains put X people to implement stuff for
Bindows only (making IntelliJ Bindows-version dependent, etc.) but
because IntelliJ now supports the real core technologies we use in our
application - Java, JavaScript and XML.

Once you start implementing direct support for all kinds of specific
components you have to draw the line where you start getting diminishing
returns.

Having said that, I am sure that JetBrains will have more incentive to
accommodate general needs that would augment your Spring experience too,
as those would fortify the overall strength of IntelliJ (and not just
for Spring) rather than create a tentacle of functionality (which is
what's plaguing a lot of IDEs and applications in general).

Amnon I. Govrin
Tech Lead Enterprise Development
Webroot Software

Neil Chaudhuri wrote:

In that case, where can a user provide meaningful feedback? I believe, for example, that Spring support would be really useful, and I doubt too many developers out there would disagree. How does the analysis work among the IDEA developers as far as deciding what tools to support? How difficult is it to implement Spring support in future releases?

Thanks for the prompt response. I know you are very busy.

Neil

0

I agree completely with Amnon's statement.

However, note that IDEA 5.1 (my copy, anyway!) has already got what I think is excellent Spring support anyway, for which I am grateful.

The Hibero plug-in for Hibernate is very nice, too, worth the extra $50 in my view.

If companies like Beto can produce specific 3rd party plug-ins of this quality for popular open source libraries like Hibernate, I am pleased to support them.

John Hurst
Wellington, New Zealand

0

Point taken, Amnon. But you might have missed my first statement:

"It is hard enough to keep up with rapidly evolving Java specs, so I do not expect IDEA to keep up with every open-source tool that comes out. Then again, some open-source tools emerge (e.g. Spring, Hibernate, Facelets) that become so popular that support would be a huge convenience."

I am quite aware that IDEA cannotand indeed should notattempt to support every Tom, Dick, and Hibernate that comes along. However, there are some tools that become so pervasive that supporting them doesn't produce "tentacles of functionality" (nice metaphor by the way) but rather features that increase productivity and allow us to more quickly meet business objectives.

The key issue is to define the threshold between merely providing generic support for supporting technologies for some tool and providing full-fledged support for that tool because it is as widely used as a core spec. After all, it may just be possible that Sun's solution to a problem isn't the best, and IDEA is far more than a Sun vehicle.

Thanks.

0

In article <4405FC2C.7020808@jetbrains.com>, nomail@jetbrains.com
says...


Personally I value the core support for Java and generic technologies
that have proved to be stable and evolving (XML, JavaScript, Java, HTML,
application servers, JUnit, etc.), and not turn JetBrains into a large
organization that chases the trend of the day.

Spring meets that criteria and is certainly more core than javascript.
--
-


David H. McCoy


-


0


Don't confuse velocity with position.

Simply because it's the only dynamic language that ships with all browsers, JavaScript probably has 10% total programmer penetration. That's enormous. It may even be more than a third of of Java's ridiculous penetration (it is probable that more programmers are currently using Java than have ever used any language at one time, ever).

If 2% of programmers have even heard of Spring, let alone used it, I would be very surprised. <1% seems more likely. That's not saying anything bad about Spring, it's just too new and too ill-supported to have gotten the penetration. If IDEA never supported Spring (and it already does, to some extent), >97% of programmers would never even notice.

Other than Java, the only languages with more penetration than JavaScript are C/C+, HTML, SQL, and XML. VB comes close, C# does not. IDEA supports HTML and XML perfectly well. IDEA-level support of C/C+ would probably require strong AI (it's a much more difficult problem than JavaScript, and one of the reasons C++ will eventually die). IDEA-level support of SQL would rule the heavens, but has yet to be seriously attempted.

--Dave Griffith

0

IDEA-level support of SQL would rule the heavens, but has yet
to be seriously attempted.


http://www.agiledata.org/essays/databaseRefactoring.html


0

Hello Neil,

NC> In that case, where can a user provide meaningful feedback? I
NC> believe, for example, that Spring support would be really useful,
NC> and I doubt too many developers out there would disagree. How does
NC> the analysis work among the IDEA developers as far as deciding what
NC> tools to support? How difficult is it to implement Spring support
NC> in future releases?

This forum / newsgroup is a good place for providing feedback.

As for the difficulty of implementing support, many people request "support"
for this or another framework without providing any clarification on what
exactly support they mean. Some degree of support for Spring - namely, resolving
references and completion in Spring config files - is available in IDEA since
version 5.0.2. Does this qualify as "support" for you? If not, what else
would you like to have?

Without these details, it does not make sense to discuss how difficult it
would be.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

In article <83ca25fd2680638c80c166c352b20@news.intellij.net>,
yole@jetbrains.com says...

Hello Neil,

NC> In that case, where can a user provide meaningful feedback? I
NC> believe, for example, that Spring support would be really useful,
NC> and I doubt too many developers out there would disagree. How does
NC> the analysis work among the IDEA developers as far as deciding what
NC> tools to support? How difficult is it to implement Spring support
NC> in future releases?

This forum / newsgroup is a good place for providing feedback.

As for the difficulty of implementing support, many people request "support"
for this or another framework without providing any clarification on what
exactly support they mean. Some degree of support for Spring - namely, resolving
references and completion in Spring config files - is available in IDEA since
version 5.0.2. Does this qualify as "support" for you? If not, what else
would you like to have?

Without these details, it does not make sense to discuss how difficult it
would be.

Fair enough. I have noticed Idea's current support and it is very
helpful. What would put it over the top, without having to support every
nuance would be the ability to navigate both local and bean references
across files. The Idea Spring plugin takes a shot at this, but doesn't
seem to work consistent and doesn't appear to be under current
development. If I could ctrl-b on a file in one xml file and be taken to
a reference in another as well as get a red tick when a bean being
referenced in one file doesn't exist in another(misspelled, for
instance) I think that would solidfy Idea's initial moves.

Follow ups based on demand might be:
1) If you have a bean defined in a file with attributes 1,2 and 3, but
the java bean itself only missing say attribute 3, getting an intention.
A similar intention for an attribute that doesn't have getter/setters.

2)Bean able to navigate to a reference used in an Proxy interceptor.

3)Having the rename refactor rename attributes in a bean definition. For
example, if a rename an instance variable from foo to foo2, the bean
definition would have "foo2" in it.

4) Being able to refactor:extract definitions into a new xml file, or
refactor:move definitions to different files. Basically, make it as easy
to modify defintions as java code.

5) Intentions that all you to use Springs 1.2.x less verbose XML for
bean defs, like their Tiles like abstract definition.Can change them if
necessary.

6)Perhaps integrating that project that allows one to generate a diagram
of the Spring files.




--
-


David H. McCoy


-


0

In article <33325176.1141269142509.JavaMail.itn@is.intellij.net>,
dave.griffith@cnn.com says...


Don't confuse velocity with position.

Simply because it's the only dynamic language that ships with all browsers, JavaScript probably has 10% total programmer penetration. That's enormous. It may even be more than a third of of Java's ridiculous penetration (it is probable that more programmers are currently using Java than have ever used any language at one time, ever).

If 2% of programmers have even heard of Spring, let alone used it, I would be very surprised. <1% seems more likely. That's not saying anything bad about Spring, it's just too new and too ill-supported to have gotten the penetration. If IDEA never supported Spring (and it already does, to some extent), >97% of programmers would never even notice.

Other than Java, the only languages with more penetration than JavaScript are C/C+, HTML, SQL, and XML. VB comes close, C# does not. IDEA supports HTML and XML perfectly well. IDEA-level support of C/C+ would probably require strong AI (it's a much more difficult problem than JavaScript, and one of the reasons C++ will eventually die). IDEA-level support of SQL would rule the heavens, but has yet to be seriously attempted.

--Dave Griffith


Here's the thing. Spring is getting more popular. Bea offers full Spring
support, IBM has released quite a few articles, and will probably come
out with a similar statement of support. Oracle wrote the Spring Toplink
integration layer.

I think Spring will become as popular as Struts and Hibernate. I think
the Idea 5 web-support is great, but I think that maintaining the
appearance that Idea is "edgy" requires some due-diligence and support
for up and coming technology. Certainly not every framework, but when
one comes out that has made as much of an impact as Spring and Hibernate
has, I think you've got to have some type of support.

Things like JSF and Spring are, IMO, those next levels.
--
-


David H. McCoy


-


0

David you should try IdeaSpring 1.1.2 which gives you :

+ a red tick when a bean being referenced in one file doesn't exist in another(misspelled, for instance)

+ ctrl-b on bean id

+ auto-completion on bean and method references

+ Refactoring: inline bean

+ Refactoring : convert anonymous bean to named one

+ ...

And wait for 1.2 with :

+ QuickFix : create a new bean from an unknown referenced one
+ Intention : converts full form of value and ref elements to shortcut form
+ Intention : converts shortcut form of value and ref elements to full form if the bean referenced is local

- Refactoring : rename bean

- Refactoring : move bean

and more...


If you tell me what's inconsistent with IdeaSPring i can try to fix it.

0

In article <17552173.1141392552422.JavaMail.itn@is.intellij.net>,
intellij@maguyane.net says...

David you should try IdeaSpring 1.1.2 which gives you :

+ a red tick when a bean being referenced in one file doesn't exist in another(misspelled, for instance)

+ ctrl-b on bean id

+ auto-completion on bean and method references

+ Refactoring: inline bean

+ Refactoring : convert anonymous bean to named one

+ ...

And wait for 1.2 with :

+ QuickFix : create a new bean from an unknown referenced one
+ Intention : converts full form of value and ref elements to shortcut form
+ Intention : converts shortcut form of value and ref elements to full form if the bean referenced is local

- Refactoring : rename bean

- Refactoring : move bean

and more...


If you tell me what's inconsistent with IdeaSPring i can try to fix it.

I'll try it! I'm currently using a less than 1.0 release, which I liked,
but I'll try the new one!
--
-


David H. McCoy


-


0

Hi Maurice,

Keep up the great work! I look forward to 1.2.

Are you planning to add support for following child contexts imported by top-level configuration files?

e.g. ]]>

Cheers,

Franck

0

Thanks for the clarification, Neil. You are right, the question is in
the threshold and identifying current and future trends and balance
those with best-of-breed solutions.

I guess that if it makes sense business-wise, they'll do it...

Amnon

Neil Chaudhuri wrote:

Point taken, Amnon. But you might have missed my first statement:

"It is hard enough to keep up with rapidly evolving Java specs, so I do not expect IDEA to keep up with every open-source tool that comes out. Then again, some open-source tools emerge (e.g. Spring, Hibernate, Facelets) that become so popular that support would be a huge convenience."

I am quite aware that IDEA cannotand indeed should notattempt to support every Tom, Dick, and Hibernate that comes along. However, there are some tools that become so pervasive that supporting them doesn't produce "tentacles of functionality" (nice metaphor by the way) but rather features that increase productivity and allow us to more quickly meet business objectives.

The key issue is to define the threshold between merely providing generic support for supporting technologies for some tool and providing full-fledged support for that tool because it is as widely used as a core spec. After all, it may just be possible that Sun's solution to a problem isn't the best, and IDEA is far more than a Sun vehicle.

Thanks.

0

I know this thread has gotten carried away with Spring, but I must point out that my original point was far more general. Basically, my premise remains that it is often the case that the best solution to a problem is not found in the Java specs. If that premise is accepted, then there must be some objective threshold of acceptance by the Java developer community at which point it makes sense for IDEA to support the solution.

It seems to me the answer provided by Dmitry is that there is no clear or truly objective means of defining that threshold. Instead, it is simply a matter of when the cacophony on the forums becomes intense enough. Though not ideal, that's cool. It is still awesome that the IDEA developers like Dmitry take the time to read the rants of its users. For that, I thank you, Dmitry.

Dmitry raised the important corollary point that it is not enough to simply clamor for "support" of some tool. It is also necessary to be specific about the functionalitybasically the requirements for the module providing the support. Although Spring has captured the imagination of this thread, I must confess I am fairly new to it, so I cannot add more than what David and others have suggested. I might just add that a GUI for adding beans to Spring's XML file would be usefuljust as the one IDEA has for EJB deployment descriptors. But that's all I can think of beyond what others have mentioned.

I now pose to other developers: What other open-source tools would you like to see fully and specifically supported in IDEA? Please consider IDEA's current support for the tool through generic mechanisms as well as the market penetration of the tool. Besides Spring, I would suggest Hibernate. Though it is not quite popular enough (as determined through my own empirical evidence and zero raw data), I would also say Facelets is getting there.

Thanks.

0


If 2% of programmers have even heard of Spring, let
alone used it, I would be very surprised. <1% seems
more likely. That's not saying anything bad about
Spring, it's just too new and too ill-supported to
have gotten the penetration. If IDEA never
supported Spring (and it already does, to some
extent), >97% of programmers would never even notice.

--Dave Griffith


Although your statement may be technically correct, I couldn't disagree more with the point you are trying to make.

First off, it is a fact - originally stated by the great computer scientist Dijkstra - that at least 90% of all programmers are BAD programmers. That doesn't mean they are all dumb, it just means that even super-intelligent people often write nothing but god-awful code. Unfortunately, only a small percentage of software engineers are indeed capable of writing clear, reusable, pluggable and well-organized code with minimum dependancies, code that is easy to read and maintain. And that's what Spring is all about! That's why any GOOD programmer has noticed and appreciated Spring immediately. Springs speaks to those programmers, while all others remain deaf and blind to it, because they just don't know the difference between good and poor programming. Being a truly good programmer is actually a very rare talent, but somehow too many people out there think that they can be programmers while they should be doing something else - it's just too easy to be a bad programmer and still get a job. (Just take a good look at that Java method written by your well-respected colleage - with 900 lines of spaghetti code and no comments in it.)

Anyway, what I am saying is that no software vendor should cator to the least competent majority. It's those few % that are actually driving the progress and get things done. And, yes, those folks have heard of Spring by now, and they are using it. Because Spring is arguably the best thing that has happened to the Java community within the last couple of years.

This discussion aside, I agree that it is impossible for an IDE to respond to any - even hot - technology. Even Struts is not so hot anymore, and its limitations and flaws are obvious to anyone who's paying attention. What IDEA needs is a super easy way for the developers to write plug-ins for it. The plug-in support must be perfected to the point where it becomes just as easy to write a plug-in for IDEA as it is for Eclipse. Well, obviously, that's not easy to achieve because, unlike Eclipse, IntelliJ's architecture is not plug-in based. So, if anything, JetBrains should be focusing their efforts on adopting an architecture to encourage software vendors to write plug-ins for IntelliJ along with their main products. Practically any hot technology today has a corresponding plug-in for Eclipse. But not IntelliJ... If IDEA does not become significantly plugin-friendlier, no matter how superior it is to Eclipse, it will eventually lose its market share, however small compared to Eclipse it is today.

0

Thanks Franck.

Beans imported by import tag are shown in the browser... but they wasn't handled for navigation, etc...

Thanks for pointing this out. It's fixed in forthcoming v1.2
but i'm considering making IdeaSpring a commercial plugin with this version.


Maurice

0

In article <29905710.1142002475188.JavaMail.itn@is.intellij.net>,
intellij@maguyane.net says...

Thanks Franck.

Beans imported by import tag are shown in the browser... but they wasn't handled for navigation, etc...

Thanks for pointing this out. It's fixed in forthcoming v1.2
but i'm considering making IdeaSpring a commercial plugin with this version.


Maurice

How much?
--
-


David H. McCoy


-


0

Please sign in to leave a comment.