On Aug 29, 2007, at 8:58 AM, Jerome Lacoste wrote:
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.
You are right, I jumped on you... sorry.
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.
We all make mistakes, I'm sorry I replied in prick form....
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.getGroovyObjectPrope
rty(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)
Ya, I think Ant 1.7.0 is to blame here really... cause IMO its
Locator.fromURI() really should encode ' ' -> "%20" but it doesn't :-
( Though though I wish that the JDK's URL muck would do that
automatically anyways... blah I hate spaces in URLs :-(
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 ?
Well, you had a point, but you started off by suggesting that the s-m-
p was using the Ant task, which it isn't and I got a little irritated
by the fact that you were basing your statement on something that
was, well, false. Anyways :-P
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.
Probably not a whole lot actually, though sure w/o the Groovy layer
it would be a little faster and leaner, but IMO as a developer of
plugins, I prefer the ease of developing w/Groovy. IMO its a much
more pleasant language for implementing Maven plugins, a whole lot
less verbose than Java, but at the cost of a little extra fat at the
moment... no denying that.
I wish that Groovy had some mode where it would simply spit out .java
and let me compile that w/o the extra magical MOP-muck... but not
sure when/if that will ever happen.
The Groovy team still isn't really set on a direction to make the
main distribution thiner either, so I may eventually setup a diet
version of the jars required to build/use this stuff at some-point to
cut down on more weight.
But, as for the Ant stuff... I dunno, Ant has already got some
really, really, really powerful support for build-related things and
for that reason I still see it in its Groovy AntBuilder-form as very,
very helpful for Maven plugin developers. But ya, its got a lot of
stuff in there these days. I had considered trying to make a helper
builder that internally used Plexus bits for things like copying
files, making directories and so on, which is what I tend to use the
AntBuilder stuff for anyways. But its yet to happen.
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.
No worries, I'm sorry I jumped on you... though I kinda wished you
had done a little more research before you started making
statements... :-\
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.
Eh, I'm really not all that interested to be honest. Maybe once
Maven moves to Java 5 then I may consider implementing more plugins w/
Java instead of Groovy, but right now I most certainly prefer Groovy
for Maven plugin development.
I'm still trying to figure out how to fix this stupid Windows-tickled
bug though, but I think that it will probably end up with the same
result on other operating systems if the repo is located at some path
with spaces.
I may revert the Maven/Groovy stuff to use Ant 1.6.5 until I can sort
that out fully, which I believe should solve the problem for the most
part.
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 ?
I guess I don't know what you mean by this... what is that minimal
integration layer?
--jason
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
