Quantcast

Sonatype's Hudson Plans for Maven Integration

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

Sonatype's Hudson Plans for Maven Integration

Jason van Zyl-3
Howdy,

I want to share with you what Sonatype is planning to do with Hudson -  
I hope you will be interested. We'll are planning a lot of work on the  
OSS side and will contribute that all back (provided the license of  
Hudson does not change to the CDDL). We are also planning to work on a  
commercially supported version of Hudson and we will create some  
additional commercial plugins. I think people here will be most  
interested in the OSS work so I'll start there.

It all starts with the work we've done with Tom Huybrechts over the  
last few months to embed Plexus inside Hudson. This has several  
implications, especially for those who are interested in Maven  
integration. Tom made the PluginManager itself pluggable and the  
Plexus version of the PluginManager that was created finds Plexus  
components in its standard way. As a result plugins now work the same  
way in Hudson, Maven and Nexus.

 From a Sonatype perspective we want to use the same system inside  
Maven, Nexus, Hudson, and Eclipse. Maven 2.x has used Plexus from the  
beginning, Nexus has used Plexus since its inception, the work Tom has  
done for Sonatype now allows us to write any Hudson extension using  
Plexus, and we are currently working on a Plexus/OSGi bridge as part  
of our work in m2eclipse so Plexus components will operate in OSGi  
runtimes as bundles.. We want to take a Plexus component and reuse it  
across all of these systems.

With the Plexus integration we have for Hudson we can now leverage any  
of the components that were created for Continuum (Continuum was  
probably the first Plexus application) and we want to create tight  
integration with Maven SCM (also a set of Plexus components) and the  
quality reporting system in Maven (also a set of Plexus components).  
We fully realize that changes will need to be made in Maven SCM and in  
the reporting/quality system in Maven to facilitate the integration.  
We already see changes that we must make in Maven 3.x and the  
underlying plugin and reporting APIs so that we can run efficiently in  
an OSGi-based environment like Eclipse. As an example of what we're  
doing lets take Emma as an example.

We have started work to create Plexus components for Emma, we now have  
a reworked set of Maven Emma plugins, and we've attempted to bridge  
our work into Eclemma (which is currently the best Emma plugin for  
Eclipse). We now want to take the Plexus components and make it work  
for use inside Hudson. We want to be able to contribute to data  
collection and trending.  We have done all sorts of prototype work to  
create a new Maven API for quality metrics by moving away from a  
document production model to a data production model. I think it's  
unfortunate that a very large number of Hudson plugins essentially  
duplicate many of the Maven plugins that exist because it wasn't a  
huge change we made to collect data as opposed to producing a document.

In the same vein we will make any modifications necessary to the Maven  
SCM API to integrate better with Hudson and Eclipse team providers.  
When our Plexus/OSGi bridge work is done any component written in  
Plexus will be available inside an OSGi environment as a bundle. I  
don't know how popular OSGi will be as runtime for applications as it  
has its great parts, but has some serious detractions as well. What is  
certain is that OSGi rules on the developer desktop with Eclipse so we  
have taken that into account and need to make sure the tools we  
produce function equally well in Maven and Eclipse. We also feel that  
Hudson rules in the arena of build automation and so we're focusing on  
what we feel is an ideal set of tools consisting of Maven, Nexus,  
Hudson, and Eclipse and we are working on production quality  
integration between these four systems.

So the first thing we would like to contribute is the Plexus  
integration that Tom has worked on. This integration is will not work  
with the current form of Hudson because an old version of the Maven  
Embedder is used in the core of Hudson and it depends on a much older  
version of Plexus. It's up to you guys but if you want the Plexus  
integration in your SVN I am happy to work on a branch helping to  
decouple the current form of Maven integration from the core so that  
both versions of Plexus can exist. This would allow anyone to write a  
Hudson plugin in much the same way they would write a Maven plugin.

We are also working on a new Maven job type and some new Hudson  
features which depend on Maven 3.x. So this work I wouldn't recommend  
for public consumption yet, but as Maven 3.x reaches GA so will the  
Hudson integration we are working on. So we are also happy to  
contribute this if you are interested.  We would also like to work on  
integrating JSecurity and our REST framework (currently based on  
Restlet but moving toward Jersey). For anyone who is familiar with  
Nexus we want to integrate the security systems and we want to be able  
to create a UI for Hudson based on ExtJS. These parts we would also be  
happy to contribute if you are interested. This is something that we  
want at Sonatype and we fully realize this may not mesh with what you  
want. We're not going to try and shove anything down anyone's throats.  
We just want to be open about what we're working on and the direction  
we're going and if you guys want the code we're happy to contribute.

Beyond that we will be working on some commercial extensions. We want  
to integrate a workflow system, create bullet proof release management  
that is integrated with Nexus, tools for the automatic provisioning of  
build nodes and custom data collections tools the creation of what we  
think is a pretty cool dashboard idea.

Happy to answer any questions, and if people want the work that we've  
slated for OSS we are more then happy to contribute it. We use Hudson  
on a daily basis and couldn't live without it at this point so we feel  
it only fair to give something back.

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more  
examples
you look at, the more general your framework will be.

   -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks


---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Ulli Hafner-2
> [...]
>
> From a Sonatype perspective we want to use the same system inside  
> Maven, Nexus, Hudson, and Eclipse. Maven 2.x has used Plexus
> from the  
> beginning, Nexus has used Plexus since its inception, the
> work Tom has  
> done for Sonatype now allows us to write any Hudson extension using  
> Plexus, and we are currently working on a Plexus/OSGi bridge as part  
> of our work in m2eclipse so Plexus components will operate in OSGi  
> runtimes as bundles.. We want to take a Plexus component and
> reuse it  
> across all of these systems.

That looks quite interesting. Does that mean that all plug-ins
(and dependency libraries) could be OSGi bundles? This might solve some
classloading problems we currently have with the native plug-in system.

> We have started work to create Plexus components for Emma, we
> now have  
> a reworked set of Maven Emma plugins, and we've attempted to bridge  
> our work into Eclemma (which is currently the best Emma plugin for  
> Eclipse). We now want to take the Plexus components and make it work  
> for use inside Hudson. We want to be able to contribute to data  
> collection and trending.  We have done all sorts of prototype
> work to  
> create a new Maven API for quality metrics by moving away from a  
> document production model to a data production model. I think it's  
> unfortunate that a very large number of Hudson plugins essentially  
> duplicate many of the Maven plugins that exist because it wasn't a  
> huge change we made to collect data as opposed to producing a
> document.

Well I'm not sure if any of the Hudson plug-ins duplicate something
what is part of maven. The maven reporting tools only create a static
HTML report for the current build. No rich UI and no build trend
reports.

I think it would be a good idea if maven produces only data and the
build servers are responsible for rendering the information. (Note
that the Hudson plug-ins still need to be compatible with ant builds,
so the efforts to write a Hudson plug-in will be the same...)

Ulli

---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Jason van Zyl-3

On 3-Feb-09, at 9:23 AM, Hafner Ullrich wrote:

>> [...]
>>
>> From a Sonatype perspective we want to use the same system inside
>> Maven, Nexus, Hudson, and Eclipse. Maven 2.x has used Plexus
>> from the
>> beginning, Nexus has used Plexus since its inception, the
>> work Tom has
>> done for Sonatype now allows us to write any Hudson extension using
>> Plexus, and we are currently working on a Plexus/OSGi bridge as part
>> of our work in m2eclipse so Plexus components will operate in OSGi
>> runtimes as bundles.. We want to take a Plexus component and
>> reuse it
>> across all of these systems.
>
> That looks quite interesting. Does that mean that all plug-ins
> (and dependency libraries) could be OSGi bundles? This might solve  
> some
> classloading problems we currently have with the native plug-in  
> system.
>

We are working on a prototype system that allows you to take advantage  
of the OSGi runtime model which I believe is good. But avoid the  
programming model and the infrastructure model which I feel are pretty  
awful. So we want to use Plexus APIs not the OSGi service model API,  
and we don't want to use "bundles" where the metadata is fused into  
the artifact but use normal JARs and metadata stored separately in an  
Atom store. This involves some custom protocol handlers and  
installation tools and some custom code which we have initially target  
at Equinox.

>> We have started work to create Plexus components for Emma, we
>> now have
>> a reworked set of Maven Emma plugins, and we've attempted to bridge
>> our work into Eclemma (which is currently the best Emma plugin for
>> Eclipse). We now want to take the Plexus components and make it work
>> for use inside Hudson. We want to be able to contribute to data
>> collection and trending.  We have done all sorts of prototype
>> work to
>> create a new Maven API for quality metrics by moving away from a
>> document production model to a data production model. I think it's
>> unfortunate that a very large number of Hudson plugins essentially
>> duplicate many of the Maven plugins that exist because it wasn't a
>> huge change we made to collect data as opposed to producing a
>> document.
>
> Well I'm not sure if any of the Hudson plug-ins duplicate something
> what is part of maven. The maven reporting tools only create a static
> HTML report for the current build.

That was my point, in that it's a small change for the generation of  
data.

> No rich UI and no build trend
> reports.
>

With data streams you are seeing that a lot of custom UI for data  
visualization is not required.

> I think it would be a good idea if maven produces only data and the
> build servers are responsible for rendering the information. (Note
> that the Hudson plug-ins still need to be compatible with ant builds,
> so the efforts to write a Hudson plug-in will be the same...)

This is where we will be focusing on Maven users. We care about the  
tools working in a best practices way for Maven users. So this is  
where we may diverge because we care about Maven builds, integration  
with the Maven command line, Hudson and m2eclipse. For us the same  
component must work in those environments. I don't see any reason why  
the data production systems that will be created in Maven 3.x can't be  
used by your Ant support but we won't be doing anything for Ant  
specifically. If we can make small changes that help that don't  
detract from great Maven support then we're willing to do that. We are  
focusing squarely on great Maven support.

>
>
> Ulli
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.

  -- Eric Hoffer, Reflections on the Human Condition


---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

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

It's great to hear that you guys are planning a substantial contribution
on Hudson. The Maven integration from the Maven guys themselves is
great, and the release support has long been desired. We'll definitely
have more technical discussions about the possible changes and their
implications, but I suppose those could come later one by one.

Since you mentioned about a commercially supported version of Hudson, I
should also mention that Sun is also working on productizing Hudson in
several fronts --- I need Sun to make some revenue in order for them to
keep me working on Hudson   :-)  , and I think it serves the community
better to have an economically sustainable development model. The
details are still being worked out, but I can say that the whole thing
is moving along nicely.

Personally, I feel good to have more than one offerings around Hudson
from different vendors --- it shows how far Hudson has come, growing
from 2 shell scripts kicked by cron just a few years ago!

As for the license, we have no intention of changing the license from
MIT (and even if we wanted to, we don't own the entire copyright of the
codebase anyway), but I think this points out the need to clarify the
copyright holders of the core Hudson codebase --- we currently have just
one LICENSE.txt in hudson/main that covers the codebase with a blanket
statement, but I need to do the copyright header clean-up to bring it to
the level that most other projects are in. This has long been overdue
anyway.


Now, moving on to more technical things, it sounds like the first thing
that we'd want to do is to create a branch for the Plexus integration. I
have some questions about how that could co-exist with the existing
model of Hudson plugins, and it'd be great if I can see the code to
understand it myself.

Could we do that as a starter?


Jason van Zyl wrote:

> Howdy,
>
> I want to share with you what Sonatype is planning to do with Hudson -  
> I hope you will be interested. We'll are planning a lot of work on the  
> OSS side and will contribute that all back (provided the license of  
> Hudson does not change to the CDDL). We are also planning to work on a  
> commercially supported version of Hudson and we will create some  
> additional commercial plugins. I think people here will be most  
> interested in the OSS work so I'll start there.
>
> It all starts with the work we've done with Tom Huybrechts over the  
> last few months to embed Plexus inside Hudson. This has several  
> implications, especially for those who are interested in Maven  
> integration. Tom made the PluginManager itself pluggable and the  
> Plexus version of the PluginManager that was created finds Plexus  
> components in its standard way. As a result plugins now work the same  
> way in Hudson, Maven and Nexus.
>
>  From a Sonatype perspective we want to use the same system inside  
> Maven, Nexus, Hudson, and Eclipse. Maven 2.x has used Plexus from the  
> beginning, Nexus has used Plexus since its inception, the work Tom has  
> done for Sonatype now allows us to write any Hudson extension using  
> Plexus, and we are currently working on a Plexus/OSGi bridge as part  
> of our work in m2eclipse so Plexus components will operate in OSGi  
> runtimes as bundles.. We want to take a Plexus component and reuse it  
> across all of these systems.
>
> With the Plexus integration we have for Hudson we can now leverage any  
> of the components that were created for Continuum (Continuum was  
> probably the first Plexus application) and we want to create tight  
> integration with Maven SCM (also a set of Plexus components) and the  
> quality reporting system in Maven (also a set of Plexus components).  
> We fully realize that changes will need to be made in Maven SCM and in  
> the reporting/quality system in Maven to facilitate the integration.  
> We already see changes that we must make in Maven 3.x and the  
> underlying plugin and reporting APIs so that we can run efficiently in  
> an OSGi-based environment like Eclipse. As an example of what we're  
> doing lets take Emma as an example.
>
> We have started work to create Plexus components for Emma, we now have  
> a reworked set of Maven Emma plugins, and we've attempted to bridge  
> our work into Eclemma (which is currently the best Emma plugin for  
> Eclipse). We now want to take the Plexus components and make it work  
> for use inside Hudson. We want to be able to contribute to data  
> collection and trending.  We have done all sorts of prototype work to  
> create a new Maven API for quality metrics by moving away from a  
> document production model to a data production model. I think it's  
> unfortunate that a very large number of Hudson plugins essentially  
> duplicate many of the Maven plugins that exist because it wasn't a  
> huge change we made to collect data as opposed to producing a document.
>
> In the same vein we will make any modifications necessary to the Maven  
> SCM API to integrate better with Hudson and Eclipse team providers.  
> When our Plexus/OSGi bridge work is done any component written in  
> Plexus will be available inside an OSGi environment as a bundle. I  
> don't know how popular OSGi will be as runtime for applications as it  
> has its great parts, but has some serious detractions as well. What is  
> certain is that OSGi rules on the developer desktop with Eclipse so we  
> have taken that into account and need to make sure the tools we  
> produce function equally well in Maven and Eclipse. We also feel that  
> Hudson rules in the arena of build automation and so we're focusing on  
> what we feel is an ideal set of tools consisting of Maven, Nexus,  
> Hudson, and Eclipse and we are working on production quality  
> integration between these four systems.
>
> So the first thing we would like to contribute is the Plexus  
> integration that Tom has worked on. This integration is will not work  
> with the current form of Hudson because an old version of the Maven  
> Embedder is used in the core of Hudson and it depends on a much older  
> version of Plexus. It's up to you guys but if you want the Plexus  
> integration in your SVN I am happy to work on a branch helping to  
> decouple the current form of Maven integration from the core so that  
> both versions of Plexus can exist. This would allow anyone to write a  
> Hudson plugin in much the same way they would write a Maven plugin.
>
> We are also working on a new Maven job type and some new Hudson  
> features which depend on Maven 3.x. So this work I wouldn't recommend  
> for public consumption yet, but as Maven 3.x reaches GA so will the  
> Hudson integration we are working on. So we are also happy to  
> contribute this if you are interested.  We would also like to work on  
> integrating JSecurity and our REST framework (currently based on  
> Restlet but moving toward Jersey). For anyone who is familiar with  
> Nexus we want to integrate the security systems and we want to be able  
> to create a UI for Hudson based on ExtJS. These parts we would also be  
> happy to contribute if you are interested. This is something that we  
> want at Sonatype and we fully realize this may not mesh with what you  
> want. We're not going to try and shove anything down anyone's throats.  
> We just want to be open about what we're working on and the direction  
> we're going and if you guys want the code we're happy to contribute.
>
> Beyond that we will be working on some commercial extensions. We want  
> to integrate a workflow system, create bullet proof release management  
> that is integrated with Nexus, tools for the automatic provisioning of  
> build nodes and custom data collections tools the creation of what we  
> think is a pretty cool dashboard idea.
>
> Happy to answer any questions, and if people want the work that we've  
> slated for OSS we are more then happy to contribute it. We use Hudson  
> on a daily basis and couldn't live without it at this point so we feel  
> it only fair to give something back.
>
> Thanks,
>
> Jason
--
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: Sonatype's Hudson Plans for Maven Integration

Jason van Zyl-3

On 3-Feb-09, at 3:06 PM, Kohsuke Kawaguchi wrote:

>
> It's great to hear that you guys are planning a substantial  
> contribution
> on Hudson. The Maven integration from the Maven guys themselves is
> great, and the release support has long been desired. We'll definitely
> have more technical discussions about the possible changes and their
> implications, but I suppose those could come later one by one.
>
> Since you mentioned about a commercially supported version of  
> Hudson, I
> should also mention that Sun is also working on productizing Hudson in
> several fronts --- I need Sun to make some revenue in order for them  
> to
> keep me working on Hudson   :-)  , and I think it serves the community
> better to have an economically sustainable development model. The
> details are still being worked out, but I can say that the whole thing
> is moving along nicely.

Absolutely, there's lots of room. We're entirely focused on the Maven  
side of things.

>
>
> Personally, I feel good to have more than one offerings around Hudson
> from different vendors --- it shows how far Hudson has come, growing
> from 2 shell scripts kicked by cron just a few years ago!

The uptake is amazing, but that's what happens with useful software.  
You've done a great job.

>
>
> As for the license, we have no intention of changing the license from
> MIT (and even if we wanted to, we don't own the entire copyright of  
> the
> codebase anyway), but I think this points out the need to clarify the
> copyright holders of the core Hudson codebase --- we currently have  
> just
> one LICENSE.txt in hudson/main that covers the codebase with a blanket
> statement, but I need to do the copyright header clean-up to bring  
> it to
> the level that most other projects are in. This has long been overdue
> anyway.

If you are not making people sign contribution agreements then you  
should probably start doing so because nothing is really safe for  
commercial extension without all the legal aspects taken care of. This  
is why Apache and Eclipse are so successful because they have the  
legal work kept at the same level of importance as the technical work.

>
>
>
> Now, moving on to more technical things, it sounds like the first  
> thing
> that we'd want to do is to create a branch for the Plexus  
> integration. I
> have some questions about how that could co-exist with the existing
> model of Hudson plugins, and it'd be great if I can see the code to
> understand it myself.
>
> Could we do that as a starter?

Absolutely. Tom has done the work thus far so he can commit the work.  
I don't think it will take a lot of work to create some isolated  
classloaders so the old/new plexus versions can work in the same  
environment.

>
>
>
> Jason van Zyl wrote:
>> Howdy,
>> I want to share with you what Sonatype is planning to do with  
>> Hudson -  I hope you will be interested. We'll are planning a lot  
>> of work on the  OSS side and will contribute that all back  
>> (provided the license of  Hudson does not change to the CDDL). We  
>> are also planning to work on a  commercially supported version of  
>> Hudson and we will create some  additional commercial plugins. I  
>> think people here will be most  interested in the OSS work so I'll  
>> start there.
>> It all starts with the work we've done with Tom Huybrechts over  
>> the  last few months to embed Plexus inside Hudson. This has  
>> several  implications, especially for those who are interested in  
>> Maven  integration. Tom made the PluginManager itself pluggable and  
>> the  Plexus version of the PluginManager that was created finds  
>> Plexus  components in its standard way. As a result plugins now  
>> work the same  way in Hudson, Maven and Nexus.
>> From a Sonatype perspective we want to use the same system inside  
>> Maven, Nexus, Hudson, and Eclipse. Maven 2.x has used Plexus from  
>> the  beginning, Nexus has used Plexus since its inception, the work  
>> Tom has  done for Sonatype now allows us to write any Hudson  
>> extension using  Plexus, and we are currently working on a Plexus/
>> OSGi bridge as part  of our work in m2eclipse so Plexus components  
>> will operate in OSGi  runtimes as bundles.. We want to take a  
>> Plexus component and reuse it  across all of these systems.
>> With the Plexus integration we have for Hudson we can now leverage  
>> any  of the components that were created for Continuum (Continuum  
>> was  probably the first Plexus application) and we want to create  
>> tight  integration with Maven SCM (also a set of Plexus components)  
>> and the  quality reporting system in Maven (also a set of Plexus  
>> components).  We fully realize that changes will need to be made in  
>> Maven SCM and in  the reporting/quality system in Maven to  
>> facilitate the integration.  We already see changes that we must  
>> make in Maven 3.x and the  underlying plugin and reporting APIs so  
>> that we can run efficiently in  an OSGi-based environment like  
>> Eclipse. As an example of what we're  doing lets take Emma as an  
>> example.
>> We have started work to create Plexus components for Emma, we now  
>> have  a reworked set of Maven Emma plugins, and we've attempted to  
>> bridge  our work into Eclemma (which is currently the best Emma  
>> plugin for  Eclipse). We now want to take the Plexus components and  
>> make it work  for use inside Hudson. We want to be able to  
>> contribute to data  collection and trending.  We have done all  
>> sorts of prototype work to  create a new Maven API for quality  
>> metrics by moving away from a  document production model to a data  
>> production model. I think it's  unfortunate that a very large  
>> number of Hudson plugins essentially  duplicate many of the Maven  
>> plugins that exist because it wasn't a  huge change we made to  
>> collect data as opposed to producing a document.
>> In the same vein we will make any modifications necessary to the  
>> Maven  SCM API to integrate better with Hudson and Eclipse team  
>> providers.  When our Plexus/OSGi bridge work is done any component  
>> written in  Plexus will be available inside an OSGi environment as  
>> a bundle. I  don't know how popular OSGi will be as runtime for  
>> applications as it  has its great parts, but has some serious  
>> detractions as well. What is  certain is that OSGi rules on the  
>> developer desktop with Eclipse so we  have taken that into account  
>> and need to make sure the tools we  produce function equally well  
>> in Maven and Eclipse. We also feel that  Hudson rules in the arena  
>> of build automation and so we're focusing on  what we feel is an  
>> ideal set of tools consisting of Maven, Nexus,  Hudson, and Eclipse  
>> and we are working on production quality  integration between these  
>> four systems.
>> So the first thing we would like to contribute is the Plexus  
>> integration that Tom has worked on. This integration is will not  
>> work  with the current form of Hudson because an old version of the  
>> Maven  Embedder is used in the core of Hudson and it depends on a  
>> much older  version of Plexus. It's up to you guys but if you want  
>> the Plexus  integration in your SVN I am happy to work on a branch  
>> helping to  decouple the current form of Maven integration from the  
>> core so that  both versions of Plexus can exist. This would allow  
>> anyone to write a  Hudson plugin in much the same way they would  
>> write a Maven plugin.
>> We are also working on a new Maven job type and some new Hudson  
>> features which depend on Maven 3.x. So this work I wouldn't  
>> recommend  for public consumption yet, but as Maven 3.x reaches GA  
>> so will the  Hudson integration we are working on. So we are also  
>> happy to  contribute this if you are interested.  We would also  
>> like to work on  integrating JSecurity and our REST framework  
>> (currently based on  Restlet but moving toward Jersey). For anyone  
>> who is familiar with  Nexus we want to integrate the security  
>> systems and we want to be able  to create a UI for Hudson based on  
>> ExtJS. These parts we would also be  happy to contribute if you are  
>> interested. This is something that we  want at Sonatype and we  
>> fully realize this may not mesh with what you  want. We're not  
>> going to try and shove anything down anyone's throats.  We just  
>> want to be open about what we're working on and the direction  
>> we're going and if you guys want the code we're happy to contribute.
>> Beyond that we will be working on some commercial extensions. We  
>> want  to integrate a workflow system, create bullet proof release  
>> management  that is integrated with Nexus, tools for the automatic  
>> provisioning of  build nodes and custom data collections tools the  
>> creation of what we  think is a pretty cool dashboard idea.
>> Happy to answer any questions, and if people want the work that  
>> we've  slated for OSS we are more then happy to contribute it. We  
>> use Hudson  on a daily basis and couldn't live without it at this  
>> point so we feel  it only fair to give something back.
>> Thanks,
>> Jason
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Selfish deeds are the shortest path to self destruction.

  -- The Seven Samuari, Akira Kurosawa


---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Kohsuke Kawaguchi
Administrator
Jason van Zyl wrote:

>> As for the license, we have no intention of changing the license from
>> MIT (and even if we wanted to, we don't own the entire copyright of  
>> the
>> codebase anyway), but I think this points out the need to clarify the
>> copyright holders of the core Hudson codebase --- we currently have  
>> just
>> one LICENSE.txt in hudson/main that covers the codebase with a blanket
>> statement, but I need to do the copyright header clean-up to bring  
>> it to
>> the level that most other projects are in. This has long been overdue
>> anyway.
>
> If you are not making people sign contribution agreements then you  
> should probably start doing so because nothing is really safe for  
> commercial extension without all the legal aspects taken care of. This  
> is why Apache and Eclipse are so successful because they have the  
> legal work kept at the same level of importance as the technical work.
Yeah, I think you are right.

I just hope it doesn't affect the community in a negative way. I hate to
make it any more difficult to contribute changes. Between Jelly, Stapler
and Maven, technical hoops are hard enough as it stands today already...



>> Now, moving on to more technical things, it sounds like the first  
>> thing
>> that we'd want to do is to create a branch for the Plexus  
>> integration. I
>> have some questions about how that could co-exist with the existing
>> model of Hudson plugins, and it'd be great if I can see the code to
>> understand it myself.
>>
>> Could we do that as a starter?
>
> Absolutely. Tom has done the work thus far so he can commit the work.  
> I don't think it will take a lot of work to create some isolated  
> classloaders so the old/new plexus versions can work in the same  
> environment.
OK. I'll work with Tom about bringing this change into Hudson's
subversion repository, then.

I don't mind using a newer version of Plexus in Hudson --- the current
dependency comes through Maven embedder, and old components will continu
to work in new Plexus, right ;-) ?

Or does it not, and is that why you think classloader isolation is
necessary?


--
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: Sonatype's Hudson Plans for Maven Integration

Jason van Zyl-3

On 3-Feb-09, at 5:35 PM, Kohsuke Kawaguchi wrote:

> Jason van Zyl wrote:
>>> As for the license, we have no intention of changing the license  
>>> from
>>> MIT (and even if we wanted to, we don't own the entire copyright  
>>> of  the
>>> codebase anyway), but I think this points out the need to clarify  
>>> the
>>> copyright holders of the core Hudson codebase --- we currently  
>>> have  just
>>> one LICENSE.txt in hudson/main that covers the codebase with a  
>>> blanket
>>> statement, but I need to do the copyright header clean-up to  
>>> bring  it to
>>> the level that most other projects are in. This has long been  
>>> overdue
>>> anyway.
>> If you are not making people sign contribution agreements then you  
>> should probably start doing so because nothing is really safe for  
>> commercial extension without all the legal aspects taken care of.  
>> This  is why Apache and Eclipse are so successful because they have  
>> the  legal work kept at the same level of importance as the  
>> technical work.
>
> Yeah, I think you are right.
>
> I just hope it doesn't affect the community in a negative way. I  
> hate to make it any more difficult to contribute changes. Between  
> Jelly, Stapler and Maven, technical hoops are hard enough as it  
> stands today already...
>

If you are going to do anything commercial you don't have any choice.  
I am certain your own lawyers will stop any commercial effort until  
you know the pedigree of all code that contributes to your offering.  
You should probably get a standard contributors license agreement  
(CLA) in place and get people to sign and send it in before you give  
them commit access. At Apache if you don't sign the CLA you don't get  
your commit access. It's even more strict at Eclipse. It's not just  
for your own offerings but people cannot safely extend your code  
unless you do things like this. The effort is made at Apache and  
Eclipse to protect downstream consumers and re-distributors.

>
>
>>> Now, moving on to more technical things, it sounds like the first  
>>> thing
>>> that we'd want to do is to create a branch for the Plexus  
>>> integration. I
>>> have some questions about how that could co-exist with the existing
>>> model of Hudson plugins, and it'd be great if I can see the code to
>>> understand it myself.
>>>
>>> Could we do that as a starter?
>> Absolutely. Tom has done the work thus far so he can commit the  
>> work.  I don't think it will take a lot of work to create some  
>> isolated  classloaders so the old/new plexus versions can work in  
>> the same  environment.
>
> OK. I'll work with Tom about bringing this change into Hudson's  
> subversion repository, then.
>
> I don't mind using a newer version of Plexus in Hudson --- the  
> current dependency comes through Maven embedder, and old components  
> will continu to work in new Plexus, right ;-) ?
>

The versions of Plexus are not compatible but the old components will  
continue to work in the new version of Plexus.

> Or does it not, and is that why you think classloader isolation is  
> necessary?

If you want the current version of the embedder you are using and the  
new one you will need to separate them because they aren't compatible.

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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

To do two things at once is to do neither.

  -—Publilius Syrus, Roman slave, first century B.C.


---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Kohsuke Kawaguchi
Administrator
Jason van Zyl wrote:

> On 3-Feb-09, at 5:35 PM, Kohsuke Kawaguchi wrote:
>
>> Jason van Zyl wrote:
>>>> As for the license, we have no intention of changing the license  
>>>> from
>>>> MIT (and even if we wanted to, we don't own the entire copyright  
>>>> of  the
>>>> codebase anyway), but I think this points out the need to clarify  
>>>> the
>>>> copyright holders of the core Hudson codebase --- we currently  
>>>> have  just
>>>> one LICENSE.txt in hudson/main that covers the codebase with a  
>>>> blanket
>>>> statement, but I need to do the copyright header clean-up to  
>>>> bring  it to
>>>> the level that most other projects are in. This has long been  
>>>> overdue
>>>> anyway.
>>> If you are not making people sign contribution agreements then you  
>>> should probably start doing so because nothing is really safe for  
>>> commercial extension without all the legal aspects taken care of.  
>>> This  is why Apache and Eclipse are so successful because they have  
>>> the  legal work kept at the same level of importance as the  
>>> technical work.
>>
>> Yeah, I think you are right.
>>
>> I just hope it doesn't affect the community in a negative way. I  
>> hate to make it any more difficult to contribute changes. Between  
>> Jelly, Stapler and Maven, technical hoops are hard enough as it  
>> stands today already...
>>
>
> If you are going to do anything commercial you don't have any choice.  
> I am certain your own lawyers will stop any commercial effort until  
> you know the pedigree of all code that contributes to your offering.  
> You should probably get a standard contributors license agreement  
> (CLA) in place and get people to sign and send it in before you give  
> them commit access. At Apache if you don't sign the CLA you don't get  
> your commit access. It's even more strict at Eclipse. It's not just  
> for your own offerings but people cannot safely extend your code  
> unless you do things like this. The effort is made at Apache and  
> Eclipse to protect downstream consumers and re-distributors.
Right.

>>>> Now, moving on to more technical things, it sounds like the first  
>>>> thing
>>>> that we'd want to do is to create a branch for the Plexus  
>>>> integration. I
>>>> have some questions about how that could co-exist with the existing
>>>> model of Hudson plugins, and it'd be great if I can see the code to
>>>> understand it myself.
>>>>
>>>> Could we do that as a starter?
>>> Absolutely. Tom has done the work thus far so he can commit the  
>>> work.  I don't think it will take a lot of work to create some  
>>> isolated  classloaders so the old/new plexus versions can work in  
>>> the same  environment.
>>
>> OK. I'll work with Tom about bringing this change into Hudson's  
>> subversion repository, then.
>>
>> I don't mind using a newer version of Plexus in Hudson --- the  
>> current dependency comes through Maven embedder, and old components  
>> will continu to work in new Plexus, right ;-) ?
>>
>
> The versions of Plexus are not compatible but the old components will  
> continue to work in the new version of Plexus.
>
>> Or does it not, and is that why you think classloader isolation is  
>> necessary?
>
> If you want the current version of the embedder you are using and the  
> new one you will need to separate them because they aren't compatible.
OK, thanks for the information.

--
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: Sonatype's Hudson Plans for Maven Integration

Henrik Lynggaard Hansen
In reply to this post by Jason van Zyl-3
2009/2/4 Jason van Zyl <[hidden email]>:

>
> If you are going to do anything commercial you don't have any choice. I am
> certain your own lawyers will stop any commercial effort until you know the
> pedigree of all code that contributes to your offering. You should probably
> get a standard contributors license agreement (CLA) in place and get people
> to sign and send it in before you give them commit access. At Apache if you
> don't sign the CLA you don't get your commit access. It's even more strict
> at Eclipse. It's not just for your own offerings but people cannot safely
> extend your code unless you do things like this. The effort is made at
> Apache and Eclipse to protect downstream consumers and re-distributors.

As long as we can avoid going for postal snail mail for these forms, I
think we can hopefully keep the PITA effect low. Email of PDF
documents could be perhaps be a way to go...

best regard
henrik

---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Tom Huybrechts
In reply to this post by Kohsuke Kawaguchi
>>
>> Absolutely. Tom has done the work thus far so he can commit the work.  I
>> don't think it will take a lot of work to create some isolated  classloaders
>> so the old/new plexus versions can work in the same  environment.
>
> OK. I'll work with Tom about bringing this change into Hudson's subversion
> repository, then.
>

I've committed the plexus integration into
https://svn.dev.java.net/svn/hudson/branches/plexus
Maybe not the best place, since it is not a branch of trunk, but we
can give it a better home later.
It is:
- a library containing the plexus plugin strategy
- a custom hudson-war that packages that library
- an example plugin - the javadoc publisher built with Plexus

Tom

---------------------------------------------------------------------
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: Sonatype's Hudson Plans for Maven Integration

Jason van Zyl-3
Do you have a CLA I can sign? Then I can help Tom :-)

I can draft you a CLA if you like or the Sun folks can draft one, but  
I think you need one. I'll be the first :-)

On 4-Feb-09, at 2:03 PM, Tom Huybrechts wrote:

>>>
>>> Absolutely. Tom has done the work thus far so he can commit the  
>>> work.  I
>>> don't think it will take a lot of work to create some isolated  
>>> classloaders
>>> so the old/new plexus versions can work in the same  environment.
>>
>> OK. I'll work with Tom about bringing this change into Hudson's  
>> subversion
>> repository, then.
>>
>
> I've committed the plexus integration into
> https://svn.dev.java.net/svn/hudson/branches/plexus
> Maybe not the best place, since it is not a branch of trunk, but we
> can give it a better home later.
> It is:
> - a library containing the plexus plugin strategy
> - a custom hudson-war that packages that library
> - an example plugin - the javadoc publisher built with Plexus
>
> Tom
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

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]

Loading...