Re: Plugin Development: expansion of Lockable Resources Plugin?

[Kevin Werner]

Thanks Jesse, that should get me started.  I appreciate the pointers.  :)

kddubb

On Friday, May 18, 2018 at 3:39:39 PM UTC-6, Jesse Glick wrote:
>
> On Fri, May 18, 2018 at 5:11 PM, Kevin Werner  > wrote: 
> > it seems like #1 
> > on my list should be implemented by adding a .../api to the 
> > /lockable-resources/ URL? 
>
> Perhaps for “querying current reservations”, but Stapler export API 
> (`hudson.model.Api`, what you linked to) is read-only. For general 
> operations you need to implement Stapler web methods in various 
> patterns. 
>
> > Any suggestions on good plugin examples to use? 
>
> Some plugins implement RESTish APIs, some implement CLI commands, some 
> implement both, and the quality is quite variable I am afraid. Jenkins 
> core implements plenty of RESTish APIs; sometimes they are documented 
> in `_api.jelly` files, but usually they are not. You can find APIs 
> very roughly by searching for usages of `StaplerRequest`, 
> `StaplerResponse`, `HttpResponse`, and a few other things. 
>
> http://stapler.kohsuke.org/reference.html 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/fc2d26a6-977b-47f6-ab04-cf1f78d116ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Development: expansion of Lockable Resources Plugin?

[Jesse Glick]

On Fri, May 18, 2018 at 5:11 PM, Kevin Werner  wrote:
> it seems like #1
> on my list should be implemented by adding a .../api to the
> /lockable-resources/ URL?

Perhaps for “querying current reservations”, but Stapler export API
(`hudson.model.Api`, what you linked to) is read-only. For general
operations you need to implement Stapler web methods in various
patterns.

> Any suggestions on good plugin examples to use?

Some plugins implement RESTish APIs, some implement CLI commands, some
implement both, and the quality is quite variable I am afraid. Jenkins
core implements plenty of RESTish APIs; sometimes they are documented
in `_api.jelly` files, but usually they are not. You can find APIs
very roughly by searching for usages of `StaplerRequest`,
`StaplerResponse`, `HttpResponse`, and a few other things.

http://stapler.kohsuke.org/reference.html

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1MpjX4LoAySTYaOEt6q0F7KbQ0n1cgVA%2BFCE8EVa6ErA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[Jesse Glick]

On Fri, May 18, 2018 at 3:19 PM, nicolas de loof
 wrote:
> I'm not using custom-war-packager, but --commonLibFolder jenkins.war
> launcher option.

Never heard of it, and likely does not work for this purpose. You need
an entry in `jenkins.war!/WEB-INF/lib/*.jar` as I said.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3rMm-CTXH-TpKTyysL0WnOKKAQ41gbHHQOYCJeaVTmxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Development: expansion of Lockable Resources Plugin?

[Kevin Werner]

btw, I haven't had to use the Remote Access API much, but it seems like #1 
on my list should be implemented by adding a .../api to the 
/lockable-resources/ URL?

https://wiki.jenkins.io/display/JENKINS/Remote+access+API

Any suggestions on good plugin examples to use?  I'm sure I can figure it 
out for myself, but since I'm newer to this I'm sure having a pointer in 
the right direction from those that know would be helpful!

Thanks in advance,

kddubb

On Friday, May 18, 2018 at 10:22:21 AM UTC-6, Kevin Werner wrote:
>
> Hi,
>
> The current Lockable Resources Plugin has reservation for external 
> resources and the ability to lock (and wait for availability to lock) them 
> during a build pipeline.  This is very helpful functionality that I'm 
> already using minimally in our test pipelines.  For the plugin to really be 
> useful for me though, I need some additional functionality:
>
> 1.  The ability to reserve, unreserve and query the current reservations 
> and available resources through a REST API rather than the GUI; I have a 
> couple external tools that I would like to integrate with.  I need to 
> especially be able to query the resources that are currently reserved to a 
> jenkins user.  The main utility is that we have CI, manual and automated 
> (outside CI) test runs and I want to integrate the reservation system for 
> all, if possible.  For instance, before a manual run starts, I want to make 
> sure that the resources are actually reserved by the developer.  
> 2.  I would like to possibly add some additional data to the lockable 
> resources as well.  This is a longer-term goal as I could abuse the 
> description field in the short-term and use it for my own purposes.  I'm 
> hoping to be able to add JSON metadata about the resource that is useful 
> for the external tools to know (ex. PDU information so I can power it 
> on/off during a pipeline).  
> 3.  I would also like to add an optional reservation "tag" when reserving 
> that can help create sub-groups of reservations (ex.  Joe reserves two 
> separate resources, but he wants to use each for two different test runs 
> that are running simultaneously so the external test tool needs to query 
> not only what he has reserved but choose the correct resource for each test 
> run)
>
> Is there any functionality like this that exists already that I don't know 
> about?  I hate reinventing the wheel.
>
> If not, I'm not currently a Jenkins plugin dev, but I have a Java/Groovy 
> background and I'm happy to jump in and start contributing.  I'm assuming I 
> can modify and add to the current Lockable Resources Plugin?  I'm happy to 
> coordinate with other devs with this work.
>
> For now, I'm going to start poking around getting a dev environment setup 
> for myself and start playing around with making my own plugin.
>
> Any feedback or help is welcome.  Thanks in advance!
>
> kddubb
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/8a2deb7c-cb4b-45cf-909a-6153a8a611b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[nicolas de loof]

didn't help unfortunately. Still get NoClassDefFoundError:
hudson/model/listeners/RunListener

note : I'm not using custom-war-packager, but --commonLibFolder jenkins.war
launcher option. Not sure this is commonly used ...

2018-05-18 18:53 GMT+02:00 nicolas de loof :

> Thanks for the tip
>
> Le ven. 18 mai 2018 à 18:50, Jesse Glick  a écrit :
>
>> On Fri, May 18, 2018 at 9:03 AM, nicolas de loof
>>  wrote:
>> > I'm writing an extension to jenkins that can't be packaged as a plugin
>> (need
>> > to be ran before plugins get loaded)
>>
>> I think what you are looking for is to use a standard plugin layout
>> but replacing
>>
>> hpi
>>
>> with
>>
>> jenkins-module
>>
>> and then add it to the list here:
>>
>> https://github.com/jenkinsci/jenkins/blob/ac749d669d6ba8bd77c0827c8705c9
>> 454f973a6a/war/pom.xml#L95-L134
>>
>> or use `custom-war-packager` to retrofit it into an existing
>> `jenkins.war` artifact.
>>
>> (Most of these actually could be converted to regular plugins, I
>> think; it is only those things which genuinely need to run code before
>> the Jenkins plugin manager is initialized which must be modules, such
>> as `ConfidentialStore` implementations.)
>>
>> --
>> 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.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jenkinsci-dev/CANfRfr2w9%2BJmfXJh-X63u3smvQstvV6JgGM2T4ML76K%
>> 3DXoBZ3Q%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzncsaHrzxar7iP2d2As_0Wgf9nNe8P53vMsUoUQmoD%3D1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Development: expansion of Lockable Resources Plugin?

[Steven F]

There's definitely an open PR for the 2nd feature which I am patiently 
waiting for

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/cf6f4ad8-b806-4412-88f6-721a0b5e8c8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin Development: expansion of Lockable Resources Plugin?

[Kevin Werner]

Awesome I'll take a look through those.

On Friday, May 18, 2018 at 10:55:37 AM UTC-6, Jesse Glick wrote:
>
> On Fri, May 18, 2018 at 12:15 PM, Kevin Werner  > wrote: 
> > Is there any functionality like this that exists already that I don't 
> know 
> > about? 
>
> Look through 
>
> https://github.com/jenkinsci/lockable-resources-plugin/pulls 
>
> Probably best to discuss any major plans with @abayer & @amuniz, who 
> seem to have been active recently merging PRs. As a rule, PRs are most 
> likely to get traction if they are reasonably small (reviewers have 
> very limited time to grasp what you are doing), solving a single 
> specific problem, with thorough test coverage, and no compatibility 
> impact. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b6008180-e6e9-48b6-a61b-117f8880cf92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: service library in Jenkins

[nicolas de loof]

Thanks for the tip

Le ven. 18 mai 2018 à 18:50, Jesse Glick  a écrit :

> On Fri, May 18, 2018 at 9:03 AM, nicolas de loof
>  wrote:
> > I'm writing an extension to jenkins that can't be packaged as a plugin
> (need
> > to be ran before plugins get loaded)
>
> I think what you are looking for is to use a standard plugin layout
> but replacing
>
> hpi
>
> with
>
> jenkins-module
>
> and then add it to the list here:
>
>
> https://github.com/jenkinsci/jenkins/blob/ac749d669d6ba8bd77c0827c8705c9454f973a6a/war/pom.xml#L95-L134
>
> or use `custom-war-packager` to retrofit it into an existing
> `jenkins.war` artifact.
>
> (Most of these actually could be converted to regular plugins, I
> think; it is only those things which genuinely need to run code before
> the Jenkins plugin manager is initialized which must be modules, such
> as `ConfidentialStore` implementations.)
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2w9%2BJmfXJh-X63u3smvQstvV6JgGM2T4ML76K%3DXoBZ3Q%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkPGbqctsifZmoTXixvV3mFRUw2ip7CWQTELR%2B_uuQJtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[nicolas de loof]

To be honest, I can't see any benefit in short terms to introduce this just
because at some time we might wish to change casc-plugin handling of _some_
metadata that would introduce a breaking change.
At the time such a thing actually happens, we could easily introduce a top
level "version: 2" pseudo-property so unlock such a breaking change (just
like docker-compose did by the way). Or we can just have a 2.x branch for
configuration-as-code plugin and keep 1.x for security fixes only. So that
if you want your yaml config to rely on this, you just need to install 2.x
plugin.




2018-05-18 18:09 GMT+02:00 Jeff Thompson :

> I agree on the value of having a version identifier. At some level, there
> is a structure that may change, as anything tends to do over time.
> Stephen’s description of a meta-schema version shows the existence of one
> such structure.
>
> In my experience there have been times where I created a version
> identifier for something and didn’t end up using it. But I can’t think of
> an instance where keeping that at version 1 was ever a burden. There have
> been other times where I didn’t add a version identifier and later wished I
> had. And other times where I created one that I didn’t know I needed and
> was later glad I had.
>
> Jeff
>
>
>
> On May 17, 2018, at 5:44 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> But I still think you should include the (let’s invent a different name to
> show the purpose) meta-schema version
>
> Most likely the meta-schema version will always be 1, but if you ever need
> to revise then you will thank Jesse and I for suggesting it.
>
> CaaC has a schema for generating the schema at runtime... this is the
> meta-schema... it says things like: Java Maps are represented by , use
> the @Symbol as a , etc
>
> That is what the meta-schema version represents. If it changes then you
> are saying the way of binding between yaml and runtime (in the general
> sense) has changed.
>
> On Tue 15 May 2018 at 19:30, nicolas de loof 
> wrote:
>
>> I've added a section on this topic in JEP-201: https://github.com/
>> jenkinsci/jep/tree/master/jep/201#versioning
>>
>> We can already generate a json-schema you can use to validate your yaml
>> file(s) before applying configuration.
>> What you miss is a tool to convert jenkins-core + plugins.spec -> json
>> schema.
>> This is something we could package as well (something comparable to
>> jenkinsfile-runner) or even provide "as a service".
>>
>> We could also get such a tool both generate a schema and validate your
>> config, as it seems there's not  (yet) so much text editors to support
>> json schema validation in yaml
>>
>> Would this help ?
>>
>> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy :
>>
>>> (replies inline)
>>>
>>> On Tue, 15 May 2018, nicolas de loof wrote:
>>>
>>> > 2018-05-15 0:20 GMT+02:00 Liam Newman :
>>> >
>>> > >
>>> > > Putting all that aside (as that is not the original point of this
>>> thread),
>>> > > the original suggestion was to include a version field in the CasC
>>> YAML.
>>> > > You said it would not work because the version would have to take
>>> into
>>> > > account the core version and versions of all plugins, otherwise it
>>> might
>>> > > break. Does that mean the CasC YAML could break _any time_  I
>>> upgrade any
>>> > > component? Doesn't that rather defeats the purpose of CasC?
>>> > >
>>> >
>>> > Yes indeed. CasC doesn't have it's own model, everything is based on
>>> actual
>>> > java code discovery at runtime. So upgrading core or any plugin is
>>> changing
>>> > this model. CasC targets reproducibility and immutability use-cases.
>>> If you
>>> > want to upgrade anything you need to test it before.
>>>
>>>
>>> Testing of changes between plugin versions was something I had great
>>> difficulty
>>> with for Groovy-scripting-based configuration, which was much more
>>> common prior
>>> to Configuration as Code. Do you have suggestions for administrators
>>> such as
>>> myself on how I might validate that my configuration YAML is
>>> correct/applies
>>> between any core or plugin upgrades?
>>>
>>> This gets to the underlying concern I had in mind when starting this
>>> thread, as
>>> an administrator, how will I know that my configuration applies correctly
>>> between any core or plugin upgrades? My initial thought was
>>> schema-versioning,
>>> but I'm certainly open to other suggestions.
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/jenkinsci-dev/20180515181926.GB3395%40grape.lasagna.io.
>>> For more options, visit 

Plugin Development: expansion of Lockable Resources Plugin?

[Kevin Werner]

Hi,

The current Lockable Resources Plugin has reservation for external 
resources and the ability to lock (and wait for availability to lock) them 
during a build pipeline.  This is very helpful functionality that I'm 
already using minimally in our test pipelines.  For the plugin to really be 
useful for me though, I need some additional functionality:

1.  The ability to reserve, unreserve and query the current reservations 
and available resources through a REST API rather than the GUI; I have a 
couple external tools that I would like to integrate with.  I need to 
especially be able to query the resources that are currently reserved to a 
jenkins user.  The main utility is that we have CI, manual and automated 
(outside CI) test runs and I want to integrate the reservation system for 
all, if possible.  For instance, before a manual run starts, I want to make 
sure that the resources are actually reserved by the developer.  
2.  I would like to possibly add some additional data to the lockable 
resources as well.  This is a longer-term goal as I could abuse the 
description field in the short-term and use it for my own purposes.  I'm 
hoping to be able to add JSON metadata about the resource that is useful 
for the external tools to know (ex. PDU information so I can power it 
on/off during a pipeline).  
3.  I would also like to add an optional reservation "tag" when reserving 
that can help create sub-groups of reservations (ex.  Joe reserves two 
separate resources, but he wants to use each for two different test runs 
that are running simultaneously so the external test tool needs to query 
not only what he has reserved but choose the correct resource for each test 
run)

Is there any functionality like this that exists already that I don't know 
about?  I hate reinventing the wheel.

If not, I'm not currently a Jenkins plugin dev, but I have a Java/Groovy 
background and I'm happy to jump in and start contributing.  I'm assuming I 
can modify and add to the current Lockable Resources Plugin?  I'm happy to 
coordinate with other devs with this work.

For now, I'm going to start poking around getting a dev environment setup 
for myself and start playing around with making my own plugin.

Any feedback or help is welcome.  Thanks in advance!

kddubb

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/f9772acf-5e27-4e56-94bb-bf3f94304e1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion: versioning the schema for Configuration as Code

[Jeff Thompson]

I agree on the value of having a version identifier. At some level, there is a 
structure that may change, as anything tends to do over time. Stephen’s 
description of a meta-schema version shows the existence of one such structure.

In my experience there have been times where I created a version identifier for 
something and didn’t end up using it. But I can’t think of an instance where 
keeping that at version 1 was ever a burden. There have been other times where 
I didn’t add a version identifier and later wished I had. And other times where 
I created one that I didn’t know I needed and was later glad I had.

Jeff


> On May 17, 2018, at 5:44 PM, Stephen Connolly 
>  wrote:
> 
> But I still think you should include the (let’s invent a different name to 
> show the purpose) meta-schema version
> 
> Most likely the meta-schema version will always be 1, but if you ever need to 
> revise then you will thank Jesse and I for suggesting it.
> 
> CaaC has a schema for generating the schema at runtime... this is the 
> meta-schema... it says things like: Java Maps are represented by , use 
> the @Symbol as a , etc
> 
> That is what the meta-schema version represents. If it changes then you are 
> saying the way of binding between yaml and runtime (in the general sense) has 
> changed.
> 
> On Tue 15 May 2018 at 19:30, nicolas de loof  > wrote:
> I've added a section on this topic in JEP-201: 
> https://github.com/jenkinsci/jep/tree/master/jep/201#versioning 
> 
> 
> We can already generate a json-schema you can use to validate your yaml 
> file(s) before applying configuration.
> What you miss is a tool to convert jenkins-core + plugins.spec -> json 
> schema. 
> This is something we could package as well (something comparable to 
> jenkinsfile-runner) or even provide "as a service".
> 
> We could also get such a tool both generate a schema and validate your 
> config, as it seems there's not  (yet) so much text editors to support json 
> schema validation in yaml
> 
> Would this help ?
> 
> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy  >:
> (replies inline)
> 
> On Tue, 15 May 2018, nicolas de loof wrote:
> 
> > 2018-05-15 0:20 GMT+02:00 Liam Newman  > >:
> > 
> > >
> > > Putting all that aside (as that is not the original point of this thread),
> > > the original suggestion was to include a version field in the CasC YAML.
> > > You said it would not work because the version would have to take into
> > > account the core version and versions of all plugins, otherwise it might
> > > break. Does that mean the CasC YAML could break _any time_  I upgrade any
> > > component? Doesn't that rather defeats the purpose of CasC?
> > >
> > 
> > Yes indeed. CasC doesn't have it's own model, everything is based on actual
> > java code discovery at runtime. So upgrading core or any plugin is changing
> > this model. CasC targets reproducibility and immutability use-cases. If you
> > want to upgrade anything you need to test it before.
> 
> 
> Testing of changes between plugin versions was something I had great 
> difficulty
> with for Groovy-scripting-based configuration, which was much more common 
> prior
> to Configuration as Code. Do you have suggestions for administrators such as
> myself on how I might validate that my configuration YAML is correct/applies
> between any core or plugin upgrades?
> 
> This gets to the underlying concern I had in mind when starting this thread, 
> as
> an administrator, how will I know that my configuration applies correctly
> between any core or plugin upgrades? My initial thought was schema-versioning,
> but I'm certainly open to other suggestions.
> 
> 
> 
> Cheers
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/20180515181926.GB3395%40grape.lasagna.io
>  
> .
> 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 
> .
> To view this discussion on the web visit 
> 

service library in Jenkins

[nicolas de loof]

Hi there,

I'm writing an extension to jenkins that can't be packaged as a plugin
(need to be ran before plugins get loaded) so I created an InitLoader as a
Service


@MetaInfServices
public class InitListener implements InitReactorListener {

@Override
public void onTaskStarted(Task task) {
System.out.println("started :" + task.toString());
}
...
}

When Jenkins starts I get this error =

GRAVE: Failed to initialize Jenkins
hudson.util.HudsonFailedToLoad: java.lang.NoClassDefFoundError:
hudson/init/InitReactorListener
at hudson.WebAppMain$3.run(WebAppMain.java:247)
Caused by: java.lang.NoClassDefFoundError: hudson/init/InitReactorListener
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:560)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at com.google.common.collect.Lists.newArrayList(Lists.java:139)
at com.google.common.collect.Lists.newArrayList(Lists.java:119)
at jenkins.InitReactorRunner.buildReactorListener(InitReactorRunner.java:63)
at jenkins.InitReactorRunner.run(InitReactorRunner.java:48)
at jenkins.model.Jenkins.executeReactor(Jenkins.java:1096)
at jenkins.model.Jenkins.(Jenkins.java:900)
at hudson.model.Hudson.(Hudson.java:85)
at hudson.model.Hudson.(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:233)


For a reason I can't get, this service when loaded can't access jenkins.war
core classes.

I'm running from plain jenkins.war

java -jar jenkins-2.107.3.war --commonLibFolder=./lib/


Any thoughts ?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3D3aDA2053-cu5oZYU3S%3DXwgXWQkPL2WEqMweuQgDO7Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Plugin development : extension to add custom options in declarative pipeline

[Robert Sandell]

I think

 options {
 // Declare the Foo
 withFoo(fooParams)
 }

Should work as is. Have you tried it?

/B

2018-05-17 18:44 GMT+02:00 Bill Dennis :

> I am developing a Jenkins pipeline plugin that provides some custom block
> scoped steps something like this:
>
> withFoo( fooParams ) {
>// Some code block that uses the declared "Foo" thing
> }
>
>
> My *withFoo* step creates some object "Foo" that is made available in the
> code block to my other custom steps.
>
> I have all this sort of thing working with custom block-scoped steps and
> simple steps and it is going well in my declarative pipelines and providing
> the functionality I need.
>
> However the "foo" is only available in a pipeline code block in a single
> declarative stage and it won't be available in a post handler unless I
> re-declare it ( think).
>
> I am envisioning some scenarios where I want my "Foo" object to be
> available to the whole job in the pipeline context using something like
> "options" (or possibly at the stage options level).
>
> So I am looking at the possibility of some custom option like this:
>
> pipeline {
>
>  agent none
>
>  options {
>  // Declare the Foo
>  foo(fooParams)
>  }
>
>
>  // Rest of pipeline uses the Foo in stages or post sections
> }
>
>
> To give some context, the "Foo" is some sort of connection to a remote system 
> so it could be expensive to keep tearing it down and re-establishing it.
>
>
> Is there a way to provide custom options like this to have an object is 
> created and put in the pipeline context for the whole pipeline and can be 
> consumed by my other custom steps?
>
>
> I had a look at the existing Jenkins extension point documents and around 
> some plugins in GitHub but I cannot tell whether these options are generally 
> extendable in this way.
>
>
> Thanks for any suggestions or pointers anyone here may have!
>
>
> --Bill
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/92d6270f-7da0-4aea-b7ba-5f41eb1be190%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Robert Sandell*
Software Engineer
CloudBees, Inc.
[image: CloudBees-Logo.png] 
E: rsand...@cloudbees.com
Twitter: robert_sandell

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS1%3DRT1DujCDuu6H1PtbCpaCEPY%2BeaXL7%3DbeKeVaPybaiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Stapler example not enable to bring it up.

[Penugonda chenna reddy]

 

I have downloaded the source code for the stapler-core example from github (
*https://github.com/stapler/stapler* )

And able to build the stapler-example.war file without any compilation 
issues.

When I deploy stapler-example.war in C:\tomcat\apache-tomcat-8.5.31\webapps 
its extracting.

But when I try from the browser like the below

 

 

 

Its giving the above error. Any help is highly appreciated.

 

Regards

PCReddy

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/1bcd792b-69d9-4e7c-82c3-cebb0f3e963b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2018] Jenkins Remoting over Message Bus/Queue Introduction

[Carlos Sanchez]

Very cool, looking forward to it !

On Fri, May 18, 2018 at 7:51 AM Pham Vu Tuan  wrote:

> Hi all,
>
> My name is Vu Tuan, and I am participating in Jenkins Google Summer of
> Code this year as a student. My project is Jenkins Remoting over Message
> Bus/Queue
> .
> Some background about this project:
>
>- Current versions of Jenkins Remoting are based on the TCP protocol.
>If it fails, the agent connection and the build fails as well. There are
>also issues with traffic prioritization and multi-agent communications,
>which impact Jenkins stability and scalability.
>- This project aims an update of Remoting and Jenkins in order to add
>support of a popular message queue/bus technology (RabbitMQ or Kafka) as a
>fault-tolerant communication layer in Jenkins.
>
>
> Currently we are in the first phase of the project and I am going to
> implement a PoC in this first phase. The messaging technology used is
> Apache Kafka, and the deliverable for the first phase will be in Docker
> compose with multiple services and components involved.
> If you are interested, we have a gitter
>  chat for this project. The weekly
> meeting schedule is:
>
>-
>
>Every Tuesday, 02:00-03:00 PM UTC
>-
>
>Every Friday, 02:00-03:00 PM UTC
>
> I am looking forward to contributing to Jenkins community this summer.
>
> Best regards,
> Pham Vu Tuan
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/22237593-3392-4a88-9267-634c8827b50b%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6Ng%2BQRdAuZBb3BssT8qLNU5TBFaCnQOJgk9B%3DxmQ4zp5Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.