Quantcast

Plexus introduction?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Plexus introduction?

Ringo De Smet
Hello,

When validating a patch for 2736, I also wanted to write some unit
tests to validate some expectations. I failed, since everything seems
to be tightly linked because of Hudson.getInstance() all over the
place.

My experience in writing Nexus plugins was completely the opposite:
because of the Plexus container usage, I was able to write a plugin
*with* unit tests in no time, even without Nexus having an explicit
plugin API. Most of the important classes are Plexus components! :-)

I read Sonatype's intention to introduce the Plexus container also in
Hudson. Can someone report on the status? I have some spare cycles to
waste, and I was thinking of creating a Hudson branch with the
following goal: change Hudson in such a way that the initialization is
similar to Nexus: the ServletContextListener initializes the Plexus
container. Hudson itself would be the first (and single) component
deployed in there.

What do you think?

Ringo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Jason van Zyl-3
I'm waiting to sign a CLA, but Tom is the original author of the work  
so I'm sure he can put the work on a branch if he hasn't already.

I'm also going to publish a GIT repository as I think it's just easier  
to share that way.

We're committed to the Plexus/OSGi path as well so I think that would  
help here as well. OSGi+DI is very powerful. On another note I think  
Igor (Maven/M2E/Nexus developer) has pretty much convinced me that OSGi
+Plexus is probably the way Maven/Nexus should go so it's likely in  
the near future that Maven and Nexus will use OSGi as the runtime and  
Plexus for Dependency injection. If Maven and Nexus did this then  
Hudson doing the same thing I believe would make writing build/release  
tooling that much easier.

On 17-Feb-09, at 9:43 AM, Ringo De Smet wrote:

> Hello,
>
> When validating a patch for 2736, I also wanted to write some unit
> tests to validate some expectations. I failed, since everything seems
> to be tightly linked because of Hudson.getInstance() all over the
> place.
>
> My experience in writing Nexus plugins was completely the opposite:
> because of the Plexus container usage, I was able to write a plugin
> *with* unit tests in no time, even without Nexus having an explicit
> plugin API. Most of the important classes are Plexus components! :-)
>
> I read Sonatype's intention to introduce the Plexus container also in
> Hudson. Can someone report on the status? I have some spare cycles to
> waste, and I was thinking of creating a Hudson branch with the
> following goal: change Hudson in such a way that the initialization is
> similar to Nexus: the ServletContextListener initializes the Plexus
> container. Hudson itself would be the first (and single) component
> deployed in there.
>
> What do you think?
>
> Ringo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
http://twitter.com/jvanzyl
----------------------------------------------------------

A language that doesn’t affect the way you think about programming is  
not worth knowing.

-— Alan Perlis


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Ringo De Smet
Jason,

2009/2/17 Jason van Zyl <[hidden email]>:
> I'm waiting to sign a CLA, but Tom is the original author of the work so I'm
> sure he can put the work on a branch if he hasn't already.

Maybe I should also look into signing a CLA. This wouldn't be a
trivial code change...

> I'm also going to publish a GIT repository as I think it's just easier to
> share that way.

Would that be a public GIT repository? Would I be able to contribute
via your GIT repository?

> We're committed to the Plexus/OSGi path as well so I think that would help
> here as well. OSGi+DI is very powerful. On another note I think Igor
> (Maven/M2E/Nexus developer) has pretty much convinced me that OSGi+Plexus is
> probably the way Maven/Nexus should go so it's likely in the near future
> that Maven and Nexus will use OSGi as the runtime and Plexus for Dependency
> injection. If Maven and Nexus did this then Hudson doing the same thing I
> believe would make writing build/release tooling that much easier.

OK, plexus mailing lists here I come! :-)

Ringo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Tom Huybrechts
You can already have a look at what's available for Plexus here:
https://svn.dev.java.net/svn/hudson/branches/plexus
It's not actually a branch, but more a repackaging, with some added code.

I do wonder: when you were writing your test cases, did you use
HudsonTestCase ? Writing tests is not that hard any more in my
opinion.

Tom



On Wed, Feb 18, 2009 at 1:09 PM, Ringo De Smet <[hidden email]> wrote:

> Jason,
>
> 2009/2/17 Jason van Zyl <[hidden email]>:
>> I'm waiting to sign a CLA, but Tom is the original author of the work so I'm
>> sure he can put the work on a branch if he hasn't already.
>
> Maybe I should also look into signing a CLA. This wouldn't be a
> trivial code change...
>
>> I'm also going to publish a GIT repository as I think it's just easier to
>> share that way.
>
> Would that be a public GIT repository? Would I be able to contribute
> via your GIT repository?
>
>> We're committed to the Plexus/OSGi path as well so I think that would help
>> here as well. OSGi+DI is very powerful. On another note I think Igor
>> (Maven/M2E/Nexus developer) has pretty much convinced me that OSGi+Plexus is
>> probably the way Maven/Nexus should go so it's likely in the near future
>> that Maven and Nexus will use OSGi as the runtime and Plexus for Dependency
>> injection. If Maven and Nexus did this then Hudson doing the same thing I
>> believe would make writing build/release tooling that much easier.
>
> OK, plexus mailing lists here I come! :-)
>
> Ringo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Kohsuke Kawaguchi
Administrator
In reply to this post by Ringo De Smet
Ringo De Smet wrote:
> Hello,
>
> When validating a patch for 2736, I also wanted to write some unit
> tests to validate some expectations. I failed, since everything seems
> to be tightly linked because of Hudson.getInstance() all over the
> place.

Right, this was an design decision that has various not so pleasant
consequences, as you noted. Unfortunately, for compatibility reasons,
it's too late to change this.

Note that you can still write unit tests by extending from
HudsonTestCase, which does the proper set up and tear down for singletons.


> My experience in writing Nexus plugins was completely the opposite:
> because of the Plexus container usage, I was able to write a plugin
> *with* unit tests in no time, even without Nexus having an explicit
> plugin API. Most of the important classes are Plexus components! :-)
>
> I read Sonatype's intention to introduce the Plexus container also in
> Hudson. Can someone report on the status? I have some spare cycles to
> waste, and I was thinking of creating a Hudson branch with the
> following goal: change Hudson in such a way that the initialization is
> similar to Nexus: the ServletContextListener initializes the Plexus
> container. Hudson itself would be the first (and single) component
> deployed in there.
>
> What do you think?
Tom committed a branch for the plexus integration, and I intend to look
at that and merge that into the trunk.

Again, for compatibility reasons, the best we can do is to bring them
side-by-side with the current model. So the way I see it is that you'll
be able to write your plugins as Plexus components, but the things in
Hudson core would remain as the way they are.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Kohsuke Kawaguchi
Administrator
In reply to this post by Ringo De Smet
Ringo De Smet wrote:
> Jason,
>
> 2009/2/17 Jason van Zyl <[hidden email]>:
>> I'm waiting to sign a CLA, but Tom is the original author of the work so I'm
>> sure he can put the work on a branch if he hasn't already.
>
> Maybe I should also look into signing a CLA. This wouldn't be a
> trivial code change...

Yes, if you are interested in contributing to the Hudson core, we now
need to ask you to sign SCA. More info at
https://glassfish.dev.java.net/public/GovernancePolicy.html


>> I'm also going to publish a GIT repository as I think it's just easier to
>> share that way.
>
> Would that be a public GIT repository? Would I be able to contribute
> via your GIT repository?
>
>> We're committed to the Plexus/OSGi path as well so I think that would help
>> here as well. OSGi+DI is very powerful. On another note I think Igor
>> (Maven/M2E/Nexus developer) has pretty much convinced me that OSGi+Plexus is
>> probably the way Maven/Nexus should go so it's likely in the near future
>> that Maven and Nexus will use OSGi as the runtime and Plexus for Dependency
>> injection. If Maven and Nexus did this then Hudson doing the same thing I
>> believe would make writing build/release tooling that much easier.
>
> OK, plexus mailing lists here I come! :-)
>
> Ringo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Ringo De Smet
In reply to this post by Kohsuke Kawaguchi
Kohsuke,

2009/2/18 Kohsuke Kawaguchi <[hidden email]>:
>
> Right, this was an design decision that has various not so pleasant
> consequences, as you noted. Unfortunately, for compatibility reasons, it's
> too late to change this.

It's never too late. It only takes a lot of courage. :-)

> Note that you can still write unit tests by extending from HudsonTestCase,
> which does the proper set up and tear down for singletons.

This is a nice workaround, but not maintainable in the long run. We
need to start decoupling things, both with the intent of pluggability
(e.g. the discussion on pluggability of the queue implementation) and
the easier unit testing. What's the unit test code coverage currently?
I suspect that if we don't work on these things in the short term, it
will slow down Hudson core and plugin development considerably. Too
much regressions will pop up at every release.

> Again, for compatibility reasons, the best we can do is to bring them
> side-by-side with the current model. So the way I see it is that you'll be
> able to write your plugins as Plexus components, but the things in Hudson
> core would remain as the way they are.

The Hudson code base is quite good, and Hudson is getting a lot of
attention lately. However, some groundwork must be performed to make
Hudson extendable in an easy and consistent way (long term vision!).
As an example, I can't rename a class containing an extension point
since that would break a number of plugins registering their services
in that class. Eclipse with it's extensions points and extensions
doesn't have that problem since everything is declarative. The code
looking up the registered extensions can be modified at will, as well
as the extensions themselves. The only thing that has to remain the
same is the name of the extension point.

Comments?

Ringo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Kohsuke Kawaguchi
Administrator
Ringo De Smet wrote:
> Kohsuke,
>
> 2009/2/18 Kohsuke Kawaguchi <[hidden email]>:
>>
>> Right, this was an design decision that has various not so pleasant
>> consequences, as you noted. Unfortunately, for compatibility reasons, it's
>> too late to change this.
>
> It's never too late. It only takes a lot of courage. :-)

I don't think it's a matter of courage. I think the compatibility
matters --- we cannot tell our users "hey, starting 1.300 all your
plugins will stop working."


>> Note that you can still write unit tests by extending from HudsonTestCase,
>> which does the proper set up and tear down for singletons.
>
> This is a nice workaround, but not maintainable in the long run. We
> need to start decoupling things, both with the intent of pluggability
> (e.g. the discussion on pluggability of the queue implementation) and
> the easier unit testing. What's the unit test code coverage currently?
> I suspect that if we don't work on these things in the short term, it
> will slow down Hudson core and plugin development considerably. Too
> much regressions will pop up at every release.
Yes, certain things would have been easier if we had a real DI
container, but I think there's a lot of things we can improve in these
spaces even if we don't have one.

Whether that becomes too much of a burden, we'll see. At that point,
there might be Hudson 2.0. Right now, I think the biggest problem is not
that it's too hard to write tests --- it's more that we just don't have
enough number of tests.


>> Again, for compatibility reasons, the best we can do is to bring them
>> side-by-side with the current model. So the way I see it is that you'll be
>> able to write your plugins as Plexus components, but the things in Hudson
>> core would remain as the way they are.
>
> The Hudson code base is quite good, and Hudson is getting a lot of
> attention lately. However, some groundwork must be performed to make
> Hudson extendable in an easy and consistent way (long term vision!).
> As an example, I can't rename a class containing an extension point
> since that would break a number of plugins registering their services
> in that class. Eclipse with it's extensions points and extensions
> doesn't have that problem since everything is declarative. The code
> looking up the registered extensions can be modified at will, as well
> as the extensions themselves. The only thing that has to remain the
> same is the name of the extension point.
The reason we cannot rename classes is because we use a persistence
mechanism that's tied to class names, so that's not because we don't
have a container.

But I agree that manually installing extension points and doing so to a
singleton is rather stupid, and I think we can fix that somewhat without
breaking the compatibility, and we can fix that without forcing one and
the only container. So we can still allow people to write their plugins
in Plexus, Spring, Guice, or what have you.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Alan Harder-2

>> It's never too late. It only takes a lot of courage. :-)
>
> I don't think it's a matter of courage. I think the compatibility
> matters --- we cannot tell our users "hey, starting 1.300 all your
> plugins will stop working."
>

how about things deprecated more than 100 releases ago are subject to
deletion?  some such policy would allow cleaning up old/compatibility
code eventually (at least for code compatibility of plugins... harder to
remove compatibility code for loading old xml data that may not get
updated even when you upgrade Hudson).

Or, at some point you can make a bunch of changes that break
compatibility (probably in a branch) and release the first 2.x
version... people can then stay on 1.x releases and only upgrade when
all the plugins they want have been updated for 2.x.

    - Alan



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plexus introduction?

Jason van Zyl-3
In reply to this post by Kohsuke Kawaguchi

On 19-Feb-09, at 9:28 PM, Kohsuke Kawaguchi wrote:

> Ringo De Smet wrote:
>> Kohsuke,
>> 2009/2/18 Kohsuke Kawaguchi <[hidden email]>:
>>>
>>> Right, this was an design decision that has various not so pleasant
>>> consequences, as you noted. Unfortunately, for compatibility  
>>> reasons, it's
>>> too late to change this.
>> It's never too late. It only takes a lot of courage. :-)
>
> I don't think it's a matter of courage. I think the compatibility  
> matters --- we cannot tell our users "hey, starting 1.300 all your  
> plugins will stop working."
>

I think you can make anything work with a little AspectJ, but I don't  
think it would be too hard to make the old work with the new without  
getting as radical as Hudson 2.0.

>
>>> Note that you can still write unit tests by extending from  
>>> HudsonTestCase,
>>> which does the proper set up and tear down for singletons.
>> This is a nice workaround, but not maintainable in the long run. We
>> need to start decoupling things, both with the intent of pluggability
>> (e.g. the discussion on pluggability of the queue implementation) and
>> the easier unit testing. What's the unit test code coverage  
>> currently?
>> I suspect that if we don't work on these things in the short term, it
>> will slow down Hudson core and plugin development considerably. Too
>> much regressions will pop up at every release.
>
> Yes, certain things would have been easier if we had a real DI  
> container, but I think there's a lot of things we can improve in  
> these spaces even if we don't have one.
>
> Whether that becomes too much of a burden, we'll see. At that point,  
> there might be Hudson 2.0. Right now, I think the biggest problem is  
> not that it's too hard to write tests --- it's more that we just  
> don't have enough number of tests.
>
>
>>> Again, for compatibility reasons, the best we can do is to bring  
>>> them
>>> side-by-side with the current model. So the way I see it is that  
>>> you'll be
>>> able to write your plugins as Plexus components, but the things in  
>>> Hudson
>>> core would remain as the way they are.
>> The Hudson code base is quite good, and Hudson is getting a lot of
>> attention lately. However, some groundwork must be performed to make
>> Hudson extendable in an easy and consistent way (long term vision!).
>> As an example, I can't rename a class containing an extension point
>> since that would break a number of plugins registering their services
>> in that class. Eclipse with it's extensions points and extensions
>> doesn't have that problem since everything is declarative. The code
>> looking up the registered extensions can be modified at will, as well
>> as the extensions themselves. The only thing that has to remain the
>> same is the name of the extension point.
>
> The reason we cannot rename classes is because we use a persistence  
> mechanism that's tied to class names, so that's not because we don't  
> have a container.
>
> But I agree that manually installing extension points and doing so  
> to a singleton is rather stupid, and I think we can fix that  
> somewhat without breaking the compatibility, and we can fix that  
> without forcing one and the only container. So we can still allow  
> people to write their plugins in Plexus, Spring, Guice, or what have  
> you.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
http://twitter.com/jvanzyl
----------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

   -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...