What controls what components get configured via http://localhost:8080/configure ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

What controls what components get configured via http://localhost:8080/configure ?

Jason Dillon
I'm trying to understand how the global configuration bits work.  Some components, like Plugins and Descriptors, get included in the configuration display/update bits for http://localhost:8080/configure.  Do other ExtensionPoint impls also get this processing?

How does Hudson determine which objects to be included in the global configuration page?

--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: What controls what components get configured via http://localhost:8080/configure ?

Jesse Glick-2
On 07/24/2010 05:53 PM, Jason Dillon wrote:
> How does Hudson determine which objects to be included in the global configuration page?

You can look through main/core/src/main/resources/hudson/model/Hudson/configure.jelly and see everything that is displayed and in which order. If you're not used to Jelly
scripting it can be a bit cryptic.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: What controls what components get configured via http://localhost:8080/configure ?

Jason Dillon
On Jul 24, 2010, at 5:39 PM, Jesse Glick wrote:
> On 07/24/2010 05:53 PM, Jason Dillon wrote:
>> How does Hudson determine which objects to be included in the global configuration page?
>
> You can look through main/core/src/main/resources/hudson/model/Hudson/configure.jelly and see everything that is displayed and in which order. If you're not used to Jelly scripting it can be a bit cryptic.

Thanks.

Looks like only a small sub-set of extensions are exposed here for global configuration.  I think it would be a good idea to make the set of objects selected for global configuration more dynamic.

I have a case where a plugin contains many build components, some of which need to share some common configuration, but its not global to the entire plugin.  So it doesn't make sense to put the global configuration into one of the descriptors or into the plugin.  I'd like to have the ability to contribute new objects for global configuration, either by installing them when the plugin loads, or by defining a new extension point and somehow configuring hudson to include it.

Any ideas on possible designs to allow something like that?

I think I can probably rig something up that is custom, using the plugin instance to render other configuration objects, though it would be nice if there was a more general and less wonky way to allow a plugin to contribute arbitrary objects for global configuration mgmt.

--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: What controls what components get configured via http://localhost:8080/configure ?

Jason Dillon
I think maybe the easiest and/or best way would be to add this functionality into a library plugin, expose a new extension point for feature plugins to contribute objects, and then implement the semantics via the library plugin's Plugin instance.

Probably no reason that this should be muddled up in to the core... especially when I think that a lot of stuff from the core should find its way into plugins anyways. ;-)

--jason


On Jul 25, 2010, at 1:18 PM, Jason Dillon wrote:

> On Jul 24, 2010, at 5:39 PM, Jesse Glick wrote:
>> On 07/24/2010 05:53 PM, Jason Dillon wrote:
>>> How does Hudson determine which objects to be included in the global configuration page?
>>
>> You can look through main/core/src/main/resources/hudson/model/Hudson/configure.jelly and see everything that is displayed and in which order. If you're not used to Jelly scripting it can be a bit cryptic.
>
> Thanks.
>
> Looks like only a small sub-set of extensions are exposed here for global configuration.  I think it would be a good idea to make the set of objects selected for global configuration more dynamic.
>
> I have a case where a plugin contains many build components, some of which need to share some common configuration, but its not global to the entire plugin.  So it doesn't make sense to put the global configuration into one of the descriptors or into the plugin.  I'd like to have the ability to contribute new objects for global configuration, either by installing them when the plugin loads, or by defining a new extension point and somehow configuring hudson to include it.
>
> Any ideas on possible designs to allow something like that?
>
> I think I can probably rig something up that is custom, using the plugin instance to render other configuration objects, though it would be nice if there was a more general and less wonky way to allow a plugin to contribute arbitrary objects for global configuration mgmt.
>
> --jason


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: What controls what components get configured via http://localhost:8080/configure ?

Andrew Bayer
I'm not sure what the right way to do this would be, but I definitely agree that a better way of getting onto /configure would be nice - could you open a feature request for this, so that it doesn't vanish into the mailing list ether?

A.

On Sun, Jul 25, 2010 at 1:36 PM, Jason Dillon <[hidden email]> wrote:
I think maybe the easiest and/or best way would be to add this functionality into a library plugin, expose a new extension point for feature plugins to contribute objects, and then implement the semantics via the library plugin's Plugin instance.

Probably no reason that this should be muddled up in to the core... especially when I think that a lot of stuff from the core should find its way into plugins anyways. ;-)

--jason


On Jul 25, 2010, at 1:18 PM, Jason Dillon wrote:

> On Jul 24, 2010, at 5:39 PM, Jesse Glick wrote:
>> On 07/24/2010 05:53 PM, Jason Dillon wrote:
>>> How does Hudson determine which objects to be included in the global configuration page?
>>
>> You can look through main/core/src/main/resources/hudson/model/Hudson/configure.jelly and see everything that is displayed and in which order. If you're not used to Jelly scripting it can be a bit cryptic.
>
> Thanks.
>
> Looks like only a small sub-set of extensions are exposed here for global configuration.  I think it would be a good idea to make the set of objects selected for global configuration more dynamic.
>
> I have a case where a plugin contains many build components, some of which need to share some common configuration, but its not global to the entire plugin.  So it doesn't make sense to put the global configuration into one of the descriptors or into the plugin.  I'd like to have the ability to contribute new objects for global configuration, either by installing them when the plugin loads, or by defining a new extension point and somehow configuring hudson to include it.
>
> Any ideas on possible designs to allow something like that?
>
> I think I can probably rig something up that is custom, using the plugin instance to render other configuration objects, though it would be nice if there was a more general and less wonky way to allow a plugin to contribute arbitrary objects for global configuration mgmt.
>
> --jason


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]