where to put cross-plugin include files?

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

where to put cross-plugin include files?

Timothy Bingaman
Hi all,

Quick question about where to put files that are used by one plugin, but rendered by other plugins.

I've been working on a new Section type for my Section View Plugin that displays mini versions of the trend graphs produced by floatingBox.jelly files.

see the wiki for a pic:
http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress(unreleased)

Because the paths, graph sizes, and positioning are different in this case I can't use the floatingBox.jelly files.
I've coded it to pull modified copies of these called sectionFloatingBox.jelly.

The question is, should I talk to each report plugin maintainer to see if I can add a sectionFloatingBox.jelly file to their plugin (this would include adding one to Hudson Core for the TestResultProjectAction)?  Or should I just bundle them all in my plugin (using the package name of the plugin which they are for so jelly finds them correctly from the action classes)?

thanks a lot for the help,
Timo
--
Timothy Bingaman
Software Engineer, Open Cloud Limited
Level 4, 54-56 Cambridge Tce, Wellington, New Zealand
http://www.opencloud.com
t:  +64 4 977 4782
m:  +64 21 027 33614
linkedIn:  http://www.linkedin.com/in/timobingaman
Reply | Threaded
Open this post in threaded view
|

Re: where to put cross-plugin include files?

Kohsuke Kawaguchi
Administrator

If the size of the box is the main issue, maybe we should refine an
abstraction so that the size information gets passed to the jelly view,
instead of defining another jelly view with a fixed size? Or maybe
that's what you did with the sectionFloatingBox.jelly?

I believe the Jelly views would need to be in the respective plugins,
partly because of classloader issues and how Stapler finds them, partly
because of compatibility issues when those plugins evolve later and
break things that you rely on.


Timothy Bingaman wrote:

> Hi all,
>
> Quick question about where to put files that are used by one plugin, but
> rendered by other plugins.
>
> I've been working on a new Section type for my Section View Plugin that
> displays mini versions of the trend graphs produced by floatingBox.jelly
> files.
>
> see the wiki for a pic:
> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress%28unreleased%29>
>
> Because the paths, graph sizes, and positioning are different in this case I
> can't use the floatingBox.jelly files.
> I've coded it to pull modified copies of these called
> sectionFloatingBox.jelly.
>
> The question is, should I talk to each report plugin maintainer to see if I
> can add a sectionFloatingBox.jelly file to their plugin (this would include
> adding one to Hudson Core for the TestResultProjectAction)?  Or should I
> just bundle them all in my plugin (using the package name of the plugin
> which they are for so jelly finds them correctly from the action classes)?
>
> thanks a lot for the help,
> Timo

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: where to put cross-plugin include files?

Timothy Bingaman
Hey Kohsuke,

thanks for the response.
and yes, I just tried putting them in my own plugin and realised that the classloader wouldn't pick them up from there.

There are a few problems with using the floatingBox.jelly files as they are.

1) size
* arguments passed in would be great for this - applied to the image and the imageMap (if a map is used)

2) the relative urls
* currently, they are either hardcoded (like "test" for the test result one or they use ${from.urlName})
* since I'm displaying them one level up I need ${job.shortUrl}${from.urlName}
* this could be resolved by a relative link argument

making those changes would allow the graphs to be embedded pretty much anywhere in any size which would be great for anyone else wanting to leverage them for their own use.

3) potential formatting issues (maybe not such a big deal)
* some of the floatingBox.jelly files have extra links/info above or below them that stand out a bit much when placed in a grid of trend maps.  This is minor though and probably doesn't really matter.


By "refining an abstraction" do you mean creating a new tag under lib.hudson for floatingBox that defines these attributes and then includes the floatingBox.jelly from the respective action?  I'll give that a try locally with the test result action and see how it goes.

thanks a lot,
Timo

2009/7/1 Kohsuke Kawaguchi <[hidden email]>

If the size of the box is the main issue, maybe we should refine an
abstraction so that the size information gets passed to the jelly view,
instead of defining another jelly view with a fixed size? Or maybe
that's what you did with the sectionFloatingBox.jelly?

I believe the Jelly views would need to be in the respective plugins,
partly because of classloader issues and how Stapler finds them, partly
because of compatibility issues when those plugins evolve later and
break things that you rely on.


Timothy Bingaman wrote:
> Hi all,
>
> Quick question about where to put files that are used by one plugin, but
> rendered by other plugins.
>
> I've been working on a new Section type for my Section View Plugin that
> displays mini versions of the trend graphs produced by floatingBox.jelly
> files.
>
> see the wiki for a pic:
> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress%28unreleased%29>
>
> Because the paths, graph sizes, and positioning are different in this case I
> can't use the floatingBox.jelly files.
> I've coded it to pull modified copies of these called
> sectionFloatingBox.jelly.
>
> The question is, should I talk to each report plugin maintainer to see if I
> can add a sectionFloatingBox.jelly file to their plugin (this would include
> adding one to Hudson Core for the TestResultProjectAction)?  Or should I
> just bundle them all in my plugin (using the package name of the plugin
> which they are for so jelly finds them correctly from the action classes)?
>
> thanks a lot for the help,
> Timo


--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/



--
Timothy Bingaman
Software Engineer, Open Cloud Limited
Level 4, 54-56 Cambridge Tce, Wellington, New Zealand
http://www.opencloud.com
t:  +64 4 977 4782
m:  +64 21 027 33614
linkedIn:  http://www.linkedin.com/in/timobingaman
Reply | Threaded
Open this post in threaded view
|

Re: where to put cross-plugin include files?

Timothy Bingaman
Hi Kohsuke,

I've got a solution that lets me use the floatingBox.jelly files (although it requires some small changes to them).

Can you take a look at the attached patch when you have a minute and let me know what you think and if I can commit it?

thanks a lot,
Timo

2009/7/1 Timothy Bingaman <[hidden email]>
Hey Kohsuke,

thanks for the response.
and yes, I just tried putting them in my own plugin and realised that the classloader wouldn't pick them up from there.

There are a few problems with using the floatingBox.jelly files as they are.

1) size
* arguments passed in would be great for this - applied to the image and the imageMap (if a map is used)

2) the relative urls
* currently, they are either hardcoded (like "test" for the test result one or they use ${from.urlName})
* since I'm displaying them one level up I need ${job.shortUrl}${from.urlName}
* this could be resolved by a relative link argument

making those changes would allow the graphs to be embedded pretty much anywhere in any size which would be great for anyone else wanting to leverage them for their own use.

3) potential formatting issues (maybe not such a big deal)
* some of the floatingBox.jelly files have extra links/info above or below them that stand out a bit much when placed in a grid of trend maps.  This is minor though and probably doesn't really matter.


By "refining an abstraction" do you mean creating a new tag under lib.hudson for floatingBox that defines these attributes and then includes the floatingBox.jelly from the respective action?  I'll give that a try locally with the test result action and see how it goes.

thanks a lot,
Timo

2009/7/1 Kohsuke Kawaguchi <[hidden email]>


If the size of the box is the main issue, maybe we should refine an
abstraction so that the size information gets passed to the jelly view,
instead of defining another jelly view with a fixed size? Or maybe
that's what you did with the sectionFloatingBox.jelly?

I believe the Jelly views would need to be in the respective plugins,
partly because of classloader issues and how Stapler finds them, partly
because of compatibility issues when those plugins evolve later and
break things that you rely on.


Timothy Bingaman wrote:
> Hi all,
>
> Quick question about where to put files that are used by one plugin, but
> rendered by other plugins.
>
> I've been working on a new Section type for my Section View Plugin that
> displays mini versions of the trend graphs produced by floatingBox.jelly
> files.
>
> see the wiki for a pic:
> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress%28unreleased%29>
>
> Because the paths, graph sizes, and positioning are different in this case I
> can't use the floatingBox.jelly files.
> I've coded it to pull modified copies of these called
> sectionFloatingBox.jelly.
>
> The question is, should I talk to each report plugin maintainer to see if I
> can add a sectionFloatingBox.jelly file to their plugin (this would include
> adding one to Hudson Core for the TestResultProjectAction)?  Or should I
> just bundle them all in my plugin (using the package name of the plugin
> which they are for so jelly finds them correctly from the action classes)?
>
> thanks a lot for the help,
> Timo


--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/



--
Timothy Bingaman
Software Engineer, Open Cloud Limited
Level 4, 54-56 Cambridge Tce, Wellington, New Zealand
http://www.opencloud.com
t:  +64 4 977 4782
m:  +64 21 027 33614
linkedIn:  http://www.linkedin.com/in/timobingaman



--
Timothy Bingaman
Software Engineer, Open Cloud Limited
Level 4, 54-56 Cambridge Tce, Wellington, New Zealand
http://www.opencloud.com
t:  +64 4 977 4782
m:  +64 21 027 33614
linkedIn:  http://www.linkedin.com/in/timobingaman

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

floatingBox.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: where to put cross-plugin include files?

Kohsuke Kawaguchi
Administrator
In reply to this post by Timothy Bingaman

My belated response ...

Timothy Bingaman wrote:

> Hey Kohsuke,
>
> thanks for the response.
> and yes, I just tried putting them in my own plugin and realised that the
> classloader wouldn't pick them up from there.
>
> There are a few problems with using the floatingBox.jelly files as they are.
>
> 1) size
> * arguments passed in would be great for this - applied to the image and the
> imageMap (if a map is used)
>
> 2) the relative urls
> * currently, they are either hardcoded (like "test" for the test result one
> or they use ${from.urlName})
> * since I'm displaying them one level up I need
> ${job.shortUrl}${from.urlName}
> * this could be resolved by a relative link argument
>
> making those changes would allow the graphs to be embedded pretty much
> anywhere in any size which would be great for anyone else wanting to
> leverage them for their own use.
I think I now understand what you are really trying to get to.

In this case, I think it's better to define a subtype of Action that
renders graphs. Such a subtype can define methods to render graph,
imagemap, title, etc., in a desirable size.

Graphs are of particular interest to machine clients (we just had an
inquiry in the dev list asking how one can enumerate graphs from the
remote API, and think about NetBeans picking up all the graphs from
plugins, too.

The current floatingBox.jelly allows arbitrary HTML fragment, which goes
beyond just graphs, and generally it's hard to generate the right HTML
that fits into a given size.


> 3) potential formatting issues (maybe not such a big deal)
> * some of the floatingBox.jelly files have extra links/info above or below
> them that stand out a bit much when placed in a grid of trend maps.  This is
> minor though and probably doesn't really matter.
>
>
> By "refining an abstraction" do you mean creating a new tag under lib.hudson
> for floatingBox that defines these attributes and then includes the
> floatingBox.jelly from the respective action?  I'll give that a try locally
> with the test result action and see how it goes.
Now that I understand your motivation better, "refining an abstraction"
means defining additional interfaces for rendering graphs.

>
> thanks a lot,
> Timo
>
> 2009/7/1 Kohsuke Kawaguchi <[hidden email]>
>
>>
>> If the size of the box is the main issue, maybe we should refine an
>> abstraction so that the size information gets passed to the jelly view,
>> instead of defining another jelly view with a fixed size? Or maybe
>> that's what you did with the sectionFloatingBox.jelly?
>>
>> I believe the Jelly views would need to be in the respective plugins,
>> partly because of classloader issues and how Stapler finds them, partly
>> because of compatibility issues when those plugins evolve later and
>> break things that you rely on.
>>
>>
>> Timothy Bingaman wrote:
>> > Hi all,
>> >
>> > Quick question about where to put files that are used by one plugin, but
>> > rendered by other plugins.
>> >
>> > I've been working on a new Section type for my Section View Plugin that
>> > displays mini versions of the trend graphs produced by floatingBox.jelly
>> > files.
>> >
>> > see the wiki for a pic:
>> >
>> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress%28unreleased%29>
>> <
>> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedViewPlugin-WorkInProgress%28unreleased%29
>> >
>> >
>> > Because the paths, graph sizes, and positioning are different in this
>> case I
>> > can't use the floatingBox.jelly files.
>> > I've coded it to pull modified copies of these called
>> > sectionFloatingBox.jelly.
>> >
>> > The question is, should I talk to each report plugin maintainer to see if
>> I
>> > can add a sectionFloatingBox.jelly file to their plugin (this would
>> include
>> > adding one to Hudson Core for the TestResultProjectAction)?  Or should I
>> > just bundle them all in my plugin (using the package name of the plugin
>> > which they are for so jelly finds them correctly from the action
>> classes)?
>> >
>> > thanks a lot for the help,
>> > Timo
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>>
>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re: where to put cross-plugin include files?

Ulli Hafner-2
Wouldn't it be better if there would exist a kind of "portlet"
abstraction in Hudson
(as e.g. in Jira)? (Or is the action subclass you mentioned already that
kind of abstraction?)

I.e., plug-ins could contribute portlet instances rather than a
singleton floatingBox.jelly.
That would allow easy re-arrangements of the portlets in Hudson and you
can use multiple instances
of a portlet from the same plug-in (with different configurations). The
portlet abstraction then
could also provide a global configuration of shared properties like
title and size.

Ulli

> My belated response ...
>
> Timothy Bingaman wrote:
> > Hey Kohsuke,
> >
> > thanks for the response.
> > and yes, I just tried putting them in my own plugin and
> realised that the
> > classloader wouldn't pick them up from there.
> >
> > There are a few problems with using the floatingBox.jelly
> files as they are.
> >
> > 1) size
> > * arguments passed in would be great for this - applied to
> the image and the
> > imageMap (if a map is used)
> >
> > 2) the relative urls
> > * currently, they are either hardcoded (like "test" for the
> test result one
> > or they use ${from.urlName})
> > * since I'm displaying them one level up I need
> > ${job.shortUrl}${from.urlName}
> > * this could be resolved by a relative link argument
> >
> > making those changes would allow the graphs to be embedded
> pretty much
> > anywhere in any size which would be great for anyone else wanting to
> > leverage them for their own use.
>
> I think I now understand what you are really trying to get to.
>
> In this case, I think it's better to define a subtype of Action that
> renders graphs. Such a subtype can define methods to render graph,
> imagemap, title, etc., in a desirable size.
>
> Graphs are of particular interest to machine clients (we just had an
> inquiry in the dev list asking how one can enumerate graphs from the
> remote API, and think about NetBeans picking up all the graphs from
> plugins, too.
>
> The current floatingBox.jelly allows arbitrary HTML fragment,
> which goes
> beyond just graphs, and generally it's hard to generate the right HTML
> that fits into a given size.
>
>
> > 3) potential formatting issues (maybe not such a big deal)
> > * some of the floatingBox.jelly files have extra links/info
> above or below
> > them that stand out a bit much when placed in a grid of
> trend maps.  This is
> > minor though and probably doesn't really matter.
> >
> >
> > By "refining an abstraction" do you mean creating a new tag
> under lib.hudson
> > for floatingBox that defines these attributes and then includes the
> > floatingBox.jelly from the respective action?  I'll give
> that a try locally
> > with the test result action and see how it goes.
>
> Now that I understand your motivation better, "refining an
> abstraction"
> means defining additional interfaces for rendering graphs.
>
> >
> > thanks a lot,
> > Timo
> >
> > 2009/7/1 Kohsuke Kawaguchi <[hidden email]>
> >
> >>
> >> If the size of the box is the main issue, maybe we should refine an
> >> abstraction so that the size information gets passed to
> the jelly view,
> >> instead of defining another jelly view with a fixed size? Or maybe
> >> that's what you did with the sectionFloatingBox.jelly?
> >>
> >> I believe the Jelly views would need to be in the
> respective plugins,
> >> partly because of classloader issues and how Stapler finds
> them, partly
> >> because of compatibility issues when those plugins evolve later and
> >> break things that you rely on.
> >>
> >>
> >> Timothy Bingaman wrote:
> >> > Hi all,
> >> >
> >> > Quick question about where to put files that are used by
> one plugin, but
> >> > rendered by other plugins.
> >> >
> >> > I've been working on a new Section type for my Section
> View Plugin that
> >> > displays mini versions of the trend graphs produced by
> floatingBox.jelly
> >> > files.
> >> >
> >> > see the wiki for a pic:
> >> >
> >>
> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin
> #SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hu
> dson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedView
> Plugin-WorkInProgress%28unreleased%29>
> >> <
> >>
> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin
> #SectionedViewPlugin-WorkInProgress%28unreleased%29
> >> >
> >> >
> >> > Because the paths, graph sizes, and positioning are
> different in this
> >> case I
> >> > can't use the floatingBox.jelly files.
> >> > I've coded it to pull modified copies of these called
> >> > sectionFloatingBox.jelly.
> >> >
> >> > The question is, should I talk to each report plugin
> maintainer to see if
> >> I
> >> > can add a sectionFloatingBox.jelly file to their plugin
> (this would
> >> include
> >> > adding one to Hudson Core for the
> TestResultProjectAction)?  Or should I
> >> > just bundle them all in my plugin (using the package
> name of the plugin
> >> > which they are for so jelly finds them correctly from the action
> >> classes)?
> >> >
> >> > thanks a lot for the help,
> >> > Timo
> >>
> >>
> >> --
> >> Kohsuke Kawaguchi
> >> Sun Microsystems                  
> http://weblogs.java.net/blog/kohsuke/
> >>
> >
> >
> >
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                  
> http://weblogs.java.net/blog/kohsuke/
>

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

Reply | Threaded
Open this post in threaded view
|

Re: where to put cross-plugin include files?

Kohsuke Kawaguchi
Administrator
Hafner Ullrich wrote:

> Wouldn't it be better if there would exist a kind of "portlet"
> abstraction in Hudson
> (as e.g. in Jira)? (Or is the action subclass you mentioned already that
> kind of abstraction?)
>
> I.e., plug-ins could contribute portlet instances rather than a
> singleton floatingBox.jelly.
> That would allow easy re-arrangements of the portlets in Hudson and you
> can use multiple instances
> of a portlet from the same plug-in (with different configurations). The
> portlet abstraction then
> could also provide a global configuration of shared properties like
> title and size.
Indeed. Now this would take more coding, which is probably the only
downside...

>
> Ulli
>
>> My belated response ...
>>
>> Timothy Bingaman wrote:
>> > Hey Kohsuke,
>> >
>> > thanks for the response.
>> > and yes, I just tried putting them in my own plugin and
>> realised that the
>> > classloader wouldn't pick them up from there.
>> >
>> > There are a few problems with using the floatingBox.jelly
>> files as they are.
>> >
>> > 1) size
>> > * arguments passed in would be great for this - applied to
>> the image and the
>> > imageMap (if a map is used)
>> >
>> > 2) the relative urls
>> > * currently, they are either hardcoded (like "test" for the
>> test result one
>> > or they use ${from.urlName})
>> > * since I'm displaying them one level up I need
>> > ${job.shortUrl}${from.urlName}
>> > * this could be resolved by a relative link argument
>> >
>> > making those changes would allow the graphs to be embedded
>> pretty much
>> > anywhere in any size which would be great for anyone else wanting to
>> > leverage them for their own use.
>>
>> I think I now understand what you are really trying to get to.
>>
>> In this case, I think it's better to define a subtype of Action that
>> renders graphs. Such a subtype can define methods to render graph,
>> imagemap, title, etc., in a desirable size.
>>
>> Graphs are of particular interest to machine clients (we just had an
>> inquiry in the dev list asking how one can enumerate graphs from the
>> remote API, and think about NetBeans picking up all the graphs from
>> plugins, too.
>>
>> The current floatingBox.jelly allows arbitrary HTML fragment,
>> which goes
>> beyond just graphs, and generally it's hard to generate the right HTML
>> that fits into a given size.
>>
>>
>> > 3) potential formatting issues (maybe not such a big deal)
>> > * some of the floatingBox.jelly files have extra links/info
>> above or below
>> > them that stand out a bit much when placed in a grid of
>> trend maps.  This is
>> > minor though and probably doesn't really matter.
>> >
>> >
>> > By "refining an abstraction" do you mean creating a new tag
>> under lib.hudson
>> > for floatingBox that defines these attributes and then includes the
>> > floatingBox.jelly from the respective action?  I'll give
>> that a try locally
>> > with the test result action and see how it goes.
>>
>> Now that I understand your motivation better, "refining an
>> abstraction"
>> means defining additional interfaces for rendering graphs.
>>
>> >
>> > thanks a lot,
>> > Timo
>> >
>> > 2009/7/1 Kohsuke Kawaguchi <[hidden email]>
>> >
>> >>
>> >> If the size of the box is the main issue, maybe we should refine an
>> >> abstraction so that the size information gets passed to
>> the jelly view,
>> >> instead of defining another jelly view with a fixed size? Or maybe
>> >> that's what you did with the sectionFloatingBox.jelly?
>> >>
>> >> I believe the Jelly views would need to be in the
>> respective plugins,
>> >> partly because of classloader issues and how Stapler finds
>> them, partly
>> >> because of compatibility issues when those plugins evolve later and
>> >> break things that you rely on.
>> >>
>> >>
>> >> Timothy Bingaman wrote:
>> >> > Hi all,
>> >> >
>> >> > Quick question about where to put files that are used by
>> one plugin, but
>> >> > rendered by other plugins.
>> >> >
>> >> > I've been working on a new Section type for my Section
>> View Plugin that
>> >> > displays mini versions of the trend graphs produced by
>> floatingBox.jelly
>> >> > files.
>> >> >
>> >> > see the wiki for a pic:
>> >> >
>> >>
>> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin
>> #SectionedViewPlugin-WorkInProgress(unreleased)<http://wiki.hu
>> dson-ci.org/display/HUDSON/Sectioned+View+Plugin#SectionedView
>> Plugin-WorkInProgress%28unreleased%29>
>> >> <
>> >>
>> http://wiki.hudson-ci.org/display/HUDSON/Sectioned+View+Plugin
>> #SectionedViewPlugin-WorkInProgress%28unreleased%29
>> >> >
>> >> >
>> >> > Because the paths, graph sizes, and positioning are
>> different in this
>> >> case I
>> >> > can't use the floatingBox.jelly files.
>> >> > I've coded it to pull modified copies of these called
>> >> > sectionFloatingBox.jelly.
>> >> >
>> >> > The question is, should I talk to each report plugin
>> maintainer to see if
>> >> I
>> >> > can add a sectionFloatingBox.jelly file to their plugin
>> (this would
>> >> include
>> >> > adding one to Hudson Core for the
>> TestResultProjectAction)?  Or should I
>> >> > just bundle them all in my plugin (using the package
>> name of the plugin
>> >> > which they are for so jelly finds them correctly from the action
>> >> classes)?
>> >> >
>> >> > thanks a lot for the help,
>> >> > Timo
>> >>
>> >>
>> >> --
>> >> Kohsuke Kawaguchi
>> >> Sun Microsystems                  
>> http://weblogs.java.net/blog/kohsuke/
>> >>
>> >
>> >
>> >
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems                  
>> http://weblogs.java.net/blog/kohsuke/
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

smime.p7s (4K) Download Attachment