On Oct 7, 2008, at 11:17 PM, Adam Murdoch wrote:
Hans Dockter wrote:
On Oct 6, 2008, at 11:32 PM, Adam Murdoch wrote:
Hans Dockter wrote:
On Sep 27, 2008, at 1:34 AM, Adam Murdoch wrote:
So, I'm not sure what to do with this now. I don't really
understand the purpose of executeIsolatedAntScript() so I can't
really suggest (or implement) any solutions yet. I guess that
strictly speaking, the classpath of the isolated ant script
should be as minimal as possible. This means probably just ant
and groovy and nothing else
The Groovyc Ant task (as well as the Groovydoc task) is part of
the groovy distribution. We want to make it possible for Groovy
projects to use a different version of Groovyc and Groovycdoc
then the ones contained in the groovy version shipped with
Gradle. In particular for Groovyc this is very important for
people using some new features of Groovy 1.6. You could not
compile them with Groovyc 1.5.
Do you mean use a different version of groovy for their source,
or for their build files, or both? How do you specify that you
want to use a different version of groovy?
For their sources. See user's guide, beginning of chapter 10.
Sorry, I didn't notice that.
I went without success through the Ant Classloader hell before I
implemented the current solution. It is obviously very handcrafted.
I don't understand how this works. It looks like the isolated ant
script is still going to be picking up groovy from gradle's lib dir.
It is picked up but has no precedence as the loaderClasspath
parameter of the executeIsolatedAntScript method contains the user
defined groovy version and is higher in the classpath. In the case
of a compile this loaderClasspath property gets its content from
the getGroovyClasspath property of GroovyCompile. This again is
assigned in the GroovyPlugin. Obviously this code is confusing.
The groovyproject integration test, tests this behavior.
It certainly is confusing. The confusion for me is in figuring out
the *intent* of what its trying to do. Perhaps some renames would
help.
Another thing that would help would for the classpath to contain
only ant + groovy and nothing else, and have some kind of modelling
so that they are represented as 2 separate file collection objects.
Another option would be to use an extra classloader, a parent one
with the shared libs (ie ant). This would be shared by the main
Gradle classloader, plus the isolated groovy compilation
classloader. Put these behind a registry and I think we've just
started the modularisation work.
This would be my favorite approach. As I understand your proposal,
the registry would return a classloader corresponding to a particular
service, right?
What do you think in general on using OSGi inside Gradle. It looks
like a reasonable lightweight technology. One motivation, beside that
is solves a problem, for me to use it, is that Gradle sooner or later
needs to provide support for OSGi. And then it would be nice to use
this support also internally.
Another option would be run the compilation task in a forked process.
Right. I haven't thought about this one. That would be a simple
solution. We could still pick up the idea of a registry. But in this
case the registry would return the jar files for a particular service.
Can we invoke the groovy compiler and groovydoc tools directly,
rather than as ant tasks? Then we don't need ant in the classpath.
Unfortunately not. Groovy does not provide those as commands. We
could only (like the GMaven plugin) build this functionality by
ourselves (with the help of the Groovy classes used by the Ant task).
I suspect we should do the isolated classloader thing for java
compiles too, as the javac tool uses its (context?) classloader to
find classes which are not supplied on the compile classpath.
This is not necessary. The Ant javac task has an 'includeAntRuntime'
property. If this is true the path of the context classloader is
part of the compile classpath. Surprisingly it defaults to true when
doing an ant build, which is slightly hilarious. I don't know the
historic reasons for this. The Gradle AntJavac class sets this to
false. So we have isolation here.
On a slightly related note, I wonder if we should care about people
wanting to use a version of ant other than the one shipped with
Gradle in their build files? How about a different version of
groovy? Both these things will shake out the modularisation model,
and allowing different versions of groovy will help detangle the
core from the DSL layer.
I don't think it is major use case. But exactly for the reasons you
have given I think that would be worthwhile to implement.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
