Reporting as instructed

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

Reporting as instructed

Gregory Kick-2
I am diligently reporting an error as instructed. :-)  I'm doing a
maven2 build and had just changed my goals from "clean deploy" to
"clean deploy site-deploy" when I got:

[INFO] ------------------------------------------------------------------------
[INFO] ComponentConfigurationFilter being reused. This is a bug in
Hudson. Please report that to the development team.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: ComponentConfigurationFilter being
reused. This is a bug in Hudson. Please report that to the development
team.
        at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
        at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
        at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
        at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
        at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
        at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at hudson.maven.agent.Main.launch(Main.java:70)
        at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
        at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
        at hudson.remoting.UserRequest.perform(UserRequest.java:57)
        at hudson.remoting.UserRequest.perform(UserRequest.java:22)
        at hudson.remoting.Request$2.run(Request.java:178)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:613)

any thoughts?
--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
Thank you.

I believe this is issue #520
(https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
fixed in the latest 1.105.

2007/4/30, Gregory Kick <[hidden email]>:

> I am diligently reporting an error as instructed. :-)  I'm doing a
> maven2 build and had just changed my goals from "clean deploy" to
> "clean deploy site-deploy" when I got:
>
> [INFO] ------------------------------------------------------------------------
> [INFO] ComponentConfigurationFilter being reused. This is a bug in
> Hudson. Please report that to the development team.
> [INFO] ------------------------------------------------------------------------
> [INFO] Trace
> java.lang.IllegalStateException: ComponentConfigurationFilter being
> reused. This is a bug in Hudson. Please report that to the development
> team.
>         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
>         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
>         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
>         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
>         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
>         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>         at hudson.maven.agent.Main.launch(Main.java:70)
>         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
>         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
>         at hudson.remoting.Request$2.run(Request.java:178)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:613)
>
> any thoughts?
> --
> Gregory Kick
> http://kickstyle.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
Well, it's not particularly pressing so I'll wait for 1.105 and let
you know if it works out.

On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:

> Thank you.
>
> I believe this is issue #520
> (https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
> fixed in the latest 1.105.
>
> 2007/4/30, Gregory Kick <[hidden email]>:
> > I am diligently reporting an error as instructed. :-)  I'm doing a
> > maven2 build and had just changed my goals from "clean deploy" to
> > "clean deploy site-deploy" when I got:
> >
> > [INFO] ------------------------------------------------------------------------
> > [INFO] ComponentConfigurationFilter being reused. This is a bug in
> > Hudson. Please report that to the development team.
> > [INFO] ------------------------------------------------------------------------
> > [INFO] Trace
> > java.lang.IllegalStateException: ComponentConfigurationFilter being
> > reused. This is a bug in Hudson. Please report that to the development
> > team.
> >         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
> >         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
> >         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
> >         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
> >         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> >         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
> >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> >         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> >         at java.lang.reflect.Method.invoke(Method.java:585)
> >         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> >         at hudson.maven.agent.Main.launch(Main.java:70)
> >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
> >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
> >         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
> >         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
> >         at hudson.remoting.Request$2.run(Request.java:178)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> >         at java.lang.Thread.run(Thread.java:613)
> >
> > any thoughts?
> > --
> > Gregory Kick
> > http://kickstyle.net/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Kohsuke Kawaguchi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
1.105 is already released.

2007/4/30, Gregory Kick <[hidden email]>:

> Well, it's not particularly pressing so I'll wait for 1.105 and let
> you know if it works out.
>
> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > Thank you.
> >
> > I believe this is issue #520
> > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
> > fixed in the latest 1.105.
> >
> > 2007/4/30, Gregory Kick <[hidden email]>:
> > > I am diligently reporting an error as instructed. :-)  I'm doing a
> > > maven2 build and had just changed my goals from "clean deploy" to
> > > "clean deploy site-deploy" when I got:
> > >
> > > [INFO] ------------------------------------------------------------------------
> > > [INFO] ComponentConfigurationFilter being reused. This is a bug in
> > > Hudson. Please report that to the development team.
> > > [INFO] ------------------------------------------------------------------------
> > > [INFO] Trace
> > > java.lang.IllegalStateException: ComponentConfigurationFilter being
> > > reused. This is a bug in Hudson. Please report that to the development
> > > team.
> > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
> > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
> > >         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
> > >         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
> > >         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> > >         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
> > >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> > >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> > >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >         at java.lang.reflect.Method.invoke(Method.java:585)
> > >         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > >         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> > >         at hudson.maven.agent.Main.launch(Main.java:70)
> > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
> > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
> > >         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
> > >         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
> > >         at hudson.remoting.Request$2.run(Request.java:178)
> > >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> > >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> > >         at java.lang.Thread.run(Thread.java:613)
> > >
> > > any thoughts?
> > > --
> > > Gregory Kick
> > > http://kickstyle.net/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Kohsuke Kawaguchi
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Gregory Kick
> http://kickstyle.net/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
Really?  How'd I miss that..?  In that case, I'll give it a try and
let you know.

On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:

> 1.105 is already released.
>
> 2007/4/30, Gregory Kick <[hidden email]>:
> > Well, it's not particularly pressing so I'll wait for 1.105 and let
> > you know if it works out.
> >
> > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > > Thank you.
> > >
> > > I believe this is issue #520
> > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
> > > fixed in the latest 1.105.
> > >
> > > 2007/4/30, Gregory Kick <[hidden email]>:
> > > > I am diligently reporting an error as instructed. :-)  I'm doing a
> > > > maven2 build and had just changed my goals from "clean deploy" to
> > > > "clean deploy site-deploy" when I got:
> > > >
> > > > [INFO] ------------------------------------------------------------------------
> > > > [INFO] ComponentConfigurationFilter being reused. This is a bug in
> > > > Hudson. Please report that to the development team.
> > > > [INFO] ------------------------------------------------------------------------
> > > > [INFO] Trace
> > > > java.lang.IllegalStateException: ComponentConfigurationFilter being
> > > > reused. This is a bug in Hudson. Please report that to the development
> > > > team.
> > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
> > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
> > > >         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
> > > >         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
> > > >         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> > > >         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
> > > >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> > > >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> > > >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > >         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > >         at java.lang.reflect.Method.invoke(Method.java:585)
> > > >         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > > >         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> > > >         at hudson.maven.agent.Main.launch(Main.java:70)
> > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
> > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
> > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
> > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
> > > >         at hudson.remoting.Request$2.run(Request.java:178)
> > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> > > >         at java.lang.Thread.run(Thread.java:613)
> > > >
> > > > any thoughts?
> > > > --
> > > > Gregory Kick
> > > > http://kickstyle.net/
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> > > --
> > > Kohsuke Kawaguchi
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Gregory Kick
> > http://kickstyle.net/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Kohsuke Kawaguchi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
I've got good news and bad.  The site-deploy part works, but 1.105
gives me some problems with maven and a jdks on os x.  It seems that
when support for the directory structure was added it points to
.../version/ instead of .../version/Home.  I'd just figured that that
was necessary for whatever reason, but now that 1.105 is actually
using the path specified to invoke java it fails because it just tacks
bin/java onto the end instead of Home/bin/java.  Should be an easy fix
to just make sure the directories point to the Home directory...

On 4/30/07, Gregory Kick <[hidden email]> wrote:

> Really?  How'd I miss that..?  In that case, I'll give it a try and
> let you know.
>
> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > 1.105 is already released.
> >
> > 2007/4/30, Gregory Kick <[hidden email]>:
> > > Well, it's not particularly pressing so I'll wait for 1.105 and let
> > > you know if it works out.
> > >
> > > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > > > Thank you.
> > > >
> > > > I believe this is issue #520
> > > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
> > > > fixed in the latest 1.105.
> > > >
> > > > 2007/4/30, Gregory Kick <[hidden email]>:
> > > > > I am diligently reporting an error as instructed. :-)  I'm doing a
> > > > > maven2 build and had just changed my goals from "clean deploy" to
> > > > > "clean deploy site-deploy" when I got:
> > > > >
> > > > > [INFO] ------------------------------------------------------------------------
> > > > > [INFO] ComponentConfigurationFilter being reused. This is a bug in
> > > > > Hudson. Please report that to the development team.
> > > > > [INFO] ------------------------------------------------------------------------
> > > > > [INFO] Trace
> > > > > java.lang.IllegalStateException: ComponentConfigurationFilter being
> > > > > reused. This is a bug in Hudson. Please report that to the development
> > > > > team.
> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
> > > > >         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
> > > > >         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
> > > > >         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> > > > >         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
> > > > >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> > > > >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> > > > >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > > > >         at java.lang.reflect.Method.invoke(Method.java:585)
> > > > >         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > > > >         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> > > > >         at hudson.maven.agent.Main.launch(Main.java:70)
> > > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
> > > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
> > > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
> > > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
> > > > >         at hudson.remoting.Request$2.run(Request.java:178)
> > > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> > > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> > > > >         at java.lang.Thread.run(Thread.java:613)
> > > > >
> > > > > any thoughts?
> > > > > --
> > > > > Gregory Kick
> > > > > http://kickstyle.net/
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Kohsuke Kawaguchi
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> > > --
> > > Gregory Kick
> > > http://kickstyle.net/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Kohsuke Kawaguchi
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Gregory Kick
> http://kickstyle.net/
>


--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Rhett Sutphin
Hi,

On Apr 30, 2007, at 10:48 AM, Gregory Kick wrote:

> I've got good news and bad.  The site-deploy part works, but 1.105
> gives me some problems with maven and a jdks on os x.  It seems that
> when support for the directory structure was added it points to
> .../version/ instead of .../version/Home.  I'd just figured that that
> was necessary for whatever reason, but now that 1.105 is actually
> using the path specified to invoke java it fails because it just tacks
> bin/java onto the end instead of Home/bin/java.  Should be an easy fix
> to just make sure the directories point to the Home directory...

FWIW, I'm using 1.105 on OS X.  I'm just letting hudson use the  
version of java that's on the PATH (i.e., I don't have any specified  
in hudson's system configuration), which works fine.  If you don't  
need to use a particular JVM, then this might work for you, too.

Rhett

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
Yeah, that's what I did to get past the failed builds, but I'd like to
be able to run some with 1.4 and some with 1.5...

On 4/30/07, Rhett Sutphin <[hidden email]> wrote:

> Hi,
>
> On Apr 30, 2007, at 10:48 AM, Gregory Kick wrote:
>
> > I've got good news and bad.  The site-deploy part works, but 1.105
> > gives me some problems with maven and a jdks on os x.  It seems that
> > when support for the directory structure was added it points to
> > .../version/ instead of .../version/Home.  I'd just figured that that
> > was necessary for whatever reason, but now that 1.105 is actually
> > using the path specified to invoke java it fails because it just tacks
> > bin/java onto the end instead of Home/bin/java.  Should be an easy fix
> > to just make sure the directories point to the Home directory...
>
> FWIW, I'm using 1.105 on OS X.  I'm just letting hudson use the
> version of java that's on the PATH (i.e., I don't have any specified
> in hudson's system configuration), which works fine.  If you don't
> need to use a particular JVM, then this might work for you, too.
>
> Rhett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
In reply to this post by Gregory Kick-2
Gregory Kick wrote:
> I've got good news and bad.  The site-deploy part works, but 1.105
> gives me some problems with maven and a jdks on os x.  It seems that
> when support for the directory structure was added it points to
> ../version/ instead of .../version/Home.  I'd just figured that that
> was necessary for whatever reason, but now that 1.105 is actually
> using the path specified to invoke java it fails because it just tacks
> bin/java onto the end instead of Home/bin/java.  Should be an easy fix
> to just make sure the directories point to the Home directory...

OK. So just to make sure (I know I can go back my e-mail archive to find
the ls -lR e-mail you sent me), on MacOS X java executable is

   $JAVA_HOME/Home/java

?

>
> On 4/30/07, Gregory Kick <[hidden email]> wrote:
>> Really?  How'd I miss that..?  In that case, I'll give it a try and
>> let you know.
>>
>> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>> > 1.105 is already released.
>> >
>> > 2007/4/30, Gregory Kick <[hidden email]>:
>> > > Well, it's not particularly pressing so I'll wait for 1.105 and let
>> > > you know if it works out.
>> > >
>> > > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>> > > > Thank you.
>> > > >
>> > > > I believe this is issue #520
>> > > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520) and already
>> > > > fixed in the latest 1.105.
>> > > >
>> > > > 2007/4/30, Gregory Kick <[hidden email]>:
>> > > > > I am diligently reporting an error as instructed. :-)  I'm doing a
>> > > > > maven2 build and had just changed my goals from "clean deploy" to
>> > > > > "clean deploy site-deploy" when I got:
>> > > > >
>> > > > > [INFO] ------------------------------------------------------------------------
>> > > > > [INFO] ComponentConfigurationFilter being reused. This is a bug in
>> > > > > Hudson. Please report that to the development team.
>> > > > > [INFO] ------------------------------------------------------------------------
>> > > > > [INFO] Trace
>> > > > > java.lang.IllegalStateException: ComponentConfigurationFilter being
>> > > > > reused. This is a bug in Hudson. Please report that to the development
>> > > > > team.
>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.wrap(PluginManagerInterceptor.java:81)
>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1$1.lookup(PluginManagerInterceptor.java:64)
>> > > > >         at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1049)
>> > > > >         at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:584)
>> > > > >         at org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:470)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:683)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:642)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:517)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
>> > > > >         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
>> > > > >         at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:35)
>> > > > >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
>> > > > >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
>> > > > >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> > > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> > > > >         at java.lang.reflect.Method.invoke(Method.java:585)
>> > > > >         at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> > > > >         at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> > > > >         at hudson.maven.agent.Main.launch(Main.java:70)
>> > > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:171)
>> > > > >         at hudson.maven.MavenBuild$Builder.call(MavenBuild.java:139)
>> > > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
>> > > > >         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
>> > > > >         at hudson.remoting.Request$2.run(Request.java:178)
>> > > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>> > > > >         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>> > > > >         at java.lang.Thread.run(Thread.java:613)
>> > > > >
>> > > > > any thoughts?
>> > > > > --
>> > > > > Gregory Kick
>> > > > > http://kickstyle.net/
>> > > > >
>> > > > > ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: [hidden email]
>> > > > > For additional commands, e-mail: [hidden email]
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Kohsuke Kawaguchi
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: [hidden email]
>> > > > For additional commands, e-mail: [hidden email]
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Gregory Kick
>> > > http://kickstyle.net/
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> > >
>> >
>> >
>> > --
>> > Kohsuke Kawaguchi
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> Gregory Kick
>> http://kickstyle.net/
>>
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: Reporting as instructed

Rhett Sutphin
Hi,

I'm arriving at this topic late, so I may have missed something -- I  
don't think the JAVA_HOME layout on OS X is different from other  
platforms.  On OS X you have /Library/Java/Home (for the default JDK)  
and several directories like /System/Library/Frameworks/
JavaVM.framework/Versions/1.5.0/Home for specific versions.

Each one of these directories contains bin/ (which contains `java`),  
lib/ and include/, which appears to match with the JDKs on a Linux  
machine.  (I'm comparing it to Linux because that's the other  
platform I have available at the moment.)  The existence of "Home" in  
the directory name is different (the Linux box I'm looking at just  
has /usr/java/[version]).

I hadn't tried this before, but Hudson complains when you give it /
Library/Java/Home (or /System/Library/Frameworks/JavaVM.framework/
Versions/1.5.0/Home) as JAVA_HOME.  (The error is "... doesn't look  
like a JDK directory".)  It doesn't complain when you give it just /
Library/Java or /System/Library/Frameworks/JavaVM.framework/Versions/
1.5.0, even though these are not valid java homes.

Like I said, I didn't see the full thread on this topic, but I'm  
wondering if the solution is to change the input validation for  
JAVA_HOME to accept the actual java home on OS X, rather than special-
casing the path for the java executable.

Rhett

On Apr 30, 2007, at 8:25 PM, Kohsuke Kawaguchi wrote:

> Gregory Kick wrote:
>> I've got good news and bad.  The site-deploy part works, but 1.105
>> gives me some problems with maven and a jdks on os x.  It seems that
>> when support for the directory structure was added it points to
>> ../version/ instead of .../version/Home.  I'd just figured that that
>> was necessary for whatever reason, but now that 1.105 is actually
>> using the path specified to invoke java it fails because it just  
>> tacks
>> bin/java onto the end instead of Home/bin/java.  Should be an easy  
>> fix
>> to just make sure the directories point to the Home directory...
>
> OK. So just to make sure (I know I can go back my e-mail archive to  
> find the ls -lR e-mail you sent me), on MacOS X java executable is
>
>   $JAVA_HOME/Home/java
>
> ?
>
>> On 4/30/07, Gregory Kick <[hidden email]> wrote:
>>> Really?  How'd I miss that..?  In that case, I'll give it a try and
>>> let you know.
>>>
>>> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>>> > 1.105 is already released.
>>> >
>>> > 2007/4/30, Gregory Kick <[hidden email]>:
>>> > > Well, it's not particularly pressing so I'll wait for 1.105  
>>> and let
>>> > > you know if it works out.
>>> > >
>>> > > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>>> > > > Thank you.
>>> > > >
>>> > > > I believe this is issue #520
>>> > > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520)  
>>> and already
>>> > > > fixed in the latest 1.105.
>>> > > >
>>> > > > 2007/4/30, Gregory Kick <[hidden email]>:
>>> > > > > I am diligently reporting an error as instructed. :-)  
>>> I'm doing a
>>> > > > > maven2 build and had just changed my goals from "clean  
>>> deploy" to
>>> > > > > "clean deploy site-deploy" when I got:
>>> > > > >
>>> > > > > [INFO]  
>>> --------------------------------------------------------------------
>>> ----
>>> > > > > [INFO] ComponentConfigurationFilter being reused. This is  
>>> a bug in
>>> > > > > Hudson. Please report that to the development team.
>>> > > > > [INFO]  
>>> --------------------------------------------------------------------
>>> ----
>>> > > > > [INFO] Trace
>>> > > > > java.lang.IllegalStateException:  
>>> ComponentConfigurationFilter being
>>> > > > > reused. This is a bug in Hudson. Please report that to  
>>> the development
>>> > > > > team.
>>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
>>> $1.wrap(PluginManagerInterceptor.java:81)
>>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
>>> $1.lookup(PluginManagerInterceptor.java:64)
>>> > > > >         at  
>>> org.apache.maven.plugin.DefaultPluginManager.populatePluginFields
>>> (DefaultPluginManager.java:1049)
>>> > > > >         at  
>>> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo
>>> (DefaultPluginManager.java:584)
>>> > > > >         at  
>>> org.apache.maven.plugin.DefaultPluginManager.getReport
>>> (DefaultPluginManager.java:470)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
>>> (DefaultLifecycleExecutor.java:683)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
>>> (DefaultLifecycleExecutor.java:642)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
>>> (DefaultLifecycleExecutor.java:517)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithL
>>> ifecycle(DefaultLifecycleExecutor.java:480)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
>>> (DefaultLifecycleExecutor.java:459)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa
>>> ndleFailures(DefaultLifecycleExecutor.java:311)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme
>>> nts(DefaultLifecycleExecutor.java:278)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
>>> (DefaultLifecycleExecutor.java:143)
>>> > > > >         at  
>>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute
>>> (LifecycleExecutorInterceptor.java:35)
>>> > > > >         at org.apache.maven.DefaultMaven.doExecute
>>> (DefaultMaven.java:330)
>>> > > > >         at org.apache.maven.DefaultMaven.execute
>>> (DefaultMaven.java:123)
>>> > > > >         at org.apache.maven.cli.MavenCli.main
>>> (MavenCli.java:272)
>>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0
>>> (Native Method)
>>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:39)
>>> > > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> > > > >         at java.lang.reflect.Method.invoke(Method.java:585)
>>> > > > >         at  
>>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>> > > > >         at org.codehaus.classworlds.Launcher.launch
>>> (Launcher.java:255)
>>> > > > >         at hudson.maven.agent.Main.launch(Main.java:70)
>>> > > > >         at hudson.maven.MavenBuild$Builder.call
>>> (MavenBuild.java:171)
>>> > > > >         at hudson.maven.MavenBuild$Builder.call
>>> (MavenBuild.java:139)
>>> > > > >         at hudson.remoting.UserRequest.perform
>>> (UserRequest.java:57)
>>> > > > >         at hudson.remoting.UserRequest.perform
>>> (UserRequest.java:22)
>>> > > > >         at hudson.remoting.Request$2.run(Request.java:178)
>>> > > > >         at java.util.concurrent.ThreadPoolExecutor
>>> $Worker.runTask(ThreadPoolExecutor.java:650)
>>> > > > >         at java.util.concurrent.ThreadPoolExecutor
>>> $Worker.run(ThreadPoolExecutor.java:675)
>>> > > > >         at java.lang.Thread.run(Thread.java:613)
>>> > > > >
>>> > > > > any thoughts?
>>> > > > > --
>>> > > > > Gregory Kick
>>> > > > > http://kickstyle.net/
>>> > > > >
>>> > > > >  
>>> --------------------------------------------------------------------
>>> -
>>> > > > > To unsubscribe, e-mail: users-
>>> [hidden email]
>>> > > > > For additional commands, e-mail: users-
>>> [hidden email]
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Kohsuke Kawaguchi
>>> > > >
>>> > > >  
>>> --------------------------------------------------------------------
>>> -
>>> > > > To unsubscribe, e-mail: [hidden email]
>>> > > > For additional commands, e-mail: users-
>>> [hidden email]
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > > Gregory Kick
>>> > > http://kickstyle.net/
>>> > >
>>> > >  
>>> --------------------------------------------------------------------
>>> -
>>> > > To unsubscribe, e-mail: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> > Kohsuke Kawaguchi
>>> >
>>> >  
>>> --------------------------------------------------------------------
>>> -
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>>
>>> --
>>> Gregory Kick
>>> http://kickstyle.net/
>>>
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
Thanks. That makes sense. I'm looking at "ls -lR" output Greg sent me,
and I can see that below Home/ it looks reasonably similar to JDK on
other platforms.

One question, though, is where the tools.jar is. Looking at the file
size and all, Classes/classes.jar seems to contain everything, but
this file is not directly referenced from anything inside Home.
Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
dt.jar includes classes.jar via Class-Path manifest entry or
something?

2007/5/1, Rhett Sutphin <[hidden email]>:

> Hi,
>
> I'm arriving at this topic late, so I may have missed something -- I
> don't think the JAVA_HOME layout on OS X is different from other
> platforms.  On OS X you have /Library/Java/Home (for the default JDK)
> and several directories like /System/Library/Frameworks/
> JavaVM.framework/Versions/1.5.0/Home for specific versions.
>
> Each one of these directories contains bin/ (which contains `java`),
> lib/ and include/, which appears to match with the JDKs on a Linux
> machine.  (I'm comparing it to Linux because that's the other
> platform I have available at the moment.)  The existence of "Home" in
> the directory name is different (the Linux box I'm looking at just
> has /usr/java/[version]).
>
> I hadn't tried this before, but Hudson complains when you give it /
> Library/Java/Home (or /System/Library/Frameworks/JavaVM.framework/
> Versions/1.5.0/Home) as JAVA_HOME.  (The error is "... doesn't look
> like a JDK directory".)  It doesn't complain when you give it just /
> Library/Java or /System/Library/Frameworks/JavaVM.framework/Versions/
> 1.5.0, even though these are not valid java homes.
>
> Like I said, I didn't see the full thread on this topic, but I'm
> wondering if the solution is to change the input validation for
> JAVA_HOME to accept the actual java home on OS X, rather than special-
> casing the path for the java executable.
>
> Rhett
>
> On Apr 30, 2007, at 8:25 PM, Kohsuke Kawaguchi wrote:
>
> > Gregory Kick wrote:
> >> I've got good news and bad.  The site-deploy part works, but 1.105
> >> gives me some problems with maven and a jdks on os x.  It seems that
> >> when support for the directory structure was added it points to
> >> ../version/ instead of .../version/Home.  I'd just figured that that
> >> was necessary for whatever reason, but now that 1.105 is actually
> >> using the path specified to invoke java it fails because it just
> >> tacks
> >> bin/java onto the end instead of Home/bin/java.  Should be an easy
> >> fix
> >> to just make sure the directories point to the Home directory...
> >
> > OK. So just to make sure (I know I can go back my e-mail archive to
> > find the ls -lR e-mail you sent me), on MacOS X java executable is
> >
> >   $JAVA_HOME/Home/java
> >
> > ?
> >
> >> On 4/30/07, Gregory Kick <[hidden email]> wrote:
> >>> Really?  How'd I miss that..?  In that case, I'll give it a try and
> >>> let you know.
> >>>
> >>> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >>> > 1.105 is already released.
> >>> >
> >>> > 2007/4/30, Gregory Kick <[hidden email]>:
> >>> > > Well, it's not particularly pressing so I'll wait for 1.105
> >>> and let
> >>> > > you know if it works out.
> >>> > >
> >>> > > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >>> > > > Thank you.
> >>> > > >
> >>> > > > I believe this is issue #520
> >>> > > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520)
> >>> and already
> >>> > > > fixed in the latest 1.105.
> >>> > > >
> >>> > > > 2007/4/30, Gregory Kick <[hidden email]>:
> >>> > > > > I am diligently reporting an error as instructed. :-)
> >>> I'm doing a
> >>> > > > > maven2 build and had just changed my goals from "clean
> >>> deploy" to
> >>> > > > > "clean deploy site-deploy" when I got:
> >>> > > > >
> >>> > > > > [INFO]
> >>> --------------------------------------------------------------------
> >>> ----
> >>> > > > > [INFO] ComponentConfigurationFilter being reused. This is
> >>> a bug in
> >>> > > > > Hudson. Please report that to the development team.
> >>> > > > > [INFO]
> >>> --------------------------------------------------------------------
> >>> ----
> >>> > > > > [INFO] Trace
> >>> > > > > java.lang.IllegalStateException:
> >>> ComponentConfigurationFilter being
> >>> > > > > reused. This is a bug in Hudson. Please report that to
> >>> the development
> >>> > > > > team.
> >>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
> >>> $1.wrap(PluginManagerInterceptor.java:81)
> >>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
> >>> $1.lookup(PluginManagerInterceptor.java:64)
> >>> > > > >         at
> >>> org.apache.maven.plugin.DefaultPluginManager.populatePluginFields
> >>> (DefaultPluginManager.java:1049)
> >>> > > > >         at
> >>> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo
> >>> (DefaultPluginManager.java:584)
> >>> > > > >         at
> >>> org.apache.maven.plugin.DefaultPluginManager.getReport
> >>> (DefaultPluginManager.java:470)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
> >>> (DefaultLifecycleExecutor.java:683)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
> >>> (DefaultLifecycleExecutor.java:642)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
> >>> (DefaultLifecycleExecutor.java:517)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithL
> >>> ifecycle(DefaultLifecycleExecutor.java:480)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
> >>> (DefaultLifecycleExecutor.java:459)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa
> >>> ndleFailures(DefaultLifecycleExecutor.java:311)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme
> >>> nts(DefaultLifecycleExecutor.java:278)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
> >>> (DefaultLifecycleExecutor.java:143)
> >>> > > > >         at
> >>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute
> >>> (LifecycleExecutorInterceptor.java:35)
> >>> > > > >         at org.apache.maven.DefaultMaven.doExecute
> >>> (DefaultMaven.java:330)
> >>> > > > >         at org.apache.maven.DefaultMaven.execute
> >>> (DefaultMaven.java:123)
> >>> > > > >         at org.apache.maven.cli.MavenCli.main
> >>> (MavenCli.java:272)
> >>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0
> >>> (Native Method)
> >>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke
> >>> (NativeMethodAccessorImpl.java:39)
> >>> > > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >>> (DelegatingMethodAccessorImpl.java:25)
> >>> > > > >         at java.lang.reflect.Method.invoke(Method.java:585)
> >>> > > > >         at
> >>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> >>> > > > >         at org.codehaus.classworlds.Launcher.launch
> >>> (Launcher.java:255)
> >>> > > > >         at hudson.maven.agent.Main.launch(Main.java:70)
> >>> > > > >         at hudson.maven.MavenBuild$Builder.call
> >>> (MavenBuild.java:171)
> >>> > > > >         at hudson.maven.MavenBuild$Builder.call
> >>> (MavenBuild.java:139)
> >>> > > > >         at hudson.remoting.UserRequest.perform
> >>> (UserRequest.java:57)
> >>> > > > >         at hudson.remoting.UserRequest.perform
> >>> (UserRequest.java:22)
> >>> > > > >         at hudson.remoting.Request$2.run(Request.java:178)
> >>> > > > >         at java.util.concurrent.ThreadPoolExecutor
> >>> $Worker.runTask(ThreadPoolExecutor.java:650)
> >>> > > > >         at java.util.concurrent.ThreadPoolExecutor
> >>> $Worker.run(ThreadPoolExecutor.java:675)
> >>> > > > >         at java.lang.Thread.run(Thread.java:613)
> >>> > > > >
> >>> > > > > any thoughts?
> >>> > > > > --
> >>> > > > > Gregory Kick
> >>> > > > > http://kickstyle.net/
> >>> > > > >
> >>> > > > >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > > > > To unsubscribe, e-mail: users-
> >>> [hidden email]
> >>> > > > > For additional commands, e-mail: users-
> >>> [hidden email]
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > > >
> >>> > > > --
> >>> > > > Kohsuke Kawaguchi
> >>> > > >
> >>> > > >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > > > To unsubscribe, e-mail: [hidden email]
> >>> > > > For additional commands, e-mail: users-
> >>> [hidden email]
> >>> > > >
> >>> > > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Gregory Kick
> >>> > > http://kickstyle.net/
> >>> > >
> >>> > >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > > To unsubscribe, e-mail: [hidden email]
> >>> > > For additional commands, e-mail: [hidden email]
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>> > --
> >>> > Kohsuke Kawaguchi
> >>> >
> >>> >
> >>> --------------------------------------------------------------------
> >>> -
> >>> > To unsubscribe, e-mail: [hidden email]
> >>> > For additional commands, e-mail: [hidden email]
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>> Gregory Kick
> >>> http://kickstyle.net/
> >>>
> >
> >
> > --
> > Kohsuke Kawaguchi
> > Sun Microsystems                   [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> Thanks. That makes sense. I'm looking at "ls -lR" output Greg sent me,
> and I can see that below Home/ it looks reasonably similar to JDK on
> other platforms.

Yeah, /Library/Java/Home is just a symlink to one of the
.../Versions/#/Home directories.  Those are the ones that are supposed
to be treated as JAVA_HOMEs.

>
> One question, though, is where the tools.jar is. Looking at the file
> size and all, Classes/classes.jar seems to contain everything, but
> this file is not directly referenced from anything inside Home.
> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
> dt.jar includes classes.jar via Class-Path manifest entry or
> something?

OS X is kinda funny in that there is no tools.jar.  It's actually
bundled into one of the other ones (classes.jar I think) so it's
always on the classpath. How classes.jar gets there I still don't
understand either...  I checked the manifests and there's nothing
there.  Any other ideas?

>
> 2007/5/1, Rhett Sutphin <[hidden email]>:
> > Hi,
> >
> > I'm arriving at this topic late, so I may have missed something -- I
> > don't think the JAVA_HOME layout on OS X is different from other
> > platforms.  On OS X you have /Library/Java/Home (for the default JDK)
> > and several directories like /System/Library/Frameworks/
> > JavaVM.framework/Versions/1.5.0/Home for specific versions.
> >
> > Each one of these directories contains bin/ (which contains `java`),
> > lib/ and include/, which appears to match with the JDKs on a Linux
> > machine.  (I'm comparing it to Linux because that's the other
> > platform I have available at the moment.)  The existence of "Home" in
> > the directory name is different (the Linux box I'm looking at just
> > has /usr/java/[version]).
> >
> > I hadn't tried this before, but Hudson complains when you give it /
> > Library/Java/Home (or /System/Library/Frameworks/JavaVM.framework/
> > Versions/1.5.0/Home) as JAVA_HOME.  (The error is "... doesn't look
> > like a JDK directory".)  It doesn't complain when you give it just /
> > Library/Java or /System/Library/Frameworks/JavaVM.framework/Versions/
> > 1.5.0, even though these are not valid java homes.
> >
> > Like I said, I didn't see the full thread on this topic, but I'm
> > wondering if the solution is to change the input validation for
> > JAVA_HOME to accept the actual java home on OS X, rather than special-
> > casing the path for the java executable.
> >
> > Rhett
> >
> > On Apr 30, 2007, at 8:25 PM, Kohsuke Kawaguchi wrote:
> >
> > > Gregory Kick wrote:
> > >> I've got good news and bad.  The site-deploy part works, but 1.105
> > >> gives me some problems with maven and a jdks on os x.  It seems that
> > >> when support for the directory structure was added it points to
> > >> ../version/ instead of .../version/Home.  I'd just figured that that
> > >> was necessary for whatever reason, but now that 1.105 is actually
> > >> using the path specified to invoke java it fails because it just
> > >> tacks
> > >> bin/java onto the end instead of Home/bin/java.  Should be an easy
> > >> fix
> > >> to just make sure the directories point to the Home directory...
> > >
> > > OK. So just to make sure (I know I can go back my e-mail archive to
> > > find the ls -lR e-mail you sent me), on MacOS X java executable is
> > >
> > >   $JAVA_HOME/Home/java
> > >
> > > ?
> > >
> > >> On 4/30/07, Gregory Kick <[hidden email]> wrote:
> > >>> Really?  How'd I miss that..?  In that case, I'll give it a try and
> > >>> let you know.
> > >>>
> > >>> On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > >>> > 1.105 is already released.
> > >>> >
> > >>> > 2007/4/30, Gregory Kick <[hidden email]>:
> > >>> > > Well, it's not particularly pressing so I'll wait for 1.105
> > >>> and let
> > >>> > > you know if it works out.
> > >>> > >
> > >>> > > On 4/30/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > >>> > > > Thank you.
> > >>> > > >
> > >>> > > > I believe this is issue #520
> > >>> > > > (https://hudson.dev.java.net/issues/show_bug.cgi?id=520)
> > >>> and already
> > >>> > > > fixed in the latest 1.105.
> > >>> > > >
> > >>> > > > 2007/4/30, Gregory Kick <[hidden email]>:
> > >>> > > > > I am diligently reporting an error as instructed. :-)
> > >>> I'm doing a
> > >>> > > > > maven2 build and had just changed my goals from "clean
> > >>> deploy" to
> > >>> > > > > "clean deploy site-deploy" when I got:
> > >>> > > > >
> > >>> > > > > [INFO]
> > >>> --------------------------------------------------------------------
> > >>> ----
> > >>> > > > > [INFO] ComponentConfigurationFilter being reused. This is
> > >>> a bug in
> > >>> > > > > Hudson. Please report that to the development team.
> > >>> > > > > [INFO]
> > >>> --------------------------------------------------------------------
> > >>> ----
> > >>> > > > > [INFO] Trace
> > >>> > > > > java.lang.IllegalStateException:
> > >>> ComponentConfigurationFilter being
> > >>> > > > > reused. This is a bug in Hudson. Please report that to
> > >>> the development
> > >>> > > > > team.
> > >>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
> > >>> $1.wrap(PluginManagerInterceptor.java:81)
> > >>> > > > >         at hudson.maven.agent.PluginManagerInterceptor$1
> > >>> $1.lookup(PluginManagerInterceptor.java:64)
> > >>> > > > >         at
> > >>> org.apache.maven.plugin.DefaultPluginManager.populatePluginFields
> > >>> (DefaultPluginManager.java:1049)
> > >>> > > > >         at
> > >>> org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo
> > >>> (DefaultPluginManager.java:584)
> > >>> > > > >         at
> > >>> org.apache.maven.plugin.DefaultPluginManager.getReport
> > >>> (DefaultPluginManager.java:470)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
> > >>> (DefaultLifecycleExecutor.java:683)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports
> > >>> (DefaultLifecycleExecutor.java:642)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
> > >>> (DefaultLifecycleExecutor.java:517)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithL
> > >>> ifecycle(DefaultLifecycleExecutor.java:480)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
> > >>> (DefaultLifecycleExecutor.java:459)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa
> > >>> ndleFailures(DefaultLifecycleExecutor.java:311)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme
> > >>> nts(DefaultLifecycleExecutor.java:278)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
> > >>> (DefaultLifecycleExecutor.java:143)
> > >>> > > > >         at
> > >>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute
> > >>> (LifecycleExecutorInterceptor.java:35)
> > >>> > > > >         at org.apache.maven.DefaultMaven.doExecute
> > >>> (DefaultMaven.java:330)
> > >>> > > > >         at org.apache.maven.DefaultMaven.execute
> > >>> (DefaultMaven.java:123)
> > >>> > > > >         at org.apache.maven.cli.MavenCli.main
> > >>> (MavenCli.java:272)
> > >>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke0
> > >>> (Native Method)
> > >>> > > > >         at sun.reflect.NativeMethodAccessorImpl.invoke
> > >>> (NativeMethodAccessorImpl.java:39)
> > >>> > > > >         at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > >>> (DelegatingMethodAccessorImpl.java:25)
> > >>> > > > >         at java.lang.reflect.Method.invoke(Method.java:585)
> > >>> > > > >         at
> > >>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> > >>> > > > >         at org.codehaus.classworlds.Launcher.launch
> > >>> (Launcher.java:255)
> > >>> > > > >         at hudson.maven.agent.Main.launch(Main.java:70)
> > >>> > > > >         at hudson.maven.MavenBuild$Builder.call
> > >>> (MavenBuild.java:171)
> > >>> > > > >         at hudson.maven.MavenBuild$Builder.call
> > >>> (MavenBuild.java:139)
> > >>> > > > >         at hudson.remoting.UserRequest.perform
> > >>> (UserRequest.java:57)
> > >>> > > > >         at hudson.remoting.UserRequest.perform
> > >>> (UserRequest.java:22)
> > >>> > > > >         at hudson.remoting.Request$2.run(Request.java:178)
> > >>> > > > >         at java.util.concurrent.ThreadPoolExecutor
> > >>> $Worker.runTask(ThreadPoolExecutor.java:650)
> > >>> > > > >         at java.util.concurrent.ThreadPoolExecutor
> > >>> $Worker.run(ThreadPoolExecutor.java:675)
> > >>> > > > >         at java.lang.Thread.run(Thread.java:613)
> > >>> > > > >
> > >>> > > > > any thoughts?
> > >>> > > > > --
> > >>> > > > > Gregory Kick
> > >>> > > > > http://kickstyle.net/
> > >>> > > > >
> > >>> > > > >
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> > > > > To unsubscribe, e-mail: users-
> > >>> [hidden email]
> > >>> > > > > For additional commands, e-mail: users-
> > >>> [hidden email]
> > >>> > > > >
> > >>> > > > >
> > >>> > > >
> > >>> > > >
> > >>> > > > --
> > >>> > > > Kohsuke Kawaguchi
> > >>> > > >
> > >>> > > >
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> > > > To unsubscribe, e-mail: [hidden email]
> > >>> > > > For additional commands, e-mail: users-
> > >>> [hidden email]
> > >>> > > >
> > >>> > > >
> > >>> > >
> > >>> > >
> > >>> > > --
> > >>> > > Gregory Kick
> > >>> > > http://kickstyle.net/
> > >>> > >
> > >>> > >
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> > > To unsubscribe, e-mail: [hidden email]
> > >>> > > For additional commands, e-mail: [hidden email]
> > >>> > >
> > >>> > >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Kohsuke Kawaguchi
> > >>> >
> > >>> >
> > >>> --------------------------------------------------------------------
> > >>> -
> > >>> > To unsubscribe, e-mail: [hidden email]
> > >>> > For additional commands, e-mail: [hidden email]
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>> --
> > >>> Gregory Kick
> > >>> http://kickstyle.net/
> > >>>
> > >
> > >
> > > --
> > > Kohsuke Kawaguchi
> > > Sun Microsystems                   [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Kohsuke Kawaguchi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Rhett Sutphin
On May 1, 2007, at 11:51 AM, Gregory Kick wrote:

> On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
>> One question, though, is where the tools.jar is. Looking at the file
>> size and all, Classes/classes.jar seems to contain everything, but
>> this file is not directly referenced from anything inside Home.
>> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
>> dt.jar includes classes.jar via Class-Path manifest entry or
>> something?
>
> OS X is kinda funny in that there is no tools.jar.  It's actually
> bundled into one of the other ones (classes.jar I think) so it's
> always on the classpath. How classes.jar gets there I still don't
> understand either...  I checked the manifests and there's nothing
> there.  Any other ideas?

I think that the classes in classes.jar are always available in OS  
X's JRE (it contains all the public API classes, for instance).

At any rate, I've found several references that indicate that the  
content of tools.jar is always available when you use `java` on OS  
X.  Here's one:

http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html

Rhett

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
OK. Got it. Can either of you file an issue for this?

Like everything else, I suspect this has to wait until after JavaOne,
unless someone else can change the code for us.

2007/5/1, Rhett Sutphin <[hidden email]>:

> On May 1, 2007, at 11:51 AM, Gregory Kick wrote:
>
> > On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >> One question, though, is where the tools.jar is. Looking at the file
> >> size and all, Classes/classes.jar seems to contain everything, but
> >> this file is not directly referenced from anything inside Home.
> >> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
> >> dt.jar includes classes.jar via Class-Path manifest entry or
> >> something?
> >
> > OS X is kinda funny in that there is no tools.jar.  It's actually
> > bundled into one of the other ones (classes.jar I think) so it's
> > always on the classpath. How classes.jar gets there I still don't
> > understand either...  I checked the manifests and there's nothing
> > there.  Any other ideas?
>
> I think that the classes in classes.jar are always available in OS
> X's JRE (it contains all the public API classes, for instance).
>
> At any rate, I've found several references that indicate that the
> content of tools.jar is always available when you use `java` on OS
> X.  Here's one:
>
> http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html
>
> Rhett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Augusto Sellhorn
Speaking of Javaone is there any Hudson activity at the conference, either a BOF or a session. Don't remember seeing one when doing my schedule.

On 5/2/07, Kohsuke Kawaguchi <[hidden email]> wrote:
OK. Got it. Can either of you file an issue for this?

Like everything else, I suspect this has to wait until after JavaOne,
unless someone else can change the code for us.

2007/5/1, Rhett Sutphin <[hidden email]>:

> On May 1, 2007, at 11:51 AM, Gregory Kick wrote:
>
> > On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >> One question, though, is where the tools.jar is. Looking at the file
> >> size and all, Classes/classes.jar seems to contain everything, but
> >> this file is not directly referenced from anything inside Home.
> >> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
> >> dt.jar includes classes.jar via Class-Path manifest entry or
> >> something?
> >
> > OS X is kinda funny in that there is no tools.jar.  It's actually
> > bundled into one of the other ones ( classes.jar I think) so it's
> > always on the classpath. How classes.jar gets there I still don't
> > understand either...  I checked the manifests and there's nothing
> > there.  Any other ideas?
>
> I think that the classes in classes.jar are always available in OS
> X's JRE (it contains all the public API classes, for instance).
>
> At any rate, I've found several references that indicate that the
> content of tools.jar is always available when you use `java` on OS
> X.  Here's one:
>
> http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html
>
> Rhett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

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




--
Augusto
http://sellmic.com
Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Kohsuke Kawaguchi
Administrator
See https://hudson.dev.java.net/

Maybe I need to do a better advertizing job. I should probably blog.

2007/5/2, Augusto Sellhorn <[hidden email]>:

> Speaking of Javaone is there any Hudson activity at the conference, either a
> BOF or a session. Don't remember seeing one when doing my schedule.
>
>
> On 5/2/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >
> > OK. Got it. Can either of you file an issue for this?
> >
> > Like everything else, I suspect this has to wait until after JavaOne,
> > unless someone else can change the code for us.
> >
> > 2007/5/1, Rhett Sutphin < [hidden email]>:
> > > On May 1, 2007, at 11:51 AM, Gregory Kick wrote:
> > >
> > > > On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > > >> One question, though, is where the tools.jar is. Looking at the file
> > > >> size and all, Classes/classes.jar seems to contain everything, but
> > > >> this file is not directly referenced from anything inside Home.
> > > >> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
> > > >> dt.jar includes classes.jar via Class-Path manifest entry or
> > > >> something?
> > > >
> > > > OS X is kinda funny in that there is no tools.jar.  It's actually
> > > > bundled into one of the other ones ( classes.jar I think) so it's
> > > > always on the classpath. How classes.jar gets there I still don't
> > > > understand either...  I checked the manifests and there's nothing
> > > > there.  Any other ideas?
> > >
> > > I think that the classes in classes.jar are always available in OS
> > > X's JRE (it contains all the public API classes, for instance).
> > >
> > > At any rate, I've found several references that indicate that the
> > > content of tools.jar is always available when you use `java` on OS
> > > X.  Here's one:
> > >
> > >
> http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html
> > >
> > > Rhett
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Kohsuke Kawaguchi
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> --
> Augusto
> http://sellmic.com


--
Kohsuke Kawaguchi

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

Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Augusto Sellhorn
Whoops, sorry my bad. It's quite clear, just hadn't visited the main page in a bit.

On 5/3/07, Kohsuke Kawaguchi <[hidden email]> wrote:
See https://hudson.dev.java.net/

Maybe I need to do a better advertizing job. I should probably blog.

2007/5/2, Augusto Sellhorn <[hidden email]>:

> Speaking of Javaone is there any Hudson activity at the conference, either a
> BOF or a session. Don't remember seeing one when doing my schedule.
>
>
> On 5/2/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> >
> > OK. Got it. Can either of you file an issue for this?
> >
> > Like everything else, I suspect this has to wait until after JavaOne,
> > unless someone else can change the code for us.
> >
> > 2007/5/1, Rhett Sutphin < [hidden email]>:
> > > On May 1, 2007, at 11:51 AM, Gregory Kick wrote:
> > >
> > > > On 5/1/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > > >> One question, though, is where the tools.jar is. Looking at the file
> > > >> size and all, Classes/classes.jar seems to contain everything, but
> > > >> this file is not directly referenced from anything inside Home.
> > > >> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it. Does
> > > >> dt.jar includes classes.jar via Class-Path manifest entry or
> > > >> something?
> > > >
> > > > OS X is kinda funny in that there is no tools.jar.  It's actually
> > > > bundled into one of the other ones ( classes.jar I think) so it's
> > > > always on the classpath. How classes.jar gets there I still don't
> > > > understand either...  I checked the manifests and there's nothing
> > > > there.  Any other ideas?
> > >
> > > I think that the classes in classes.jar are always available in OS
> > > X's JRE (it contains all the public API classes, for instance).
> > >
> > > At any rate, I've found several references that indicate that the
> > > content of tools.jar is always available when you use `java` on OS
> > > X.  Here's one:
> > >
> > >
> http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html
> > >
> > > Rhett
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> >
> > --
> > Kohsuke Kawaguchi
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> --
> Augusto
> http://sellmic.com


--
Kohsuke Kawaguchi

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




--
Augusto
http://sellmic.com
Reply | Threaded
Open this post in threaded view
|

Re: Reporting as instructed

Gregory Kick-2
logged as issue 533

On 5/3/07, Augusto Sellhorn <[hidden email]> wrote:

> Whoops, sorry my bad. It's quite clear, just hadn't visited the main page in
> a bit.
>
>
> On 5/3/07, Kohsuke Kawaguchi < [hidden email]> wrote:
> > See https://hudson.dev.java.net/
> >
> > Maybe I need to do a better advertizing job. I should probably blog.
> >
> > 2007/5/2, Augusto Sellhorn <[hidden email]>:
> > > Speaking of Javaone is there any Hudson activity at the conference,
> either a
> > > BOF or a session. Don't remember seeing one when doing my schedule.
> > >
> > >
> > > On 5/2/07, Kohsuke Kawaguchi <[hidden email]> wrote:
> > > >
> > > > OK. Got it. Can either of you file an issue for this?
> > > >
> > > > Like everything else, I suspect this has to wait until after JavaOne,
> > > > unless someone else can change the code for us.
> > > >
> > > > 2007/5/1, Rhett Sutphin < [hidden email]>:
> > > > > On May 1, 2007, at 11:51 AM, Gregory Kick wrote:
> > > > >
> > > > > > On 5/1/07, Kohsuke Kawaguchi <[hidden email] > wrote:
> > > > > >> One question, though, is where the tools.jar is. Looking at the
> file
> > > > > >> size and all, Classes/classes.jar seems to contain everything,
> but
> > > > > >> this file is not directly referenced from anything inside Home.
> > > > > >> Home/lib/dt.jar just link back to Classes/dt.jar, but that's it.
> Does
> > > > > >> dt.jar includes classes.jar via Class-Path manifest entry or
> > > > > >> something?
> > > > > >
> > > > > > OS X is kinda funny in that there is no tools.jar.  It's actually
> > > > > > bundled into one of the other ones ( classes.jar I think) so it's
> > > > > > always on the classpath. How classes.jar gets there I still don't
> > > > > > understand either...  I checked the manifests and there's nothing
> > > > > > there.  Any other ideas?
> > > > >
> > > > > I think that the classes in classes.jar are always available in OS
> > > > > X's JRE (it contains all the public API classes, for instance).
> > > > >
> > > > > At any rate, I've found several references that indicate that the
> > > > > content of tools.jar is always available when you use `java` on OS
> > > > > X.  Here's one:
> > > > >
> > > > >
> > >
> http://lists.apple.com/archives/java-dev/2007/Mar/msg00090.html
> > > > >
> > > > > Rhett
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Kohsuke Kawaguchi
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Augusto
> > > http://sellmic.com
> >
> >
> > --
> > Kohsuke Kawaguchi
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
>
> --
> Augusto
> http://sellmic.com


--
Gregory Kick
http://kickstyle.net/

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