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/
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:
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.
Makes sense to me. Let's do JIRA.
>
> Whichever we choose, I think either are probably better in the long
> term than email.
>
> -Jesse
>
--
> 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
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
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.
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.
JENKINS (My mum will punish me. I'll write it 1000 times this WE)
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
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
> - 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/
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
> - 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
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?
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
- 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?)
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.
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 ... ;-)
>
> [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/
>
For example, modular email notification support has been around forever.
Indeed it's time to act on those.
...., and GWT in my eyes is more for having intensely interactive UI widgets (like update center table) --- those are things that get weaved together.
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
>
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 02/10/2011 02:41 PM, Arnaud Héritier wrote:I think it's a non-event already, no?
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.
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.)
- 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 .....
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())
[..]
> 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.
...., 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