date:20140527

The update center accesses confluence to get the {excerpt} stuff for the
plugin descriptions.

The (as KK likes to call it NIH) CloudBees update center that we use also
scrapes Confluence... but we only scrape a plugin when we have a new
version of that plugin. If scraping fails we fall back to the description
in the pom and don't repeat scraping again until there is a new version.

We also do other crazy things like being able to generate the update
center JSON on the fly so we can offer different content for LTS lines vs
the TIP line from the same URL (which is actually a redirect to the
permanent URL that has very high cache control for the specific JSON
content being served)

Madness I know!

OTOH we have more lines of Jenkins that we have to support and consequently
less load per line whereas Jenkins OSS has the mirrors which favours static
content.

The real issue here is that the Jenkins OSS update center does not use a
database-like[1] back-end to store the data so it has to scrape *every*
plugin *every* time it runs.

-Stephen

[1] does not actually need to be a formal database, it could be a cache
file on disk for example... if the cache is missing then hammer confluence
away!

On 27 May 2014 08:08, domi d...@fortysix.ch wrote:

 Why would the update center access JIRA or confluence at all?
 To display the data on confluence the flow is right in the other
 direction, confluence connects to the update center to get the info. And
 JIRA, hmm, I have no idea why JIRA would be used for anything here…
 Domi

 On 27.05.2014, at 08:46, Ivan Kalinin pupss...@gmail.com wrote:

 Ah, that's why our releases aren't showing up.

 But what exact part of the update center generation causes load on
 Jira/Confluence? It looked like the job shouldn't mess a lot with it, just
 request each plugin's page once.

 There are lots of com.atlassian.confluence.rpc.RemoteException: You're
 not allowed to view that page, or it does not exist. messages in the log
 for the pages that are generally publicly accessible.

 On Tuesday, May 27, 2014 2:41:42 AM UTC+4, R Tyler Croy wrote:

 See this ticket for more details https://issues.jenkins-ci.
 org/browse/INFRA-70


 I'm waiting to hear back from KK on how we can fix the update-center
 generation
 scripts from scraping/DoSing our JIRA instance before I re-enable the
 job.



 - R. Tyler Croy

 --
  Code: https://github.com/rtyler
   Chatter: https://twitter.com/agentdero

   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
 --


 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refreshing the Jenkins UI

On Monday, May 26, 2014 3:36:23 PM UTC+1, Bruno Kühnen Meneguello wrote:

I totally agree with you.

I've started a mobile UI and noted how difficult is to change some things,
just because the layout is entirely locked inside tables.

Right... tables are evil for anything more than tabular data... they can
make the initial layout easy but then it's locked. Also styling can be
a pain in the ass.

Although to boil the ocean should be a lot o work, maybe a major
rewrite of Jenkins interface (I liked the REST idea) will bring much more
responsiveness and reduce the bandwidth traffic that Jenkins needs today.

Our initial thoughts were that this would be a bridge too far but now I'm
thinking it might be the only way to do anything meaningful in a somewhat
predictable fashion.

Another great advantage is to adapt to distinct screens and layouts much
better and to add the possibility to override the default stylesheet with
plugins to fine tune.

I personally access Jenkins frequently via smartphone and in my company it
is shown in a big screen and we have some difficult to lay out all jobs (we
don't use extreme feedback plugins). With a more semantic page design,
based in CSS, it could be more easy to adapt.

Right... this type of thing is easy enough with divs and css and media
tags. The simple mockup I did does some of this i.e. the sidepanel drops
off if the screen becomes too narrow.

If you want to make it happens, I want to collaborate.
Em 26/05/2014 10:54, Tom Fennelly tom.fe...@gmail.com javascript:
escreveu:

Hi guys.

I've just started looking into ways in which we can refresh the look
and feel of the Jenkins UI, as well as looking at tackling some of the main
usability issues. I've really only started, but have committed a small bit
of code to a branch on github at
https://github.com/tfennelly/jenkins/tree/ui-refresh. As you might
notice... Daniel Beck has already posted some good comments/feedback on
the
commithttps://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab
.

What I've experimented with so far:

1. Tweaking the main layout in
core/src/main/resources/lib/layout/layout.jelly (and added some CSS to
style.css). Everything was layed out with tables, so I changed that to
use
divs instead, allowing us to more easily do things like make the sidebar
disappear on small screens (if that was a good idea) etc etc. Here's a
screenshot of that:

https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
2. Modified the main project/job configuration page, in an effort to
make it less cluttered, by adding accordions for the different config
sections. The only way I found I could do this was to wire in some
javascript to manipulate the page post-rendering. Kohsuke says there's a
way of doing the bulk of the DOM manipulation within Jelly templates, but
I
failed to work that one out yet - I'm sure it will be obvious after I
see
it :) Not sure if accordions are the correct choice. Here's a
screenshot
of what it looks like:

https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

The above commit obviously breaks things e.g. the breadcrumbs + some of
the styling is screwed up (I added Twitter bootstrap, causing the css's to
clash). What I've done so far is really just hacking to see what we could
do. I'm keen to hear the opinions of the community... what people thing we
should concentrate on... what should we avoid... what are the risks etc
etc. I'm aware there is some prior art in this area e.g. OHTAKE
Tomohiro's work https://github.com/jenkinsci/jenkins/tree/ui-changes,
the Simple Theme
Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Pluginand
others.

General comments/challenges/risks, as I see it:

1. Jelly + Stapler are not the easiest to work with. At least I've
found it quite difficult to figure out where to make changes. Sometimes
it
was obvious other times it was anything but e.g. tweaking the project
config page to get Jelly to create a series of table elements (Vs one
uber table). In the end... I found it easier to do it post-rendering
via
Javascript, which is not good imo.
2. What will be the effect on plugins of changing project config
layout. I already see some strange behaviour e.g. I added an Execute
shell build step... it works fine in the uber table layout, but is
screwed up after I manipulate it - prob easy to fix, but still an
indication that some of the plugins are sensitive to changes in their
surroundings.
3. Use of table for layout seems to be quite popular Vs using div
+ CSS.
4. New more modern icons?

After a few brief conversations with some of my colleagues at CloudBees
(Kohsuke, Jesse Glick, Mic Neale and

Re: Refreshing the Jenkins UI


On Monday, May 26, 2014 7:22:31 PM UTC+1, Daniel Beck wrote:


 On 26.05.2014, at 15:54, Tom Fennelly tom.fe...@gmail.com javascript: 
 wrote: 

  • New more modern icons? 

 IMO the background makes the icons look blander than they are. And we 
 should use an icon style that allows plugin developers to easily find 
 compatible (style + license) icons. Currently we're using Tango (+RRZE) 
 icons. Is there anything comparable? 


Well, by modern, I meant something like the flat icon sets that a lot of 
apps use nowadays.  The current set of icons used in Jenkins are 90s or 
early 00s style imo (as is the default styling in general).

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refreshing the Jenkins UI



On Monday, May 26, 2014 8:08:28 PM UTC+1, Christopher wrote:

 On 05/26/2014 03:54 PM, Tom Fennelly wrote: 
  Hi guys. 
  
  I've just started looking into ways in which we can refresh the look 
  and feel of the Jenkins UI, as well as looking at tackling some of the 
  main usability issues. 

 You often hear people say the Jenkins UI is bad, but it's usually said 
 that there's a lack of concrete examples of *why* it's bad.  So, just 
 out of curiosity, is there a list somewhere of the main usability issues 
 that you've been working on? 


Well this is a perfectly valid question and probably one I'm not best 
qualified to answer.  Personally though... I'd find:

   1. Initial experience is a bit clunky in that you just end up on a blank 
   page/  I think we could at least add some cheat-sheets, introductions (of 
   the looks like this is your first time using this Jenkins instance.  Want 
   a tour) or ask the user straight off if they want to set up their 
   first Job... then have some visually appealing quickstart templates on a 
   pallet of some sort.
   2. The job config page is a badly organised nightmare.
   3. The default template is definitely very dated in appearance 
   (including the icons ;) ).  I know this is not something that would bother 
   everyone, but I do think it possibly send out the wrong signal to potential 
   new community members.  I would fear that many would form the opinion 
   (maybe not intentionally) that things are stale and so would go look 
   elsewhere.



  What I've experimented with so far: 
  
   1. Tweaking the main layout in 
  core/src/main/resources/lib/layout/layout.jelly (and added some CSS 
  to style.css).  Everything was layed out with tables, so I changed 
  that to use divs instead, allowing us to more easily do things like 
  make the sidebar disappear on small screens (if that was a good 
  idea) etc etc.  Here's a screenshot of 
  that: 
 https://www.dropbox.com/s/vngs5jjailatanq/Screenshot%202014-05-26%2012.49.31.png
  
   2. Modified the main project/job configuration page, in an effort to 
  make it less cluttered, by adding accordions for the different 
  config sections.  The only way I found I could do this was to wire 
  in some javascript to manipulate the page post-rendering.  Kohsuke 
  says there's a way of doing the bulk of the DOM manipulation within 
  Jelly templates, but I failed to work that one out yet - I'm sure it 
  will be obvious after I see it :)  Not sure if accordions are the 
  correct choice.  Here's a screenshot of what it looks 
  like: 
 https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png
  

 Nice.  That job config is looking good :) 


It looks okay'sh, but the problem is that the form on that page seems to be 
quite sensitive to a change in the page structure.  The one Build Step I 
added to that page did not work after I modified the page structure.  I 
could probably fix that issue, but I'd bet there are 20 more issues waiting 
around the corner.
 



  After a few brief conversations with some of my colleagues at CloudBees 
  (Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most 
  doable approach for now is to stick with making changes to what's 
  there right now i.e. jelly templates, javascript and CSS.  We also 
  talked (not in detail) about the possibility of working towards more 
  modern technologies and approaches e.g. a Single Page App using the 
  Jenkins REST API Vs the current server-side approach with Stapler and 
  Jelly.  To do that now, however, seems a bit like trying to boil the 
  ocean (quoting one of the guys there).  What do you guys think? 

 I guess it depends what the goal is.  If it's just refreshing the UI, 
 then continuing with the changes so far and perhaps building on some of 
 the nice existing CSS themes out there would be reasonable, e.g. 
 https://github.com/Dakota628/jenkins-clean-theme 


I like that a lot... maybe this is a starting point i.e. at least make 
Jenkins like a bit fresher.  I'm guessing this will not fix issues such as 
with the config page, but it's a good start.
 



 But having seen a colleague of mine use the Jenkins API and AngularJS to 
 build some really nice (though narrowly focussed) Jenkins front-ends for 
 internal apps, dashboards and for customer use, I really like the idea 
 of building the Jenkins UI on top of its API. 

 As you may have seen, this is something Tyler did some work on during 
 FOSDEM last year.  The basic prototype I saw at the time was pretty 
 decent, but as mentioned above and at the time, of course there's a 
 *lot* of backward- and plugin-compatibility to think about: 
 https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y 


Thanks for pointing me at this.  I'll ping Tyler and ask him to pitch in. 
 In some ways I feel that this might be the only real way to make 
meaningful usability changes to Jenkins.

Re: Refreshing the Jenkins UI

On Tuesday, May 27, 2014 7:29:54 AM UTC+1, Dominik Bartholdi wrote:

Glad to see others coming up with this topic again!
We have talked about this on many occasions and some work has been done in
a separate branch too:
https://github.com/jenkinsci/jenkins/tree/ui-changes
In JIRA we also created a special component (ui-changes) to keep track of
all this:
https://issues.jenkins-ci.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+Jenkins+and+component+%3D+ui-changesrunQuery=trueclear=true
…but unfortunate all/most the effort which was put into any attempts of
changing the UI of Jenkins has stopped at some point. I think the biggest
problem really is to find a common agreement on anything - there is always
someone who does not like it.

I think there are quite a few technical barriers to making meaningful
change the UI too. This is inevitable, given the size and success of
Jenkins.

Although I agree, the current implementation does its job and most of the
people get a long with (maybe just because they have not seen anything else
yet) - I absolutely think the look and feel is way off what a user can/does
expect nowadays. In fact I know of a couple of teams which have chosen an
other CI server then Jenkins just because of the UI (e.g. TeamCity) - I
also think Jenkins has by far more capabilities then e.g. TeamCity, but not
everyone needs the more advanced plugins/features/extensionpoints and these
users can happily choose a nicer looking CI server (I would too).

Also the fact that there are so many different approaches on changing the
UI tells me that there is something we should improve.
Some more examples
- https://github.com/rackerlabs/canon-jenkins
- https://github.com/djonsson/jenkins-atlassian-theme -
http://test.do/(making Jenkins look like bamboo)
-
http://isotope11.com/blog/styling-your-jenkins-continuous-integration-server
...

As a reference, there are also the notes we made about the discussions we
had at another FOSDEM:
https://wiki.jenkins-ci.org/display/JENKINS/UI+Enhancements

Great stuff... thanks Domi.

Domi

On 27.05.2014, at 05:10, Michael Neale michae...@gmail.com javascript:
wrote:

On Tuesday, May 27, 2014 5:08:28 AM UTC+10, Christopher wrote:

But having seen a colleague of mine use the Jenkins API and AngularJS to
build some really nice (though narrowly focussed) Jenkins front-ends for
internal apps, dashboards and for customer use, I really like the idea
of building the Jenkins UI on top of its API.

As you may have seen, this is something Tyler did some work on during
FOSDEM last year. The basic prototype I saw at the time was pretty
decent, but as mentioned above and at the time, of course there's a
*lot* of backward- and plugin-compatibility to think about:
https://groups.google.com/forum/#!topic/jenkinsci-dev/dV680PGiI1Y

I have some experience doing fairly advanced UIs on top of the various
APIs - they are quite powerful (other than, notably the config - where it
is more of an xml blob) for doing a lot of things. This does feel a little
boil the ocean, and even if worthwhile, the non js based UI will be
around for a long time yet, so it is probably worth putting a bit if work
in to that to start with.

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-de...@googlegroups.com javascript:.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimenting with building an alternative Jenkins UI

Hi Tyler.

Did you ever commit your experiments to GitHub?  I'd be keen to see what 
you did and would also be keen to hear your thoughts on the API and it's 
suitability.  I started a related thread (wasn't aware of this one until 
now) at https://groups.google.com/forum/#!topic/jenkinsci-dev/zDaX4yiWLLw

Regards,

Tom.



On Monday, February 25, 2013 4:09:53 AM UTC, R Tyler Croy wrote:


 On Sat, 23 Feb 2013, Kohsuke Kawaguchi wrote: 

  Thanks for your thoughts. 
  
  I actually think the abstraction behind how we expose data via JSON is 
  fundamentally sane --- it's basically the same object graph that the 
 server 
  has, 
  
  I think the problem you are seeing is that the default behavior of 
  traverse this graph depth-first to the depth 1 isn't particularly 
 useful. 
  Instead, you should use the tree parameter to select what portions of 
 the 
  object graph you want to retrieve. 
  
  I've been meaning to add the object graph navigator, and I think 
 something 
  like that makes it clearer what the underlying data model is. 


 Kohsuke and I spent a good deal of time talking in-person about this while 
 we 
 were at SCaLE11x this past weekend in LA. 

 We've got a bit of a disagreement on how suitable the current API 
 support is 
 for building a JavaScript application atop Jenkins might be (for the 
 record, I 
 maintain that it is /not/ suitable :-P). 

 Kohsuke brought up a good point about plugins, not regarding extending of 
 the 
 view, but rather how plugins would be plugging data into model objects 
 such as 
 Build or Job for the API. I'm not entirely certain the right direction 
 on 
 this, I'm hoping to find a good middle ground between the current API 
 approach 
 of plugins mixing data directly into models and providing their own API 
 end-points separately which could lead to a plethora of HTTP requests from 
 the 
 UI app. 

 I think the next step for my experimenting, which I'll have some time for 
 next 
 weekend, will be to sketch out what I think would be most suitable for an 
 API 
 after conferring with some of the guys I work with (this is literally what 
 my 
 team does). 


 I'll update this thread once I have something on GitHub worth taking a 
 gander 
 at. 


 Cheers 
 - R. Tyler Croy 
 -- 
 Code: https://github.com/rtyler 
  Chatter: https://twitter.com/agentdero 


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Delete function on instance of a plugin

2014-05-27 Thread rakesh ranjan

Hi ,

In Jenkins do we have any delete function called when a instance of plugin 
(builder) is deleted ?
As like destructor in C++.
Please reply ASAP , its urgent.

Thanks ,
Rakesh 

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delete function on instance of a plugin

No


On 27 May 2014 13:47, rakesh ranjan rakesh.nit@gmail.com wrote:

 Hi ,

 In Jenkins do we have any delete function called when a instance of plugin
 (builder) is deleted ?
 As like destructor in C++.
 Please reply ASAP , its urgent.

 Thanks ,
 Rakesh

  --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delete function on instance of a plugin

2014-05-27 Thread rakesh ranjan

Thanks for your reply ,

Ok so can you please explain how exactly the plugins instances are removed 
and added on jobs configuration changes 
e.g. we added 2 shell script console by selecting from builder list , and 
after saving it , we remove one , so how the 
builderList is maintained 

Thanks 
Rakesh 
On Tuesday, 27 May 2014 18:17:44 UTC+5:30, rakesh ranjan wrote:

 Hi ,

 In Jenkins do we have any delete function called when a instance of plugin 
 (builder) is deleted ?
 As like destructor in C++.
 Please reply ASAP , its urgent.

 Thanks ,
 Rakesh 



-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Delete function on instance of a plugin

When the form is submitted the new list is built replacing the old one.
Simple overwrite. There are some hacks to listen out for these events e.g.
see the Job Config History plugin


On 27 May 2014 14:35, rakesh ranjan rakesh.nit@gmail.com wrote:

 Thanks for your reply ,

 Ok so can you please explain how exactly the plugins instances are removed
 and added on jobs configuration changes
 e.g. we added 2 shell script console by selecting from builder list , and
 after saving it , we remove one , so how the
 builderList is maintained

 Thanks
 Rakesh

 On Tuesday, 27 May 2014 18:17:44 UTC+5:30, rakesh ranjan wrote:

 Hi ,

 In Jenkins do we have any delete function called when a instance of
 plugin (builder) is deleted ?
 As like destructor in C++.
 Please reply ASAP , its urgent.

 Thanks ,
 Rakesh

  --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refreshing the Jenkins UI

2014-05-27 Thread Jeff King


On 05/26/2014 11:10 PM, Michael Neale wrote:

I have some experience doing fairly advanced UIs on top of the various
APIs - they are quite powerful (other than, notably the config - where
it is more of an xml blob) for doing a lot of things. This does feel a
little boil the ocean, and even if worthwhile, the non js based UI
will be around for a long time yet, so it is probably worth putting a
bit if work in to that to start with.


It'd be great if the main dashboard could be configured to pull UI 
elements from the various jobs in the current view. Basically a mash-up 
configurator.


For example, we have a build machine managing CI for three firmware 
projects. Each firmware project has the following Jenkins jobs: 
bootloader build, app build, app static analysis, app unit test, 
integration test, release.


We have a view defined for each project, so it just shows the last job 
status for those jobs associated with the particular project. But we 
have to click through to app unit test to see the test history chart 
and coverage graph, click through to app static analysis to see the 
Coverity graph, etc.


It'd be really powerful for project management if there was a way to 
configure the dashboard view to pull these charts and graphs from the 
jobs pages and put them on the main page. A complete project status at 
a glance as it were.


Of course, if there's already a plugin that does this I'd love to hear 
about it!


--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queue.WaitingItem not usable anymore

On Mon, May 26, 2014 at 5:36 PM, Reto Hirt reto.h...@gmail.com wrote:
 It seems that in the Jenkins Core, the Class
 hudson.model.Queue now denies access to it's inner classes like Item and
 WaitingItem?

No, these are still there and public. Not sure what is going wrong in
your case; use a debugger.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

On Tue, May 27, 2014 at 4:13 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 The update center accesses confluence to get the {excerpt} stuff for the
 plugin descriptions.

And, apparently, to find the list of wiki page tags by which to
classify the plugin. This seems dumb. To continue domi’s post, IMHO
everything needed for generation of an UC ought to be in the
*.hpi/META-INF/MANIFEST.MF. For example, regarding the excerpt, you
could simply pull out the Specification-Title (taken from
pom.xml#/project/description), or load /index.jelly which is what is
rendered in Plugin Manager. Why do you need the excerpt from the wiki?
If anything, the wiki macro should display an excerpt taken from the
plugin.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refreshing the Jenkins UI

On Mon, May 26, 2014 at 5:41 PM, Daniel Beck m...@beckweb.net wrote:
 It's possible to save forms with errors.

Probably fixable without fundamental changes. I swear I had this filed
in JIRA but I cannot find it now.

 Important UI elements are not available in the model-link context menu 
 because they're not in the side panel (notably disable/enable project and 
 mark slave offline/online).

I doubt those are so commonly used that they deserve space in the context menu.

 the global config requires changes (Jenkins URL, mail server, ...) or 
 otherwise things won't work right.

I think these things should be admin warnings.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refreshing the Jenkins UI

2014-05-27 Thread Ioannis Moutsatsos

We have been using Jenkins to build bioinformatic data and image processing
and workflows and the current UI has been a big challenge!
None of the lab scientists using the Jenkins-based workflow tool is
familiar with CI and Dev life cycle so hiding many of the Dev-centric UI
elements and simplifying the interface would be a great improvement.

YES, the first element I would love to hide is the side bar menu, so I can
leave enough space for the job submission form!

I'm following this discussion with great interest! If any of you are coming
to the JUC 2014 Boston meeting in June, I would love to touch base and
discuss this further.

Many thanks for the brave new world of Jenkins UI proposals out there!

best regards
--Ioannis--

On Monday, May 26, 2014 9:54:21 AM UTC-4, Tom Fennelly wrote:

Hi guys.

I've just started looking into ways in which we can refresh the look and
feel of the Jenkins UI, as well as looking at tackling some of the main
usability issues. I've really only started, but have committed a small bit
of code to a branch on github at
https://github.com/tfennelly/jenkins/tree/ui-refresh. As you might
notice... Daniel Beck has already posted some good comments/feedback on
the
commithttps://github.com/tfennelly/jenkins/commit/d586be517616a3ba33ac11c6b5a85965d473c8ab
.

What I've experimented with so far:

https://www.dropbox.com/s/wsy96r1czhzhy5z/Screenshot%202014-05-26%2012.54.39.png

General comments/challenges/risks, as I see it:

After a few brief conversations with some of my colleagues at CloudBees
(Kohsuke, Jesse Glick, Mic Neale and others), it seems like the most
doable approach for now is to stick with making changes to what's there
right now i.e. jelly templates, javascript and CSS. We also talked (not in
detail) about the possibility of working towards more modern technologies
and approaches e.g. a Single Page App using the Jenkins REST API Vs the
current server-side approach with Stapler and Jelly. To do that now,
however, seems a bit like trying to boil the ocean (quoting one of the
guys there). What do you guys think?

So I hope there's an appetite/interest in this and I hope people will let
us know where they would like to see this go (or not, as the case may be).
And of course, if anyone is interested in getting involved in a hands-on
way, then that would be even better :) I think the

Re: Update center generation has been disabled

Well the classification needs to be editable after the fact of the release.
I am with you on the excerpt though


On 27 May 2014 16:16, Jesse Glick jgl...@cloudbees.com wrote:

 On Tue, May 27, 2014 at 4:13 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  The update center accesses confluence to get the {excerpt} stuff for the
  plugin descriptions.

 And, apparently, to find the list of wiki page tags by which to
 classify the plugin. This seems dumb. To continue domi’s post, IMHO
 everything needed for generation of an UC ought to be in the
 *.hpi/META-INF/MANIFEST.MF. For example, regarding the excerpt, you
 could simply pull out the Specification-Title (taken from
 pom.xml#/project/description), or load /index.jelly which is what is
 rendered in Plugin Manager. Why do you need the excerpt from the wiki?
 If anything, the wiki macro should display an excerpt taken from the
 plugin.

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

2014-05-27 Thread R. Tyler Croy

(replies inline)

On Tue, 27 May 2014, Stephen Connolly wrote:

 OTOH we have more lines of Jenkins that we have to support and consequently
 less load per line whereas Jenkins OSS has the mirrors which favours static
 content.
 
 The real issue here is that the Jenkins OSS update center does not use a
 database-like[1] back-end to store the data so it has to scrape *every*
 plugin *every* time it runs.


Is there anybody that wants to volunteer to take this work on sooner rather
than later? I'd like to turn the UC back on without taking JIRA and Confluence
offline which consumes lots of my time (I lost ~2 hours friday figuring this
out).

If there's not enough information in the repository, I'd be happy to help
provide a DB or file dump of the data from confluence that's needed


 [1] does not actually need to be a formal database, it could be a cache
 file on disk for example... if the cache is missing then hammer confluence
 away!

stahp. plz dont hammer


 On 27 May 2014 08:08, domi d...@fortysix.ch wrote:
 
  Why would the update center access JIRA or confluence at all?
  To display the data on confluence the flow is right in the other
  direction, confluence connects to the update center to get the info. And
  JIRA, hmm, I have no idea why JIRA would be used for anything here???
  Domi
 
  On 27.05.2014, at 08:46, Ivan Kalinin pupss...@gmail.com wrote:
 
  Ah, that's why our releases aren't showing up.
 
  But what exact part of the update center generation causes load on
  Jira/Confluence? It looked like the job shouldn't mess a lot with it, just
  request each plugin's page once.
 
  There are lots of com.atlassian.confluence.rpc.RemoteException: You're
  not allowed to view that page, or it does not exist. messages in the log
  for the pages that are generally publicly accessible.
 
  On Tuesday, May 27, 2014 2:41:42 AM UTC+4, R Tyler Croy wrote:
 
  See this ticket for more details https://issues.jenkins-ci.
  org/browse/INFRA-70
 
 
  I'm waiting to hear back from KK on how we can fix the update-center
  generation
  scripts from scraping/DoSing our JIRA instance before I re-enable the
  job.
 
 
 
  - R. Tyler Croy
 
  --
   Code: https://github.com/rtyler
Chatter: https://twitter.com/agentdero
 
% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
  --
 
 
  --
  You received this message because you are subscribed to the Google Groups
  Jenkins Developers group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to jenkinsci-dev+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 
   --
  You received this message because you are subscribed to the Google Groups
  Jenkins Developers group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to jenkinsci-dev+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

- R. Tyler Croy

--
 Code: https://github.com/rtyler
  Chatter: https://twitter.com/agentdero

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--


pgpcR7nM9lJ86.pgp
Description: PGP signature

Re: Update center generation has been disabled

On Tue, May 27, 2014 at 12:13 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 the classification needs to be editable after the fact of the release.

Why? If you want to change it, just cut a new release, like you would
for the plugin display name or anything else.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queue.WaitingItem not usable anymore

2014-05-27 Thread Surya Gaddipati

I am running into the same exact problem. You can easily reproduce this

 1. Create a new jenkins plugin

mvn -U org.jenkins-ci.tools:maven-hpi-plugin:create

 2. Upgrade jenkins version to 1.564 in pom.xml


3. create an eclipse project and import it in eclipse

mvn -DdownloadSources=true -DdownloadJavadocs=true
 -DoutputDirectory=target/eclipse-classes eclipse:eclipse


 4. Now all the static inner classes in jenkins core are not accessible in
 eclipse . Strangely it complies fine on commandline with mvn install 
though.

On Monday, May 26, 2014 4:36:26 PM UTC-5, Reto Hirt wrote:

 Hi there,

 I'm currently working on some enhancements for the build-pipeline plugin 
 and recently had to update Jenkins to 1.563. In order to follow up with the 
 plugin, I updated the dependency to 1.563/4 also but ran into a problem I 
 don't quite understand. It seems that in the Jenkins Core, the Class 
 hudson.model.Queue now denies access to it's inner classes like Item and 
 WaitingItem? Especially the latter was of great use, as it allowed me to 
 show scheduled jobs with estimated starting time and expected wait time in 
 the plugin.

 So, in 1.509.3 I could do this:

...
final ListQueue.Item qitems = 
 Jenkins.getInstance().getQueue().getApproximateItemsQuickly();

and later on
if (qitem instanceof Queue.WaitingItem)

 These two things fail in 1.563 (did not try in between). 

 Does anyone know if and why this is actually the case, and might be able 
 to give me an idea how to access the same information in 1.563 or newer? I 
 had a look around, but don't see it (yet).

 Kind regards
 Reto


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

2014-05-27 Thread FredG



On Tuesday, May 27, 2014 6:50:07 PM UTC+2, Jesse Glick wrote:

 On Tue, May 27, 2014 at 12:13 PM, Stephen Connolly 
 stephen.al...@gmail.com javascript: wrote: 
  the classification needs to be editable after the fact of the release. 

 Why? If you want to change it, just cut a new release, like you would 
 for the plugin display name or anything else. 


While I like the general idea of having a highly dynamic plug-in 
classification system based on tags in the wiki, there is another problem:
The plug-in categories that are shown in the update center are hard-coded 
into the *messages*.properties* files in 
*core\src\main\resources\hudson\model*
(e.g. UpdateCenter.PluginCategory.builder=Build Tools).

When someone adds a new category-tag in the wiki, plug-ins still show up 
under misc in the update center. If the new category-tag gets added to
Jenkins core eventually, only the following Jenkins releases show the new 
category. Everyone else still sees them under misc.

So I'd suggest to pull this out of Jenkins core, either into a plug-in or 
some infra module that generates the update center.

Apart from that I'm in favor of self-contained plug-ins. There might be 
some meta-data (e.g. some kind of plug-in rating) that should be stored 
independently.
At the very least as a fallback (if the plug-in does not provide a 
description, category, then use the one stored in the update center/wiki), 
because
cutting new releases for 800+ plug-ins just to update the meta-data might 
be a bit tedious.


 

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Queue.WaitingItem not usable anymore

2014-05-27 Thread Vincent Latombe

Hi,

this is an eclipse-only issue. You can check out another thread on the ML
talking about this

https://groups.google.com/forum/#!searchin/jenkinsci-dev/Problems$20building$20maven-plugin$20in$20Eclipse/jenkinsci-dev/4rvorfnry1w/pRUPajeESCAJ

Vincent

2014-05-27 21:29 GMT+02:00 Surya Gaddipati suryapraka...@gmail.com:

I am running into the same exact problem. You can easily reproduce this

1. Create a new jenkins plugin

mvn -U org.jenkins-ci.tools:maven-hpi-plugin:create

2. Upgrade jenkins version to 1.564 in pom.xml

3. create an eclipse project and import it in eclipse

mvn -DdownloadSources=true -DdownloadJavadocs=true
-DoutputDirectory=target/eclipse-classes eclipse:eclipse

4. Now all the static inner classes in jenkins core are not accessible in
eclipse . Strangely it complies fine on commandline with mvn install
though.

On Monday, May 26, 2014 4:36:26 PM UTC-5, Reto Hirt wrote:

Hi there,

I'm currently working on some enhancements for the build-pipeline plugin
and recently had to update Jenkins to 1.563. In order to follow up with the
plugin, I updated the dependency to 1.563/4 also but ran into a problem I
don't quite understand. It seems that in the Jenkins Core, the Class
hudson.model.Queue now denies access to it's inner classes like Item and
WaitingItem? Especially the latter was of great use, as it allowed me to
show scheduled jobs with estimated starting time and expected wait time in
the plugin.

So, in 1.509.3 I could do this:

...
final ListQueue.Item qitems = Jenkins.getInstance().getQueue().
getApproximateItemsQuickly();

and later on
if (qitem instanceof Queue.WaitingItem)

These two things fail in 1.563 (did not try in between).

Does anyone know if and why this is actually the case, and might be able
to give me an idea how to access the same information in 1.563 or newer? I
had a look around, but don't see it (yet).

Kind regards
Reto

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an
email to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

Seems crazy rolling a new release of a plugin just to alter metadata about
the plugin. Our update center allows editing the metadata after the release
(yes yes I know the UI doesn't let you have access to the metadata but the
release notes git log import was more important ;-) )

On Tuesday, 27 May 2014, Jesse Glick jgl...@cloudbees.com wrote:

 On Tue, May 27, 2014 at 12:13 PM, Stephen Connolly
 stephen.alan.conno...@gmail.com javascript:; wrote:
  the classification needs to be editable after the fact of the release.

 Why? If you want to change it, just cut a new release, like you would
 for the plugin display name or anything else.

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com javascript:;.
 For more options, visit https://groups.google.com/d/optout.



-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problems building maven-plugin in Eclipse

On Sat, Nov 16, 2013 at 4:46 AM, Christoph Kutzinski ku...@gmx.de wrote:
 Maybe we're missing this bug fix which comes with bridge-method-annotation 1.9

Well Jenkins 1.536+ uses 1.9.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

On Tue, May 27, 2014 at 3:35 PM, FredG fred.g...@googlemail.com wrote:
 When someone adds a new category-tag in the wiki, plug-ins still show up
 under misc in the update center.

According to the code, it should display as “Misc (the-new-category)”.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled



Stephen and Jesse's observations are basically correct. We scrape Wiki 
to fill in a quick description of the plugin, categorizations, and so 
on. UC generator does not touch JIRA as far as I know.



I think there are two issues here, one short-term and the other long-term.


The short-term problem is that we need to get the update center 
generator code running ASAP, without assuming anything more from plugin 
metadata. That primarily involves separating Wiki crawler and UC 
generator, so that the former happens less frequently. I'll do that 
right away.



The long-term problem is if such a scraping of Wiki is necessary to 
begin with, by making plugin metadata more descriptive and self-contained.


I think we do need to define manifest entries for excerpt and labels, 
which isn't even possible today. That said, the motivation for scraping 
the Wiki was to crowd-source the categorizations of plugins, and I 
think that is still valid.


I see 26 classifications in [1] and we want more categories (see 
relevant meta packaging discussion in JENKINS-9598), only allowing 
metadata in the *.jpi files to do this is wrong, IMHO. Plus it's not 
practical at this late in game when we have 800+ plugins that do not 
have such metadata to begin with.




[1] https://wiki.jenkins-ci.org/display/JENKINS/Plugins

On 05/26/2014 03:41 PM, R. Tyler Croy wrote:

See this ticket for more details https://issues.jenkins-ci.org/browse/INFRA-70


I'm waiting to hear back from KK on how we can fix the update-center generation
scripts from scraping/DoSing our JIRA instance before I re-enable the job.



- R. Tyler Croy

--
  Code: https://github.com/rtyler
   Chatter: https://twitter.com/agentdero

   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--




--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

2014-05-27 Thread Surya Gaddipati

 Can we use the description tag in pom.xml of the plugin to generate 
description ? 

On Monday, May 26, 2014 5:41:42 PM UTC-5, R Tyler Croy wrote:

 See this ticket for more details 
 https://issues.jenkins-ci.org/browse/INFRA-70 


 I'm waiting to hear back from KK on how we can fix the update-center 
 generation 
 scripts from scraping/DoSing our JIRA instance before I re-enable the job. 



 - R. Tyler Croy 

 -- 
  Code: https://github.com/rtyler 
   Chatter: https://twitter.com/agentdero 

   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F 
 -- 


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Killing off MavenModuleSet projects

2014-05-27 Thread Andrew Bayer

So builds.apache.org is constantly abused by its excessive number of
MavenModuleSet projects (600+, with an average of nearly 40 modules
per project, for a nice total of 23k+ MavenModules - ow) and I want to
make MavenModuleSet die in a fire. To do this, though, I need to find
a viable way to convert MavenModuleSets into FreeStyleProjects
programmatically, given that, well, 600+ projects created by a few
dozen different Apache teams, etc is not a viable manual conversion.

Has anyone made a run at this before? If I can avoid starting from
scratch, that'd be nice.

A.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

On Tue, May 27, 2014 at 5:11 PM, Kohsuke Kawaguchi
kkawagu...@cloudbees.com wrote:
 I think we do need to define manifest entries for excerpt and labels, which
 isn't even possible today.

As I have mentioned, the excerpt is generally identical or at least
similar to the POM description or /index.jelly, so why not use those
instead? (You need an index.jelly anyway.)

 the motivation for scraping the Wiki was to crowd-source the 
 categorizations of plugins

This does not make much sense to me. The plugin author is well placed
to decide on a category, just as they would decide on a proper display
name and so on. If the “crowd” wants to adjust that, well then we have
pull requests.

 it's not practical at this late
 in game when we have 800+ plugins that do not have such metadata to begin
 with.

I think it is practical. As a one-time batch task we scrape up
existing tags and record those in the UC generation tool as historical
fallback values; and edit the POMs of @jenkinsci plugins to define the
current labels (just like Nicolas did a batch update of repo
definitions a couple years back). Subsequent plugin releases would use
the value defined in the POM.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimenting with building an alternative Jenkins UI

2014-05-27 Thread R. Tyler Croy

(replies inline)

On Tue, 27 May 2014, Tom Fennelly wrote:

 Did you ever commit your experiments to GitHub?  I'd be keen to see what 
 you did and would also be keen to hear your thoughts on the API and it's 
 suitability.  I started a related thread (wasn't aware of this one until 
 now) at https://groups.google.com/forum/#!topic/jenkinsci-dev/zDaX4yiWLLw


This fell off my queue of things I have time to work on so I never got around
to it.

The biggest challenge to the API work IMO is that it's currently not RESTful,
and is quite difficult to make RESTful in a way that a Backbone collection can
easily consume from.

Part of the challenge is that Jenkins' datamodel is much more of a tree than
most front-end toolkits are familiar with, but when you add added functionality
from the plugins, modeling becomes extra tricky.



I'm still of the opinion that a simple Backbone app + basic REST API exposing
jobs, builds, basic details, would be more than enough for a large percentage
of use-cases. Putting my code where my mouth is, isn't something I've had time
for unfortunately.



 On Monday, February 25, 2013 4:09:53 AM UTC, R Tyler Croy wrote:
 
 
  On Sat, 23 Feb 2013, Kohsuke Kawaguchi wrote: 
 
   Thanks for your thoughts. 
   
   I actually think the abstraction behind how we expose data via JSON is 
   fundamentally sane --- it's basically the same object graph that the 
  server 
   has, 
   
   I think the problem you are seeing is that the default behavior of 
   traverse this graph depth-first to the depth 1 isn't particularly 
  useful. 
   Instead, you should use the tree parameter to select what portions of 
  the 
   object graph you want to retrieve. 
   
   I've been meaning to add the object graph navigator, and I think 
  something 
   like that makes it clearer what the underlying data model is. 
 
 
  Kohsuke and I spent a good deal of time talking in-person about this while 
  we 
  were at SCaLE11x this past weekend in LA. 
 
  We've got a bit of a disagreement on how suitable the current API 
  support is 
  for building a JavaScript application atop Jenkins might be (for the 
  record, I 
  maintain that it is /not/ suitable :-P). 
 
  Kohsuke brought up a good point about plugins, not regarding extending of 
  the 
  view, but rather how plugins would be plugging data into model objects 
  such as 
  Build or Job for the API. I'm not entirely certain the right direction 
  on 
  this, I'm hoping to find a good middle ground between the current API 
  approach 
  of plugins mixing data directly into models and providing their own API 
  end-points separately which could lead to a plethora of HTTP requests from 
  the 
  UI app. 
 
  I think the next step for my experimenting, which I'll have some time for 
  next 
  weekend, will be to sketch out what I think would be most suitable for an 
  API 
  after conferring with some of the guys I work with (this is literally what 
  my 
  team does). 
 
 
  I'll update this thread once I have something on GitHub worth taking a 
  gander 
  at. 
 
 
  Cheers 
  - R. Tyler Croy 
  -- 
  Code: https://github.com/rtyler 
   Chatter: https://twitter.com/agentdero 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

- R. Tyler Croy

--
 Code: https://github.com/rtyler
  Chatter: https://twitter.com/agentdero

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--


pgpDziiA3sA37.pgp
Description: PGP signature

Re: Killing off MavenModuleSet projects

On Tue, May 27, 2014 at 5:29 PM, Andrew Bayer andrew.ba...@gmail.com wrote:
 I need to find
 a viable way to convert MavenModuleSets into FreeStyleProjects
 programmatically

Tricky because

1. Some features of MMS are simply not available otherwise, and it may
be hard to determine whether those features are being relied upon in a
particular case. Things like incremental builds of only changed
modules, or triggering by builds of snapshot dependencies.

2. Some features available in a FSP are configured automatically in a
MMS, and finding the current value of that configuration requires
parsing the POM. Things like artifact archival and Surefire reporting.
Fingerprinting is a special case because (until my recent change made
it optional) MMS fingerprints all dependencies, most of which are
irrelevant most of the time, and fingerprinting can be expensive so
you would prefer to do it only when the fingerprints are going to be
used.

Really we would like to have a way of adding MMS-like features and
autoconfiguration à la carte to a FSP, without using the hazardous
Maven embedder that MMS relies on. But this is a major project and no
one has committed to doing it yet.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Killing off MavenModuleSet projects

2014-05-27 Thread Andrew Bayer

That's kind of what I was afraid of - I'd hoped there was a chance
that something had come along since last I dug into this a couple
years ago, but...yeah. I guess I'll try something that detects simple
MMS jobs that can easily be converted and hope that can make a big
enough dent in the total...

A.

On Tue, May 27, 2014 at 2:50 PM, Jesse Glick jgl...@cloudbees.com wrote:
 On Tue, May 27, 2014 at 5:29 PM, Andrew Bayer andrew.ba...@gmail.com wrote:
 I need to find
 a viable way to convert MavenModuleSets into FreeStyleProjects
 programmatically

 Tricky because

 1. Some features of MMS are simply not available otherwise, and it may
 be hard to determine whether those features are being relied upon in a
 particular case. Things like incremental builds of only changed
 modules, or triggering by builds of snapshot dependencies.

 2. Some features available in a FSP are configured automatically in a
 MMS, and finding the current value of that configuration requires
 parsing the POM. Things like artifact archival and Surefire reporting.
 Fingerprinting is a special case because (until my recent change made
 it optional) MMS fingerprints all dependencies, most of which are
 irrelevant most of the time, and fingerprinting can be expensive so
 you would prefer to do it only when the fingerprints are going to be
 used.

 Really we would like to have a way of adding MMS-like features and
 autoconfiguration à la carte to a FSP, without using the hazardous
 Maven embedder that MMS relies on. But this is a major project and no
 one has committed to doing it yet.

 --
 You received this message because you are subscribed to the Google Groups 
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Killing off MavenModuleSet projects

Well as both of you know, but perhaps the rest of the list doesn't

I have a plan to put a better maven integration into the literate job type.
That better integration can probably be used by freestyle jobs too as it
will effectively be just a regular builder, but one that adds an action
that exposes the maven module details. I need to think about whether to add
auto-config of artifact slurping, etc... as I am against some of that...
but there may be a way that I can think of that would let you have a best
of both...

The sad news is my lack of free time... and this is something that lies
behind my rework of the acceptance test harness and that isn't even top of
the pile!


On 27 May 2014 22:50, Jesse Glick jgl...@cloudbees.com wrote:

 On Tue, May 27, 2014 at 5:29 PM, Andrew Bayer andrew.ba...@gmail.com
 wrote:
  I need to find
  a viable way to convert MavenModuleSets into FreeStyleProjects
  programmatically

 Tricky because

 1. Some features of MMS are simply not available otherwise, and it may
 be hard to determine whether those features are being relied upon in a
 particular case. Things like incremental builds of only changed
 modules, or triggering by builds of snapshot dependencies.

 2. Some features available in a FSP are configured automatically in a
 MMS, and finding the current value of that configuration requires
 parsing the POM. Things like artifact archival and Surefire reporting.
 Fingerprinting is a special case because (until my recent change made
 it optional) MMS fingerprints all dependencies, most of which are
 irrelevant most of the time, and fingerprinting can be expensive so
 you would prefer to do it only when the fingerprints are going to be
 used.

 Really we would like to have a way of adding MMS-like features and
 autoconfiguration à la carte to a FSP, without using the hazardous
 Maven embedder that MMS relies on. But this is a major project and no
 one has committed to doing it yet.

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled



I've added caching.

As a bonus, UC gen now runs in 3 min, whereas it used to take 20 mins.

The cache expires after a day.

Those two UC gen processes are scheduled to run 6 times a day, so we've 
gone from 12 full sweep of Wiki per day to 1 full sweep a day.


Hopefully this will keep the usage under check.


On 05/26/2014 03:41 PM, R. Tyler Croy wrote:

See this ticket for more details https://issues.jenkins-ci.org/browse/INFRA-70


I'm waiting to hear back from KK on how we can fix the update-center generation
scripts from scraping/DoSing our JIRA instance before I re-enable the job.



- R. Tyler Croy

--
  Code: https://github.com/rtyler
   Chatter: https://twitter.com/agentdero

   % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--




--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
You received this message because you are subscribed to the Google Groups Jenkins 
Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Killing off MavenModuleSet projects

2014-05-27 Thread Andrew Bayer

Anything I can help out with? 'cos it'd be nifty, to say the least. =)

A.

On Tue, May 27, 2014 at 3:41 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 Well as both of you know, but perhaps the rest of the list doesn't

 I have a plan to put a better maven integration into the literate job type.
 That better integration can probably be used by freestyle jobs too as it
 will effectively be just a regular builder, but one that adds an action that
 exposes the maven module details. I need to think about whether to add
 auto-config of artifact slurping, etc... as I am against some of that... but
 there may be a way that I can think of that would let you have a best of
 both...

 The sad news is my lack of free time... and this is something that lies
 behind my rework of the acceptance test harness and that isn't even top of
 the pile!


 On 27 May 2014 22:50, Jesse Glick jgl...@cloudbees.com wrote:

 On Tue, May 27, 2014 at 5:29 PM, Andrew Bayer andrew.ba...@gmail.com
 wrote:
  I need to find
  a viable way to convert MavenModuleSets into FreeStyleProjects
  programmatically

 Tricky because

 1. Some features of MMS are simply not available otherwise, and it may
 be hard to determine whether those features are being relied upon in a
 particular case. Things like incremental builds of only changed
 modules, or triggering by builds of snapshot dependencies.

 2. Some features available in a FSP are configured automatically in a
 MMS, and finding the current value of that configuration requires
 parsing the POM. Things like artifact archival and Surefire reporting.
 Fingerprinting is a special case because (until my recent change made
 it optional) MMS fingerprints all dependencies, most of which are
 irrelevant most of the time, and fingerprinting can be expensive so
 you would prefer to do it only when the fingerprints are going to be
 used.

 Really we would like to have a way of adding MMS-like features and
 autoconfiguration à la carte to a FSP, without using the hazardous
 Maven embedder that MMS relies on. But this is a major project and no
 one has committed to doing it yet.

 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


 --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

2014-05-27 Thread FredG



On Tuesday, May 27, 2014 10:06:25 PM UTC+2, Jesse Glick wrote:

 On Tue, May 27, 2014 at 3:35 PM, FredG fred...@googlemail.comjavascript: 
 wrote: 
  When someone adds a new category-tag in the wiki, plug-ins still show up 
  under misc in the update center. 

 According to the code, it should display as “Misc (the-new-category)”. 


You are right, it actually does show up... 25 times Misc (some category) 
plus a real Miscellaneous category.
Sorry, but this is still a crutch! m(

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Update center generation has been disabled

On Tue, May 27, 2014 at 6:56 PM, Kohsuke Kawaguchi
kkawagu...@cloudbees.com wrote:
 the categorization comes after the plugin comes into being.

Really? Whenever I have created a plugin I have set a category in the
wiki as just one of several routine tasks.

 I'm all for allowing pluin authors to definitely describe excerpt, labels,
 and so on. But I also don't really see why we have to bend over backward to
 avoid hitting Confluence.

For me that is a side benefit, but the real motivation is that I
expect the official, signed update center JSON to be a simple function
of the plugin artifacts that are fed into it from the Maven
repository, without mysterious screen scraping of some wiki. If
JENKINS-22926 is implemented and some extended columns in Plugin
Manager want to show installation counts, ratings, etc. pulled from
other databases or sites or astrological almanacks, that is fine.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DotCi - plugin hosting request

My apologies for the delay, but it's all set at
https://github.com/jenkinsci/DotCi

Surya, my mind is blown. My hats off to you. This plugin packs some serious
punch in it.

I have several requests.

First, would you be interested in doing a guest post on
http://jenkins-ci.org/node blog? I think more people should know about
this, and I think it gives you and Groupon the visibility that you deserve.

Second, I skimmed through the plugin, and it contains several interesting
parts that I think are useful outside your plugin (such as
DbBackedProject.) I see some other parts where I think you worked around
the current core limitation (such as a separate new job UI). And I have
some ideas that I'd like to run by you to improve the interoperability with
existing plugins.

I'd like to try putting out some of them into separate reusable plugins,
identify things we should change in the core to better accomodate this
plugin, and so on.

To that end, I wonder if you would walk us through the inner working of
this plugin in one of the upcoming office
hourshttps://wiki.jenkins-ci.org/display/JENKINS/Office+Hours?
The next one is June 4th 11am PT, but we can have it in an irregular time
if that time slot doesn't work for you.





2014-05-20 9:36 GMT-07:00 Surya Gaddipati suryapraka...@gmail.com:

 https://github.com/groupon/DotCi
 github usename: suryagaddipati

  --
 You received this message because you are subscribed to the Google Groups
 Jenkins Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to jenkinsci-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
Kohsuke Kawaguchi

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Experimenting with building an alternative Jenkins UI