picocontainer in OpenAPI?

Sorry but I can't help myself :) :

From your post, you seem like one of those "evangelists" that want to Spring and Maven everything out there :).

Ahmed.

Sorry but I can't help myself :) :
From your post, you sound like Hani.
:) :)

Alain

>Sorry but I can't help myself :) :
>From your post, you seem like one of those "evangelists" that want to Spring and Maven everything out there :).
>Ahmed.

>

Sorry but I can't help myself :) :
From your post, you sound like Hani.
:) :)

You are right :).

Ahmed.

Jacques Morel wrote:

Are you planning on moving to dependency injection to initialize
plugins instead of having them use the IDEA Components getInstance()?

Having started looking at the Spring Framework I'd love to see some DI
in plugins. Declare a resource has a Project and its given to you,
that'd be nice, would make for easier testing as well....

I will do a full system check if my post indicated any preferences ;)

I really don't care which one is used. It was a tongue and cheek joke about that very fact: too many people want everybody to use their favorite toy and loose track of what is more important: the principles behind the tools.
As you may have noted in my original SCR, I used both. I started with pico and then converted to spring because of legacy app constraints (constructor injection did not support cycle before). Later I stayed with spring just because that is the one we use. They are very similar in their core features.
I am however very impressed by the side effects of applying Dependency Injection in my code. So I will admit that I was then and I am even more now an evangelist of the DI principle.

Jacques

Mark, as I mentioned I have a wrapper to the plugin API that uses spring. In order to get an IDEA component you just add a constructor argument and a field and voila!
All wiring is done at the last step of IDEA initialization so you don't have to worry about incompletely initialized components. You only need a few IDEA plugin components including the container wrapper, the rest can be straight beans. IDEA plugin components like VCS, Configuration or Configurable are still created by IDEA then "autowired" by spring.
I have a corresponding test base class to register mock/stub components you need in your test so you can simplify test setup as well.

Send me an email if you are interested.

Jacques

The difference is that Ahmed added a smiley to his sentence...
:)

Vince.

Vincent Mallet wrote:

>The difference is that Ahmed added a smiley to his sentence...
>:)
>

>
I know. That's why I added 2 to mine.
:) :) :)

Alain

Jacques,

You can already use constructor-injection pattern for all your component
dependencies.

I would be interested in this. Maybe post it to intellij.org?

Jacques Morel wrote:

I could not help but notice that Iridia is using picocontainer. I got a stacktrace at IDEA initialization time so it seems you are using it internally for Component initialization.

Are you planning on moving to dependency injection to initialize plugins instead of having them use the IDEA Components getInstance()?

I submitted a request along this line a while back (http://www.intellij.net/forums/thread.jsp?forum=15&thread=37087&message=522357 ) and I would love to see this happen. Like I pointed out you can still maintain the old interface deprecated and introduce the new way. I just converted 2 of my plugins to Spring with great results. All IDEA components are loaded into a spring container and all my components automagically get the necessary ones. They are now much more testable and interestingly their design is better, tighter resulting in smaller and more cohesive loosely coupled classes.

I am just SOOOO disappointed you chose the wrong container. Now I have to move to pico... sigh (just kidding they are both very fine containers and it should be very easy to move to pico/nanocontainer).

Jacques

It actually already works the way you asking for. Just add necessary
parameters to your application/project level components to get the
dependencies.

--
Maxim Shafirov
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

Sorry, haven't read the thread completely. Already answered :)

--
Maxim Shafirov
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

No need to apologize here. The more feedback the better, thanks Mike and Maxim for your answer.

Also, did I tell you already that you rock? I think it has been too long: so...

YOU ROCK!

Jacques

PS: is the PSI dependency resolved as well? Are the components initialized on post startup activities so if one of my components takes PsiManager as a parameter of its constructor, it can use the PsiManager right away in the constructor ?

Mike, does that mean you are back on IDEA? ;)

Will do as soon as I am at a stable point. I am right in the middle of a large refactoring. Jacques

BTW could you close that SCR?

Jacques Morel wrote:

Mike, does that mean you are back on IDEA? ;)

Nope. It does mean we've started to use PicoContainer in Fabrique and
were quite impressed by it. Later we've convinced IDEA guys to allow us
(me in this case) integrate IDEA with PicoContainer - this makes our
lifes a bit happier :)

BTW we are also thinking about refactoring our Fabrique
plugin/extensions subsytem and putting it back to IDEA.

Jacques Morel wrote:

PS: is the PSI dependency resolved as well? Are the components initialized on post startup activities so if one of my components takes PsiManager as a parameter of its constructor, it can use the PsiManager right away in the constructor ?

Two questions - two answers:

1. PsiManager indeed resolves.
2. No, you can't use it right in constructor :( We haven't refactored
IDEA lifecycle (yet?). And I really doubt we'll be able to get rid of
post startup activity - it's main purpose is to gather all the work,
needed to perform on one file from all the components.

Could somebody give a super rough example (pseudo-code is OK) of the way
to refactor existing/write plugins to use pico.

A
- before: without pico
- after: with pico
comparison of pseudo-code would be enlighting, I guess.


Alain

before:

public MyComponent implements ProjectComponent {
public void MyComponent(Project project) {
myPsiManager = PsiManager.getInstance(project);
}
}

after:

public MyComponent implements ProjectComponent {
public void MyComponent(PsiManager manager) {
myPsiManager = manager;
}
}

Mike,

Woahhh, that's a lot simpler!!
:)

Joke apart, is the benefit only for you - the plugin framework
implementers -, or is there some for us - the plugin writers-?
That was the question behind my question.


Alain

before:

>

public MyComponent implements ProjectComponent {
public void MyComponent(Project project) {
myPsiManager = PsiManager.getInstance(project);
}
}

>

after:

>

public MyComponent implements ProjectComponent {
public void MyComponent(PsiManager manager) {
myPsiManager = manager;
}
}

1. You shouldn't actually bother what's the level of component you
depend on - you just declare a parameter.
2. You'll get cyclic depndency checked if you have dependant plugins.
3. We're going to get rid of most of components lifecycle - you'll be
able to work with most components right in constructor.
4. As soon as I submit some Pico improvements to Pico mainteners you'll
got simpler listeners support.

Mike,
I am curious.
Are you migrating your internal components to pico gradually or all at once?
How are you using pico in testing or are you at all?

Jacques

Nope

Oh well. One can always hope ;) You guys did great to introduce pico in IDEA. I have myself be really impressed by the cleaning effect it has had on our software.

refactoring our Fabrique plugin/extensions subsytem and putting it back to IDEA

Intriguing. I haven't had the time to keep up with Fabrique. Could you briefly tell us about the subsystem capabilities or point to some reference?

Thanks

The main 2 things that are always brought up as major advantages of DI are testability & decoupling: you can remove all implicit dependencies from singletons and most of the ones from direct allocation (sometimes you have to use a factory)
However the most interesting effect I found through the use of constructors dependency injection is that it drives you to have very cohesive classes. Constructor chaining is a pain, let's face it. So very early in the process of growing your classes responsabilities, the pain pushes you to choose a more modular, cohesive approach. God classes are completely impossible. Even doing TDD, I have found large ctors param list to be a very good STRONG smell. That smell is very hard to pass and make you refactor very early. It is rare to see the code gives you feedback as fast and as clear as this. Even junior developers can pick it up quickly.

Jacques

Jacques,

Are you migrating your internal components to pico gradually or all at once?

Gradually.

How are you using pico in testing or are you at all?

Not yet. Just discussing the possibility.

Update on benefits:

All components now come to constructor already initialized (but still no
startup activity performed).