Roadmap discussion

858 views
Skip to first unread message

Kohsuke Kawaguchi

unread,
Feb 10, 2011, 1:18:36 PM2/10/11
to jenkin...@googlegroups.com

With the good portion of the renaming work behind us, I think it's good
to think about the key areas of Jenkins that need improvements. It
should cover both the underlying architectural problems (since some of
those points raised by others are quite valid), and user-level
functionality problems.

I don't want this to turn into a laundry wish list, so I'm only sending
this to the dev list. But some of the major issues I've heard include:

- revisiting release process

- Use of IoC. (There are two branches where this is implemented, one
for Guice and the other for Spring.)

- Better template engine front-end. I say frontend because it needs to
drive the same Jelly backend to be compatible with existing stuff.
There's currently a version that does this in Groovy.

- 1st class support for build chaining / workflow.

- Startup time


I'm curious if I'm missing big ones, and the prioritization of it. I
think it's good to have that.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

Romain Seguy

unread,
Feb 10, 2011, 1:24:30 PM2/10/11
to jenkin...@googlegroups.com, Kohsuke Kawaguchi
Hi,

What about also having (1) some kind of versioning capabilities, (2) a
jobs template feature and (3) a better resource mechanism to easily plug
to application servers (like what exists for installers)?

Regards,
Romain

Le Thu, 10 Feb 2011 19:18:36 +0100, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> a écrit:

Jesse Farinacci

unread,
Feb 10, 2011, 1:29:50 PM2/10/11
to jenkin...@googlegroups.com
Greetings,

On Thu, Feb 10, 2011 at 1:18 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
>
> With the good portion of the renaming work behind us, I think it's good to
> think about the key areas of Jenkins that need improvements.

My recommendation would be that we use Jira or Confluence to catalog
these issues. It would help if we had a tag to designate them, perhaps
RFE or RoadMap or some such. If we use JIRA, then we can easily
reference them with commits, etc. There's also a vote/watch mechanism
that would help gauge interest.. with Confluence, things are easier to
mark up and we'd have history control.

Whichever we choose, I think either are probably better in the long
term than email.

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

Kohsuke Kawaguchi

unread,
Feb 10, 2011, 1:37:04 PM2/10/11
to jenkin...@googlegroups.com, Jesse Farinacci
On 02/10/2011 10:29 AM, Jesse Farinacci wrote:
> Greetings,
>
> On Thu, Feb 10, 2011 at 1:18 PM, Kohsuke Kawaguchi
> <kkawa...@cloudbees.com> wrote:
>>
>> With the good portion of the renaming work behind us, I think it's good to
>> think about the key areas of Jenkins that need improvements.
>
> My recommendation would be that we use Jira or Confluence to catalog
> these issues. It would help if we had a tag to designate them, perhaps
> RFE or RoadMap or some such. If we use JIRA, then we can easily
> reference them with commits, etc. There's also a vote/watch mechanism
> that would help gauge interest.. with Confluence, things are easier to
> mark up and we'd have history control.

Makes sense to me. Let's do JIRA.

>
> Whichever we choose, I think either are probably better in the long
> term than email.
>
> -Jesse
>


--

Frédéric Camblor

unread,
Feb 10, 2011, 1:43:25 PM2/10/11
to jenkin...@googlegroups.com
Hi everyone,

I think something like a "compilation compatibility test" would be interesting for plugins.
I don't know if it is possible, but something which would take current parent pom version number (let's say 1.390) and try to virtually increment it through last released version, and try a "mvn test-compile" (with maven-invoker-plugin for example) on the current source code.

Obviously, these tests should be deactivated by default (it could take a long long time downloading every hudson releases with deps), but would be interesting to execute on a "plugin compat matrix job" jenkins job on http://ci.jenkins-ci.org/ let's say... on a weekly frequency.

Frédéric

2011/2/10 Jesse Farinacci <jie...@gmail.com>



--
Frédéric Camblor

Bap

unread,
Feb 10, 2011, 1:39:50 PM2/10/11
to jenkin...@googlegroups.com
Quoting Romain Seguy <romain...@gmail.com>:

> Hi,
>
> What about also having (1) some kind of versioning capabilities, (2)
> a jobs template feature and (3) a better resource mechanism to
> easily plug to application servers (like what exists for installers)?
>
> Regards,
> Romain
>

+1 Configuration versioning

Robert Collins

unread,
Feb 10, 2011, 2:32:11 PM2/10/11
to jenkin...@googlegroups.com
One thing that would be really useful for folk running hudson behind
proxies would be for it to support knowing its remote url better -
there are a few ways but basically it needs to understand that its
root might be
https://example.com/middlething/<jenkins starts here>

At the moment the support for this is pretty vestigial and tends to
interact poorly with url generation. A colleague of mine was doing
some head-desking the other day trying to use the openid plugin in
this configuration : it generated incorrect urls and failed. I can get
him to file a bug if you like.

-Rob

Jesse Farinacci

unread,
Feb 10, 2011, 3:19:06 PM2/10/11
to jenkin...@googlegroups.com
Greetings

On Thu, Feb 10, 2011 at 1:18 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
>

> - revisiting release process

http://issues.jenkins-ci.org/browse/JENKINS-8750

> - Use of IoC. (There are two branches where this is implemented, one
>  for Guice and the other for Spring.)

http://issues.jenkins-ci.org/browse/JENKINS-8751

> - Better template engine front-end. I say frontend because it needs to
>  drive the same Jelly backend to be compatible with existing stuff.
>  There's currently a version that does this in Groovy.

http://issues.jenkins-ci.org/browse/JENKINS-8752

> - 1st class support for build chaining / workflow.

http://issues.jenkins-ci.org/browse/JENKINS-8753

> - Startup time

http://issues.jenkins-ci.org/browse/JENKINS-8754

Finally, there's an issue with attaching labels right now, I asked
@abayer to investigate.

marcelstoer

unread,
Feb 10, 2011, 4:27:07 PM2/10/11
to Jenkins Developers

> - Startup time

+1, it's cool I can vote for that in JIRA now ;-)

marcelstoer

unread,
Feb 10, 2011, 4:25:31 PM2/10/11
to Jenkins Developers
On Feb 10, 8:32 pm, Robert Collins <robe...@robertcollins.net> wrote:
> One thing that would be really useful for folk running hudson behind
> proxies would be for it to support knowing its remote url better -
> there are a few ways but basically it needs to understand that its
> root might behttps://example.com/middlething/<jenkins starts here>

Hhmm, I'm not quite sure I understand but I think these issues can be
addresses if you run Jenkins in Tomcat behind Apache with Tomcat AJP
Connector Settings[1].

Cheers,

[1] http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html

Stefan Wolf

unread,
Feb 10, 2011, 5:39:03 PM2/10/11
to Jenkins Developers
We should improve the test for core. There are some problems
- Tests take very long to run
- Tests fail indeterministic (e.g.hudson.slaves.NodeProvisionerTest)
- do not work on all architectures (e.g. Mac)

These are probably some reasons why the CI-Build of Jenkins on Jenkins
is basically always unstable of failed. This is somewhat embarassing
for a CI-Server.

Some possible directions:
- Modularize the tests + the build
- Separate GUI-Tests (like roundtrip) and backend tests - one probably
doesn't need a webserver to run many tests
- More Unit tests instead of integration tests
...

This is something where Jenkins really could improve and which would
have direct consequences for build stability.

Best regards,
Stefan

Arnaud Héritier

unread,
Feb 10, 2011, 5:41:20 PM2/10/11
to jenkin...@googlegroups.com
On Thu, Feb 10, 2011 at 7:18 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
>
> With the good portion of the renaming work behind us, I think it's good to
> think about the key areas of Jenkins that need improvements. It should cover
> both the underlying architectural problems (since some of those points
> raised by others are quite valid), and user-level functionality problems.
>
> I don't want this to turn into a laundry wish list, so I'm only sending this
> to the dev list. But some of the major issues I've heard include:
>
> - revisiting release process

Even if there isn't something really new it could give us some ideas
about the process we could follow :
http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/
In all cases I think that our target must be that a release must
become a none-event.


>
> - Use of IoC. (There are two branches where this is implemented, one
>  for Guice and the other for Spring.)

+1 for Guice. It's working fine and is nowadays lighter than spring
(even if this one proposes many more services/integrations)

>
> - Better template engine front-end. I say frontend because it needs to
>  drive the same Jelly backend to be compatible with existing stuff.
>  There's currently a version that does this in Groovy.

The main advantage in Jelly is that it is easy to understand.
These are just few more xml tags in a x(h)tml sub(page)
For me it is one reason of the hight number of contributions
After that there are many issues with it has it is difficult to really
put some logic in pages.

I'll be in favor to another scripting solution like groovy (templates)
to easily add/edit pages but with something more powerful (and less
buggy) than Jelly.

In hudson side they would like to promote GWT, JSF or another
"standard" framework. I won't be agree with this choice as even if
they are standard, they are heavy in term of development process and a
few part of Java developers are able correctly using them. A large
part aren't java web developers or are always using old technologies
like struts .....

>
> - 1st class support for build chaining / workflow.
>

+1

> - Startup time
>

+1000. I don't understand why hudson at startup time reads all the
history of builds (while few users are effectively reading them). A
lazy loading of them could I think really improve things.

Arnaud Héritier

unread,
Feb 10, 2011, 5:43:24 PM2/10/11
to jenkin...@googlegroups.com
2011/2/10 Arnaud Héritier <arnaud....@exoplatform.com>:

JENKINS (My mum will punish me. I'll write it 1000 times this WE)

Arnaud Héritier

unread,
Feb 10, 2011, 5:44:35 PM2/10/11
to jenkin...@googlegroups.com
not easy but +1000 too

Olivier Lamy

unread,
Feb 11, 2011, 3:50:49 AM2/11/11
to jenkin...@googlegroups.com
Hello,

2011/2/10 Stefan Wolf <glow...@gmail.com>:


> We should improve the test for core. There are some problems
> - Tests take very long to run
> - Tests fail indeterministic (e.g.hudson.slaves.NodeProvisionerTest)
> - do not work on all architectures (e.g. Mac)

Sure It looks some tests related to maven integration (which I have
introduced recently) are failing on Mac.
Sorry most of the time I test on windauze,ubuntu,solaris (I don't have
a Mac but donations are welcome :-) ).

Regarding Guice versus Spring, I would prefer guice for two reasons :
* will be easier for maven integration :-)
* guice has an extension for binding spring beans . So if folks
prefers spring they will be able to use it too.

Regarding template engine : sure we must be able to support more
languages : groovy, why not velocity too ?)


> These are probably some reasons why the CI-Build of Jenkins on Jenkins
> is basically always unstable of failed. This is somewhat embarassing
> for a CI-Server.
>
> Some possible directions:
> - Modularize the tests + the build
> - Separate GUI-Tests (like roundtrip) and backend tests - one probably
> doesn't need a webserver to run many tests
> - More Unit tests instead of integration tests
> ...
>
> This is something where Jenkins really could improve and which would
> have direct consequences for build stability.
>
> Best regards,
>  Stefan

--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

Baptiste MATHUS

unread,
Feb 11, 2011, 1:03:52 PM2/11/11
to jenkin...@googlegroups.com


Le 10 févr. 2011 19:43, "Frédéric Camblor" <fcam...@gmail.com> a écrit :
>
> Hi everyone,
>
> I think something like a "compilation compatibility test" would be interesting for plugins.
> I don't know if it is possible, but something which would take current parent pom version number (let's say 1.390) and try to virtually increment it through last released version, and try a "mvn test-compile" (with maven-invoker-plugin for example) on the current source code.

Hi Fred :),

Wouldn't it be something quite achievable using clirr?

Cheers
Baptiste

Frédéric Camblor

unread,
Feb 11, 2011, 1:35:41 PM2/11/11
to jenkin...@googlegroups.com
Hi Baptiste,

I never used clirr, but isn't it a maven plugin allowing to report compatibility changes between 2 artefact versions ?
It would be a first step to list every API changes between 2 jenkins core release.

My question was larger ... for example, if tomorrow, spring dependencies are replaced by Guice ones (since we only want dependency injection, and not spring utility classes anymore), how will we be able, in a plugin, to notice that in out dependencies ?

For now, in my plugin, I fix a parent version (let's say X) which means "I am sure that my plugin is compatible with Jenkins version X, moreover, the plugin is compatible on versions Y only and only if there have not been API-I-rely-on changes on version Y (that is : for small plugins, it is really rare !)".

Quite difficult to identify (the simplest way is, to my mind, to compile against each core versions to ensure a "compile time compatibility")

Frédéric

2011/2/11 Baptiste MATHUS <bma...@gmail.com>



--
Frédéric Camblor

Eirik Bjørsnøs

unread,
Feb 11, 2011, 3:59:10 PM2/11/11
to jenkin...@googlegroups.com
On Thu, Feb 10, 2011 at 7:18 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
>
> With the good portion of the renaming work behind us, I think it's good to
> think about the key areas of Jenkins that need improvements.

> - Use of IoC. (There are two branches where this is implemented, one


>  for Guice and the other for Spring.)

Do we need to choose? Here's my two Norwegian kroner on the topic:

When I designed the plugin API for SVNSearch, an important design goal
was to not hard code the API to a certain DI framework. This turned
out to work really, really well.

The plugin authors can choose among Spring, Guice or other DI
frameworks based on their experience and the needs of the particular
plugin. Similarly, the application services can be managed using
Spring or Guice. And it's perfectly OK to mix Spring application
services with Guice plugins etc.

This also makes the platform more future proof as new DI frameworks
can be added with no API changes.

The plugin framework has later been extracted source into Jexmec [1]
and released as open source under the ASL v2 license.

Jexmec is designed around three key abstractions: Service look up is
abstracted by the ServiceLocator [2] interface while plugin
construction and dependency injection is handled through the
PluginLoader [3] abstraction. There's also a PluginClassLoaderProvider
[4] which abstracts how plugin class loaders are discovered. (Be it
normal class path or OSGi. (yuk!))

There's a five minute intro [5] with an example showing how these work
together in the plugin manager.

I'm not going to suggest Jenkins change it's plugin framework at this
point. But if Jexmec can be of any inspiration with regards to DI
agnosticity, you're welcome to steal any ideas that you find useful
:-)

I'd say the DI framework is an implementation detail, don't let it
leak into the API when you don't have to.

Thanks,
Eirik.

PS: I actually tried implementing a PluginLoader for the HK2 kernel,
but quickly got lost in the component model. Dare I say "Womb" and
"Habitat"? :-)

[1] http://jexmec.org/
[2] http://opensource.kantega.no/svn/jexmec/trunk/api/src/main/java/org/kantega/jexmec/ServiceLocator.java
[3] http://opensource.kantega.no/svn/jexmec/trunk/api/src/main/java/org/kantega/jexmec/PluginLoader.java
[4] http://opensource.kantega.no/svn/jexmec/trunk/api/src/main/java/org/kantega/jexmec/PluginClassLoaderRegistry.java
[5] http://jexmec.org/getting-started/

Ulli Hafner

unread,
Feb 13, 2011, 12:20:55 PM2/13/11
to jenkin...@googlegroups.com
What we also should consider is the list of top voted issues.

I created a dashboard in Jira where you can see the top 15:
http://issues.jenkins-ci.org/secure/Dashboard.jspa?selectPageId=10120

One feature I would like to add to the roadmap is a UI enhancement of
the job page: this page currently is static. However, it would be a
better user experience if that page could be dynamically organized like
the 'dashboard-view' where users can add, remove and rearrange the
visible trend graphs, see JENKINS-6050.

Ulli

teilo

unread,
Feb 13, 2011, 5:23:32 PM2/13/11
to Jenkins Developers


On Feb 10, 10:39 pm, Stefan Wolf <glowwo...@gmail.com> wrote:
> We should improve the test for core. There are some problems
> - Tests take very long to run
> - Tests fail indeterministic (e.g.hudson.slaves.NodeProvisionerTest)
> - do not work on all architectures (e.g. Mac)
>
> These are probably some reasons why the CI-Build of Jenkins on Jenkins
> is basically always unstable of failed. This is somewhat embarassing
> for a CI-Server.

Definately agree with tests.
Although they don't take too long for me - I think I have only ever
updated once and had it pass all the tests (on Ubuntu - sadly I had to
ditch my Windows dev env which is so much nicer)

However I don't think that we just need more of them (or faster ones)
after all if you look at the origin/master for the past month it's
obvious that people don't run them before checking in...
Gerrit can be quite useful in this regard - but then that will need a
rework of the tests as the build has to be snappy. (unfortunately
running multiple gerrit builds in parallel locks up my Hudson
instances and I have not yet got around to filing a bug report with
stack traces).

To be fair - I don't do much Jenkins core dev - I just want to do some
fixes that impact my plugin (and any other easy ones) but it makes it
hard with the current setup (either you take a gamble that you haven't
broken anything and then someone else needs to clean it up - or you
ignore the tests)

Vojtech Juranek

unread,
Feb 14, 2011, 3:42:34 AM2/14/11
to jenkin...@googlegroups.com
Hi,

> - 1st class support for build chaining / workflow.

I think it would be useful to make workflow as independent on the rest of
Hudson core as possible, so that the default implementation can be replaced by
another. I mean especially to make possible to use some rules engine (e.g.
drools [1]) or business process management tool (e.g. jbmp [2]) for defining
the workflow.

I posted this idea into JIRA [3], but I'm wondering, if this make sence to you
or not (overkill, to much changes needed in the code, etc.)

Thanks
Vojtech

[1] http://www.jboss.org/drools
[2] http://www.jboss.org/jbpm
[3] http://issues.jenkins-ci.org/browse/JENKINS-8753

David Karlsen

unread,
Feb 16, 2011, 5:59:28 AM2/16/11
to jenkin...@googlegroups.com
http://issues.jenkins-ci.org/browse/JENKINS-1762
http://issues.jenkins-ci.org/browse/JENKINS-7813
http://issues.jenkins-ci.org/browse/JENKINS-7921
http://issues.jenkins-ci.org/browse/JENKINS-8177
http://issues.jenkins-ci.org/browse/JENKINS-3524

and possibly http://issues.jenkins-ci.org/browse/JENKINS-593

all deal with the same issue (which is very old) - so the votes add up.
Could this then fit into the list?

I see it as a crucial feature, and old/big annoying bug - so getting it fixed sooner than later would be very good.

2011/2/13 Ulli Hafner <ullrich...@gmail.com>



--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Jorg Heymans

unread,
Feb 17, 2011, 3:33:00 AM2/17/11
to jenkin...@googlegroups.com
FWIW we're not seeing this at all, artifacts of 50MB and upwards transfer with normal transfer speeds. Master is solaris, slaves winxp vmware instances. "Hudson" v1.376

Jorg


Kohsuke Kawaguchi

unread,
Feb 17, 2011, 10:44:29 AM2/17/11
to jenkin...@googlegroups.com, Robert Collins
On 02/10/2011 11:32 AM, Robert Collins wrote:
> One thing that would be really useful for folk running hudson behind
> proxies would be for it to support knowing its remote url better -
> there are a few ways but basically it needs to understand that its
> root might be
> https://example.com/middlething/<jenkins starts here>

This sounds more of a documentation improvement than anything
substantial. Jenkins behind reverse proxy works well in general --- you
just need to match up the context path when you do, and that's a
standard requirement.

The only other setting that needs to be done right is to tell Jenkins
its own root URL.


> At the moment the support for this is pretty vestigial and tends to
> interact poorly with url generation. A colleague of mine was doing
> some head-desking the other day trying to use the openid plugin in
> this configuration : it generated incorrect urls and failed. I can get
> him to file a bug if you like.

v1.0 of it had a bug in not using the configured root URL. v1.1 of the
OpenID plugin should work correctly in this regard.

>
> -Rob

Kohsuke Kawaguchi

unread,
Feb 17, 2011, 10:50:40 AM2/17/11
to jenkin...@googlegroups.com, teilo

So I think this testing space is one area that needs improvement, then.

- identify some subsets of tests that can be run faster
(maybe another mode of a harness? some methodology like mocking?)

- fix flakiness and platform issues

- have a backend set up such that JoJ runs more tests on commits
(Gerrit?)

Kohsuke Kawaguchi

unread,
Feb 17, 2011, 10:59:12 AM2/17/11
to jenkin...@googlegroups.com, Arnaud Héritier
On 02/10/2011 02:41 PM, Arnaud H�ritier wrote:
> On Thu, Feb 10, 2011 at 7:18 PM, Kohsuke Kawaguchi
> <kkawa...@cloudbees.com> wrote:
>>
>> With the good portion of the renaming work behind us, I think it's good to
>> think about the key areas of Jenkins that need improvements. It should cover
>> both the underlying architectural problems (since some of those points
>> raised by others are quite valid), and user-level functionality problems.
>>
>> I don't want this to turn into a laundry wish list, so I'm only sending this
>> to the dev list. But some of the major issues I've heard include:
>>
>> - revisiting release process
>
> Even if there isn't something really new it could give us some ideas
> about the process we could follow :
> http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/
> In all cases I think that our target must be that a release must
> become a none-event.

I think it's a non-event already, no?

>> - Use of IoC. (There are two branches where this is implemented, one
>> for Guice and the other for Spring.)
>
> +1 for Guice. It's working fine and is nowadays lighter than spring
> (even if this one proposes many more services/integrations)
>
>>
>> - Better template engine front-end. I say frontend because it needs to
>> drive the same Jelly backend to be compatible with existing stuff.
>> There's currently a version that does this in Groovy.
>
> The main advantage in Jelly is that it is easy to understand.
> These are just few more xml tags in a x(h)tml sub(page)
> For me it is one reason of the hight number of contributions
> After that there are many issues with it has it is difficult to really
> put some logic in pages.
>
> I'll be in favor to another scripting solution like groovy (templates)
> to easily add/edit pages but with something more powerful (and less
> buggy) than Jelly.
>
> In hudson side they would like to promote GWT, JSF or another
> "standard" framework. I won't be agree with this choice as even if
> they are standard, they are heavy in term of development process and a
> few part of Java developers are able correctly using them. A large
> part aren't java web developers or are always using old technologies
> like struts .....

When I think of it, what I lack with Jelly is (1) IDE edit assistance
support (for Eclipse users), (2) debugger support, and (3) type safety
(nice to have.)

Groovy passes the bar in all these regards. I suspect Velocity doesn't,
but I could be wrong. GWT/JSF is orthogonal/complementary because we
need something like Jelly that weave fragments together from different
places, and GWT in my eyes is more for having intensely interactive UI
widgets (like update center table) --- those are things that get weaved
together.

Kohsuke Kawaguchi

unread,
Feb 17, 2011, 11:03:29 AM2/17/11
to jenkin...@googlegroups.com, Eirik Bjørsnøs
On 02/11/2011 12:59 PM, Eirik Bj�rsn�s wrote:
> On Thu, Feb 10, 2011 at 7:18 PM, Kohsuke Kawaguchi
> <kkawa...@cloudbees.com> wrote:
>>
>> With the good portion of the renaming work behind us, I think it's good to
>> think about the key areas of Jenkins that need improvements.
>
>> - Use of IoC. (There are two branches where this is implemented, one
>> for Guice and the other for Spring.)
>
> Do we need to choose? Here's my two Norwegian kroner on the topic:
>
> When I designed the plugin API for SVNSearch, an important design goal
> was to not hard code the API to a certain DI framework. This turned
> out to work really, really well.
>
> The plugin authors can choose among Spring, Guice or other DI
> frameworks based on their experience and the needs of the particular
> plugin. Similarly, the application services can be managed using
> Spring or Guice. And it's perfectly OK to mix Spring application
> services with Guice plugins etc.
>
> This also makes the platform more future proof as new DI frameworks
> can be added with no API changes.
>
> The plugin framework has later been extracted source into Jexmec [1]
> and released as open source under the ASL v2 license.

Thanks. I'll look into this.


> Jexmec is designed around three key abstractions: Service look up is
> abstracted by the ServiceLocator [2] interface while plugin
> construction and dependency injection is handled through the
> PluginLoader [3] abstraction. There's also a PluginClassLoaderProvider
> [4] which abstracts how plugin class loaders are discovered. (Be it
> normal class path or OSGi. (yuk!))
>
> There's a five minute intro [5] with an example showing how these work
> together in the plugin manager.
>
> I'm not going to suggest Jenkins change it's plugin framework at this
> point. But if Jexmec can be of any inspiration with regards to DI
> agnosticity, you're welcome to steal any ideas that you find useful
> :-)
>
> I'd say the DI framework is an implementation detail, don't let it
> leak into the API when you don't have to.

I could be wrong, but it's when you do the wiring when it gets hard to
avoid the framework dependency. So while some plugins might be able to
avoid implementation dependency, the system as a whole needs to pick one.


> Thanks,
> Eirik.
>
> PS: I actually tried implementing a PluginLoader for the HK2 kernel,
> but quickly got lost in the component model. Dare I say "Womb" and
> "Habitat"? :-)

I've worked on some of those, and I'd like to think that it's a
reasonable one, but oh well ... ;-)

Kohsuke Kawaguchi

unread,
Feb 17, 2011, 11:04:47 AM2/17/11
to jenkin...@googlegroups.com

Good point.

For example, modular email notification support has been around forever.
Indeed it's time to act on those.

dan twining

unread,
Feb 17, 2011, 11:05:59 AM2/17/11
to jenkin...@googlegroups.com


...., and GWT in my eyes is more for having intensely interactive UI widgets (like update center table) --- those are things that get weaved together.



I don't know much about this sort of stuff, but is that not what the UI Binder part of GWT is designed to do (i.e. xml-based declarative "weaving" of widgets)? I love GWT in general, but have no idea how it could fit in with Jenkins

Kohsuke Kawaguchi

unread,
Feb 17, 2011, 11:05:14 AM2/17/11
to jenkin...@googlegroups.com, Vojtech Juranek
On 02/14/2011 12:42 AM, Vojtech Juranek wrote:
> Hi,
>
>> - 1st class support for build chaining / workflow.
>
> I think it would be useful to make workflow as independent on the rest of
> Hudson core as possible, so that the default implementation can be replaced by
> another. I mean especially to make possible to use some rules engine (e.g.
> drools [1]) or business process management tool (e.g. jbmp [2]) for defining
> the workflow.

Yes, I think such independence is assumed.

> I posted this idea into JIRA [3], but I'm wondering, if this make sence to you
> or not (overkill, to much changes needed in the code, etc.)
>
> Thanks
> Vojtech
>
> [1] http://www.jboss.org/drools
> [2] http://www.jboss.org/jbpm
> [3] http://issues.jenkins-ci.org/browse/JENKINS-8753
>

Stephen Connolly

unread,
Feb 17, 2011, 1:51:25 PM2/17/11
to jenkin...@googlegroups.com, Arnaud Héritier

I have some thoughts... we can talk about them sometime soon ;-)

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

On 17 Feb 2011 16:01, "Kohsuke Kawaguchi" <kkawa...@cloudbees.com> wrote:

Arnaud Héritier

unread,
Feb 17, 2011, 3:46:01 PM2/17/11
to Kohsuke Kawaguchi, jenkin...@googlegroups.com


2011/2/17 Kohsuke Kawaguchi <kkawa...@cloudbees.com>

On 02/10/2011 02:41 PM, Arnaud Héritier wrote:
On Thu, Feb 10, 2011 at 7:18 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com>  wrote:

 With the good portion of the renaming work behind us, I think it's good to
 think about the key areas of Jenkins that need improvements. It should cover
 both the underlying architectural problems (since some of those points
 raised by others are quite valid), and user-level functionality problems.

 I don't want this to turn into a laundry wish list, so I'm only sending this
 to the dev list. But some of the major issues I've heard include:

 - revisiting release process

Even if there isn't something really new it could give us some ideas
about the process we could follow :
http://techcrunch.com/2011/01/11/google-chrome-release-cycle-slideshow/
In all cases I think that our target must be that a release must
become a none-event.

I think it's a non-event already, no?

I admit I don't know as you are doing it :-)
If you say it, I'll believe you.
With the ability to do a release per week I think it is.

 


 - Use of IoC. (There are two branches where this is implemented, one
  for Guice and the other for Spring.)

+1 for Guice. It's working fine and is nowadays lighter than spring
(even if this one proposes many more services/integrations)


 - Better template engine front-end. I say frontend because it needs to
  drive the same Jelly backend to be compatible with existing stuff.
  There's currently a version that does this in Groovy.

The main advantage in Jelly is that it is easy to understand.
These are just few more xml tags in a x(h)tml sub(page)
For me it is one reason of the hight number of contributions
After that there are many issues with it has it is difficult to really
put some logic in pages.

I'll be in favor to another scripting solution like groovy (templates)
to easily add/edit pages but with something more powerful (and less
buggy) than Jelly.

In hudson side they would like to promote GWT, JSF or another
"standard" framework. I won't be agree with this choice as even if
they are standard, they are heavy in term of development process and a
few part of Java developers are able correctly using them. A large
part aren't java web developers or are always using old technologies
like struts .....

When I think of it, what I lack with Jelly is (1) IDE edit assistance support (for Eclipse users), (2) debugger support, and (3) type safety (nice to have.)

I agree

vtintillier

unread,
Feb 17, 2011, 3:50:05 PM2/17/11
to jenkin...@googlegroups.com
I think what was meant was that upgrading to a new version should become a no event (was saying that each new release came with new bugs).

2011/2/17 Arnaud Héritier <arnaud....@exoplatform.com>

Arnaud Héritier

unread,
Feb 17, 2011, 3:52:51 PM2/17/11
to jenkin...@googlegroups.com, vtintillier
It is a another but complementary issue.
I agree that a better QA should be include in the release cycle.
This is what is happening for chrome with stable/beta/dev branches : frequency vs QA level

Eirik Bjørsnøs

unread,
Feb 17, 2011, 5:42:33 PM2/17/11
to jenkin...@googlegroups.com
>> I'd say the DI framework is an implementation detail, don't let it
>> leak into the API when you don't have to.
>
> I could be wrong, but it's when you do the wiring when it gets hard to avoid
> the framework dependency. So while some plugins might be able to avoid
> implementation dependency, the system as a whole needs to pick one.


Interesting. I'd say it's the other way around. Each plugin is
responsible for doing its own wiring of the plugin class and any
internal components. Wiring could be done with a Guice Module or as a
Spring application context. In that regard each plugin dependens on
the framework / api it uses for wiring.

Any communication between application code and plugin code happens via
the application's plugin API, which is free of dependencies of any DI
framework and actually free of dependencies on Jexmec.

The only part of the application code that needs to know about Jexmec
or dependency injection frameworks is the bootstrapping of the plugin
framework:

PluginManager pm = new DefaultPluginManager(HudsonPlugin.class)
.addPluginLoader(new GuicePluginLoader())
.addPluginLoader(new GuicePluginLoader())

Eirik Bjørsnøs

unread,
Feb 17, 2011, 6:01:32 PM2/17/11
to jenkin...@googlegroups.com
>> I could be wrong, but it's when you do the wiring when it gets hard to avoid
>> the framework dependency. So while some plugins might be able to avoid
>> implementation dependency, the system as a whole needs to pick one.

[..]

> PluginManager pm = new DefaultPluginManager(HudsonPlugin.class)
>       .addPluginLoader(new GuicePluginLoader())
> .addPluginLoader(new GuicePluginLoader())

Trying to indent code in GMail apparently made GMail think I wanted to
send the email. Maybe it noticed i wrote the H-word :-)

I meant to sketch up something like the following bootstapping code:

PluginManager pm = new DefaultPluginManager(JenkinsPlugin.class)
.addPluginLoader(new GuicePluginLoader())
.addPluginLoader(new SpringPluginLoader()).start();

You can then pass the PluginManager around, or even better wrap it
with an Iterable<JenkinsPlugin> to remove the dependency on the plugin
framework implementation alltogether.

Anyway, what I was trying to show was that it is quite possible to
build a plugin api for an application that is agnostic as to which DI
framework plugins should be wired with. But you're right that each
particular plugin needs to know about its own wiring. In this regard,
JSR-330 won't really be of much help, although it will make the
non-wiring part of the code portable between DI frameworks. Probably
more useful for reuse of shared components.

Eirik.

Paul Sandoz

unread,
Mar 4, 2011, 11:08:51 AM3/4/11
to jenkin...@googlegroups.com

On Feb 17, 2011, at 8:05 AM, dan twining wrote:



...., and GWT in my eyes is more for having intensely interactive UI widgets (like update center table) --- those are things that get weaved together.



I don't know much about this sort of stuff, but is that not what the UI Binder part of GWT is designed to do (i.e. xml-based declarative "weaving" of widgets)? I love GWT in general, but have no idea how it could fit in with Jenkins

IIUC i don't think that makes any difference w.r.t. to the way GWT compilation works; the UI Binder is a way of declaratively defining layouts rather than programmatically in Java source.

Having said that since GWT generates JavaScript it should be possible to embed within HTML/Jelly. The question is to what granularity. It's gonna be easier to integrate for more isolated areas like the update center.

Structured form submission is particular tricky to make more modular but i think there might be a way if each component of the form is responsible for producing the data and the data when sent is demarcated by using multi-part/form rather than as one large JSON object.

It is gonna require more investigation but i do wonder if plugin states "I am using GWT rather than Jelly" that Jenkins could somehow automatically weave the generated JavaScript corresponding to configuration/help etc.

A harder area is where a plugin will extend from some existing functionality (IIRC Kohsuke mentioned to me that the test reporting is one such good example of this). For such cases i don't see how technologies like Wicket can be applied and alternative template approaches such as using Groovy are a better fit.

Paul.
Reply all
Reply to author
Forward
0 new messages