On 8/29/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
> On Aug 28, 2007, at 1:59 PM, Jerome Lacoste wrote:
> > Hei,
> >
> > I have tried to use the latest selenium plugin and I am facing the
> > MSELENIUM-22 issue (selenese goal).
> >
> > This issue exhibits something I feel is dangerous to the maven
> > ecosystem. To use the plugin I have a groovy layer integrating with
> > ant calling the selenese ant task.
>
> Um, no... have you actually looked at the code that is executed by
> the SeleneseMojo? It appears that you have not or else you would
> have not made this statement. And this fact exhibits something that
> I feel is dangerous, when people start to complain about something
> based on misconceptions and then others follow suite like lemmings
> jumping off of a cliff.
>
> So, if you'd like to go investigate this a little more and then
> complain about something related which is based on reality, then I'd
> be happy to provide more constructive comments and feedback.
Jason,
I feel this thread is going on the wrong path and that you're getting
very defensive. I hope to be wrong.
So yes I made a mistake: I pointed to the wrong goal. The problem was
with the start-server one, as indicated correctly in the MSELENIUM-22
issue.
I hadn't looked at the code (at that time), but I looked at the stack trace:
java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:842)
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.apache.tools.ant.launch.Locator.fromURI(Locator.java:162)
[...]
at org.apache.tools.ant.Project.init(Project.java:295)
at
org.codehaus.mojo.groovy.util.AntBuilder.createProject(AntBuilder.java:62)
at org.codehaus.mojo.groovy.util.AntBuilder.<init>(AntBuilder.java:36)
[...]
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.codehaus.groovy.runtime.MetaClassHelper.doConstructorInvoke(MetaClassHelper.java:563)
at
groovy.lang.MetaClassImpl.doConstructorInvoke(MetaClassImpl.java:1864)
[...]
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:158)
at
org.codehaus.mojo.groovy.GroovyMojoSupport.getProperty(GroovyMojoSupport.groovy)
[...]
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getGroovyObjectProperty(ScriptBytecodeAdapter.java:527)
at
org.codehaus.mojo.selenium.StartServerMojo.execute(StartServerMojo.groovy:188)
[...]
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
At runtime we still have maven, selenium mojo, groovy mojo, groovy
script, ant. A lot of reflection and class loading.
You say it yourself in comment to MGROOVY-64:
"I'm still not sure if the bug is in Classworlds, Ant, Groovy, Maven,
Groovy Maven Plugin or the JDK."
So was I so far from reality ?
If it's too hard (than necessary) to debug, then there's maybe a
complexity issue that's worth addressing. Of course fixing this
particular bug will improve the support for writing groovy mojos.
In that particular case, I wonder for example how much difference
there would be in startup time, memory resources, network resources
between this Groovy mojo and the similar Java one.
I don't mean to single you out or anything. I just want to discuss
whether others also think whether this is a valid concern in the
*general* case.
I've had problems in the past in some mojos, and so did Wayne.
So now if you want, I rewrote (most of) the mojos in Java. And it
looks like it works, except I am having some other issues from
selenium itself (bad support of proxy detection for IE...). If you
want the code, I can create a Jira issue and attach it.
But that still doesn't address the initial problem at hand. Should we
aim for minimal integration layer between the mojo and the target
functionality ?
Is that a best practice ? I would say yes. I would love to know what
guys like Brett or Jason think about the issue.
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
