Nabble - gradle-dev

Re: Adding two new features to Gradle

2009-11-26T13:07:46Z

John Murph wrote:

On Mon, Nov 23, 2009 at 4:20 PM, Adam Murdoch <a@...> wrote:

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

LOL, thanks Adam. I was worried about 2 seconds, then realized that there was no way you wanted me to do all that. I think I like the unification of these items, they are obviously very related. What class would have the configure(*) methods? This would need to be available to almost everything. Your unification thoughts almost relegate init/settings/build scripts to different flavors of a single thing. Maybe a common base class for the delegate objects for these scripts? Or maybe composition? I think I prefer composition here, but there are several methods that will need to be delegated. Maybe a "ConfigurableScript" interface to describe the method signatures, a "ScriptExecutor" class that contains the implementation (and implements the "ConfigurableScript" interface). Then each of the appropriate classes can implement the interface and delegate those methods to the class. Seems inelegant, but reasonable.

This is a good plan. Every script that Gradle compiles ends up as a subclass of org.gradle.groovy.scripts.Script, so you could change that to implement ConfigurableScript. This means that the configure(*) methods will be available from every script. Then, you could perhaps just change Project or Gradle to implement ConfigurableScript as well, so that the configure(*) methods are available outside the scripts (eg plugins, java classes, etc).

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Re: Adding two new features to Gradle

2009-11-24T08:21:58Z

On Tue, 2009-11-24 at 09:15 -0600, John Murph wrote:

> Thanks Tomek! My initial research shows that TestNG is much better in
> this respect than JUnit, so I don't think it'll be a problem.
>
First let us remove the extraneous words:

" . . . TestNG is much better . . . than JUnit. . . . "

then let us elide the elisions:

"TestNG is much better than JUnit."

Now as this is a true statement it would be really cool if everyone
thought "How do we do this for TestNG?" and then as a follow up "How do
we do this for JUnit".

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Adding two new features to Gradle

2009-11-24T07:15:21Z

On Tue, Nov 24, 2009 at 12:22 AM, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

Hi John

TestNG definitely support listeners ! See
http://testng.org/doc/documentation-main.html#testng-listeners

Thanks Tomek! My initial research shows that TestNG is much better in this respect than JUnit, so I don't think it'll be a problem.

--
John Murph
Automated Logic Research Team

Re: Adding two new features to Gradle

2009-11-24T07:13:36Z

On Mon, Nov 23, 2009 at 4:20 PM, Adam Murdoch <a@...> wrote:

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

LOL, thanks Adam. I was worried about 2 seconds, then realized that there was no way you wanted me to do all that. I think I like the unification of these items, they are obviously very related. What class would have the configure(*) methods? This would need to be available to almost everything. Your unification thoughts almost relegate init/settings/build scripts to different flavors of a single thing. Maybe a common base class for the delegate objects for these scripts? Or maybe composition? I think I prefer composition here, but there are several methods that will need to be delegated. Maybe a "ConfigurableScript" interface to describe the method signatures, a "ScriptExecutor" class that contains the implementation (and implements the "ConfigurableScript" interface). Then each of the appropriate classes can implement the interface and delegate those methods to the class. Seems inelegant, but reasonable.

--
John Murph
Automated Logic Research Team

Re: Adding two new features to Gradle

2009-11-23T22:22:36Z

Hi John

TestNG definitely support listeners ! See
http://testng.org/doc/documentation-main.html#testng-listeners

thanks

--
Tomek

2009/11/23 John Murph <jmurph.alc@...>:

> On Mon, Nov 23, 2009 at 12:02 AM, Tomek Kaczanowski
> <kaczanowski.tomek@...> wrote:
>>
>> Hi John and all,
>>
>> > First is TestListener. This (if you can recall that far back) was the
>> > reason I did the listener manager changes. We need to have an init
>> > script
>> > that can register a listener that gets testing feedback from JUnit.
>> I read "JUnit", and immediately red light bulb started to blink in my
>> head :) - will it also work for TestNG ?
>>
>> --
>> Tomek
>>
>
> Hi Tomek,
>
> I am not very familiar with TestNG, but I would assume that it has support
> for listeners. If so, it would be reasonable to make it work for that as
> well. I will get JUnit working first, then we can see how difficult TestNG
> might be (I doubt it'll be hard).
>
> Is that a good enough non-answer for you? :)
>
>
> --
> John Murph
> Automated Logic Research Team
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding two new features to Gradle

2009-11-23T14:20:50Z

Adam Murdoch wrote:

John Murph wrote:
On Fri, Nov 20, 2009 at 3:53 PM, Adam Murdoch <a@...> wrote:

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task, so that the events are available just below the surface of the NativeTest task. We'd need to add some methods for adding a TestListener to NativeTest, with an impl of that used a ListenerManager to create its broadcaster. Then, the TestListener events would be available in the init script.

I don't think we should bother with trying to fit this into the AntTest task as well, and should instead focus on getting the NativeTest stuff ready.

OK, I'll have a look at the NativeTest stuff and see what I can figure out. This is the change that is most pressing for us as we currently don't have a workaround, so hopefully I can figure something out.

If you need something really soon, it might be better to try this with AntTest. Will be a little while before we make NativeTest the official test task. It's up to you. We can figure a way to merge the two implementations if you decide to go with AntTest.

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

Why do you need to do the configuration using external scripts? What do they configure? I want to get a feel for the use case before we discuss a solution.

We showed and explained this to Hans when he was here. It's a bit difficult to explain in an email, but let me try. We have the concept of multiple modules being put together to form products, and multiple products forming installs and multiple installs forming distributions. Each of these three levels (products, install, dists) have logic and therefore need configuration of that logic. For example, what modules does this product need? What is the name of the product? What native launchers does the product need, and what are it's settings (Xmx, etc.)? Similarly, installs and distributions have configurations as well.

To support this, we have three domain objects in our buildSrc that hold this information. We also have various "xxx_product.gradle" and "xxx_install.gradle" and "xxx_dist.gradle" files in our project that are used depending on what is being built. These special .gradle files are executed on the associated domain object by our settings.gradle. This allows our developers to only say what's important to them, and not have to see our giant build.gradle scripts (or our buildSrc module). What our developers actually think is Gradle is all these special scripts, they never see "true" Gradle.

The thing is that I want these special Gradle files to be very similar in treatment to normal Gradle files. All I'm really doing is extending the concepts that Gradle knows about into my own custom domain. (This ability is at the heart of what we love so much about Gradle.) Unfortunately, to do this right now I had to copy-paste some Gradle implementation code into our buildSrc (the stuff than runs a script, knows when/where to cache it, knows when to ignore the cache and rebuild it, knows how to "delegate" to an object, etc.) Every time you guys touch that stuff it breaks us, because we are using internal APIs of Gradle. The idea of this feature is to make an easy to use public API so that we don't get broken so much. It will also make it easier for others to do this same thing.

As a matter of fact, we've talked to Hans about our idea that large projects should generally be structured this way. I don't want to go into details right now (I intended to write up something more complete eventually), but most large projects have lots of concepts centered around what they are doing and the way they work. Formalizing those concepts into "extensions" to Gradle can product a much easier to use build engine that is designed for them. It's why I've always agreed that Gradle should be a toolkit. One that works out-of-the-box for simple projects, and one that lets large projects implement their own custom build engine on top of it. Part of the power of Gradle is that it can be both.

Thanks for writing this up. I agree 100% with you on the goal. I think this is an excellent pattern for large builds, where the 'build scripts' describe what to build in some high-level build language (custom or otherwise), and some build logic in the root script/buildSrc/some plugin takes care of how to build those things.

I have a different suggestion for how we solve this problem. To me, it feels like we want some unified theory of build logic composition. That is, these all feel like the same thing:

Things we do now:
- configure a Project using a plugin
- configure a Project using a build script
- configure a Gradle instance using an init script
- configure a Settings instance using a settings script

Things we want to be able to do:
- implement a plugin using a script
- configure a Project using an arbitrary script
- configure a Gradle instance using a plugin
- configure a SourceSet/Configuration/RepositoryContainer/etc using a plugin/extension
- configure an arbitrary domain object using an arbitrary script
- auto-configure a Project using scripts or plugins or java source in a well-know location (such as buildSrc)
- ...

So, I think we could get rid of Project.usePlugin(), and replace it with a general method. Let's call it 'configure' for now. In any script you would be able to do:

configure(object) { a closure }
- this is a generalisation of Project.configure(), available from any script

configure(object, 'path/to/a/script.gradle')
- executes the given script with the given object as its delegate

configure(object, SomePluginClass)
- configures the given object using the given plugin, i.e. a generalisation of Project.usePlugin()

The target object would default to the delegate of the current script, ie in a build script the target object is a Project:

configure('path/to/a/script.gradle')
configure(SomePluginClass)

We could also add some additional ways to locate the build logic artifact:

configure(object, 'path/to/a/plugin.jar')
- locates the plugin(s) in the provided jar and applies them to the given object

configure(object, 'http://some.corporate.server/global-config.gradle')
- uses the artifact (script or jar) from the given url

configure(object, 'path/to/some/directory')
- treats the directory as a Gradle project which produces a plugin jar, ie exactly the same as buildSrc

configure(object) {
dependency 'some.org:sharedConfig:1.4+'
}
- uses the artifacts (scripts or jars) from the given dependency.

Then, our existing behaviours can be implemented in terms of configure()

- init script -> configure(gradle, initScriptPath)
- settings script -> configure(settings, settingsScriptPath)
- build script -> configure(project, buildScriptPath)
- buildSrc -> configure(gradle, "$rootDir/buildSrc")
- usePlugin('name') -> configure(project, getClassForName('name'))
- usePlugin(pluginClass) -> configure(project, pluginClass)

BTW, I'm not suggesting you do all this work, as you really only need the equivalent of configure(object, scriptPath). I'm just trying to figure out a direction for this stuff.

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Re: Re: detecting if usePlugin "xyz" for a project

2009-11-23T14:18:25Z

Philip Crotwell wrote:

> Hi
>
> Just realized that the problem was that the code was running in the
> plugin init instead of the task execution so the project was not be
> completely set up at that point. I had the usePlugin "eclipse" before
> the usePlugin "scala" in the build file, so the order was backwards.
>
> So, I guess it almost works. However, because the eclipse plugin seems
> to do its checking at init time instead of task execution time, it can
> fail to properly detect the scala plugin if usePlugin "eclipse" comes
> before usePlugin "scala".

The eclipse plugins uses this kind of construct to detect whether the
java plugin has been applied:

public void use(final Project project, ProjectPluginsContainer
projectPluginsHandler) {

projectPluginsHandler.withType(JavaPlugin.class).allPlugins {...
some action ... }

}

The action passed to allPlugins() is invoked when the JavaPlugin is
applied, whether that has already happened, or whether it happens at
some point in the future.

You should do a similar thing to detect whether the scala plugin has
been applied.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding two new features to Gradle

2009-11-23T14:17:42Z

On Mon, Nov 23, 2009 at 12:02 AM, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

Hi John and all,

> First is TestListener. This (if you can recall that far back) was the
> reason I did the listener manager changes. We need to have an init script
> that can register a listener that gets testing feedback from JUnit.

I read "JUnit", and immediately red light bulb started to blink in my
head :) - will it also work for TestNG ?

--
Tomek

Hi Tomek,

I am not very familiar with TestNG, but I would assume that it has support for listeners. If so, it would be reasonable to make it work for that as well. I will get JUnit working first, then we can see how difficult TestNG might be (I doubt it'll be hard).

Is that a good enough non-answer for you? :)

--
John Murph
Automated Logic Research Team

Re: eclipse classes in gradle-core and gradle-plugins

2009-11-23T14:14:30Z

Philip Crotwell wrote:
> Hi
>
> Is there a reason that EclipseProject is in gradle-core instead of
> gradle-plugins?

We're halfway through splitting up gradle-core, and there's still some
stuff left in gradle-core which belongs in gradle-plugins.

> This means that EclipseProject can't refer to
> EclipsePlugin due to the compile order of the subprojects.
>

Generally, our tasks don't refer to the plugins. The dependency usually
goes the other way. So, it shouldn't matter that EclipseProject is in
gradle-core.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

eclipse classes in gradle-core and gradle-plugins

2009-11-23T13:49:47Z

Hi

Is there a reason that EclipseProject is in gradle-core instead of
gradle-plugins? This means that EclipseProject can't refer to
EclipsePlugin due to the compile order of the subprojects.
EclipseProject is, as far as I can tell, only used in EclipsePlugin,
so it would seem like it would be better in the plugin than core, or
is there a larger plan to make ide integration that would require
being in core? This relates to my trying to get the eclipse plugin to
correctly generate eclipse .project files for scala.

thanks,
Philip

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: detecting if usePlugin "xyz" for a project

2009-11-23T13:34:57Z

Hi

Just realized that the problem was that the code was running in the
plugin init instead of the task execution so the project was not be
completely set up at that point. I had the usePlugin "eclipse" before
the usePlugin "scala" in the build file, so the order was backwards.

So, I guess it almost works. However, because the eclipse plugin seems
to do its checking at init time instead of task execution time, it can
fail to properly detect the scala plugin if usePlugin "eclipse" comes
before usePlugin "scala". Presumably the scala plugin detection needs
to move from the initialization to the task execution, I suppose
effectively moving the setProjectType from configureEclipseProject()
in EclipsePlugin to generateProject in EclipseProject?

thanks
Philip

On Mon, Nov 23, 2009 at 1:56 PM, Philip Crotwell <crotwell@...> wrote:

> Hi
>
> Is there a way to tell if a project uses a plugin?
>
> I tried
> project.getPlugins().hasPlugin(ScalaPlugin.class)
> but get always get false regardless. It is false even if I am inside
> the executing ecplise plugin and do a hasPlugin(EclipsePlugin.class).
>
> Perhaps a related question, why is the plugin container passed as an
> arg to Plugin.use() if it is accessuble via Project.getPlugins()? The
> second argument seems redundant, unless the Project.getPlugins() is
> not functional.
> void use(Project project,
> ProjectPluginsContainer projectPluginsHandler)
>
> My goal is to modify the EclipsePlugin in order to add the "scala
> nature" to eclipse projects if usePlugin "scala" is in the build file.
> Attached is a patch that shows what I have tried (along with some
> printlns), but this doesn't work as the hasPlugin returns false.
>
> I have created a issue for this and will upload my patch if/when I
> figure out the hasPlugin issue.
> http://jira.codehaus.org/browse/GRADLE-751
>
> Gradle 0.9-20091123133702-0500
>
> thanks,
> Philip
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

detecting if usePlugin "xyz" for a project

2009-11-23T10:56:25Z

Hi

Is there a way to tell if a project uses a plugin?

I tried
project.getPlugins().hasPlugin(ScalaPlugin.class)
but get always get false regardless. It is false even if I am inside
the executing ecplise plugin and do a hasPlugin(EclipsePlugin.class).

Perhaps a related question, why is the plugin container passed as an
arg to Plugin.use() if it is accessuble via Project.getPlugins()? The
second argument seems redundant, unless the Project.getPlugins() is
not functional.
void use(Project project,
ProjectPluginsContainer projectPluginsHandler)

My goal is to modify the EclipsePlugin in order to add the "scala
nature" to eclipse projects if usePlugin "scala" is in the build file.
Attached is a patch that shows what I have tried (along with some
printlns), but this doesn't work as the hasPlugin returns false.

I have created a issue for this and will upload my patch if/when I
figure out the hasPlugin issue.
http://jira.codehaus.org/browse/GRADLE-751

Gradle 0.9-20091123133702-0500

thanks,
Philip

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

scala-eclipse.patch (3K) Download Attachment

Re: Gradle Repository

2009-11-23T08:38:44Z

On Sun, Nov 22, 2009 at 19:15, Hans Dockter <mail@...> wrote:

> Hi,
>
> at the moment the Gradle build has only first level dependencies. We introduced this a while ago because there were some issues with multi-project builds and module dependencies. As module-dependencies have still issues with being published and having flat dependencies being pretty inconvenient, I'd like to switch to a standard repository based approach for dealing with transitive dependencies.
>
> Artifactory is offering free hosting for open source projects. So we would have a nice repository manage for managing our module descriptors.
>
> Thoughts?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

I've used artifactory in the past, it's a pretty decent repo manager. Nexus looks really nice, but I'm not sure what Sonatype does for hosting (or how close you'd want to get to them ;) )

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

signature.asc (285 bytes) Download Attachment

Re: Some archive stuff

2009-11-22T22:08:49Z

Hans Dockter wrote:

There are some issues left with our very nice new archive handling.

usePlugin('base')

task topLevelInclude(type: Zip) {
   baseName = "topLevelInclude"
   include "foo"
}

task inheritInto(type: Zip) {
   baseName = "inheritInfo"
   into "bar"
   from('foo')
}

- The topLevelInclude zip is empty. I would expect it to include foo.

Does that mean that the following should create a Zip containing the entire project directory?

task someZip(type: Zip) {
}

Perhaps instead it should be an error to use include or exclude when no source has been specified.

- The inheritInto zip has foo as a first level file. I would expect it to be in bar/foo.

I'll fix that.

I have attached a zip with the test project.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Re: Adding two new features to Gradle

2009-11-22T22:02:27Z

Hi John and all,

> First is TestListener. This (if you can recall that far back) was the
> reason I did the listener manager changes. We need to have an init script
> that can register a listener that gets testing feedback from JUnit.
I read "JUnit", and immediately red light bulb started to blink in my
head :) - will it also work for TestNG ?

--
Tomek

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding two new features to Gradle

2009-11-22T21:59:30Z

John Murph wrote:

On Fri, Nov 20, 2009 at 3:53 PM, Adam Murdoch <a@...> wrote:

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task, so that the events are available just below the surface of the NativeTest task. We'd need to add some methods for adding a TestListener to NativeTest, with an impl of that used a ListenerManager to create its broadcaster. Then, the TestListener events would be available in the init script.

I don't think we should bother with trying to fit this into the AntTest task as well, and should instead focus on getting the NativeTest stuff ready.

OK, I'll have a look at the NativeTest stuff and see what I can figure out. This is the change that is most pressing for us as we currently don't have a workaround, so hopefully I can figure something out.

If you need something really soon, it might be better to try this with AntTest. Will be a little while before we make NativeTest the official test task. It's up to you. We can figure a way to merge the two implementations if you decide to go with AntTest.

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

Why do you need to do the configuration using external scripts? What do they configure? I want to get a feel for the use case before we discuss a solution.

We showed and explained this to Hans when he was here. It's a bit difficult to explain in an email, but let me try. We have the concept of multiple modules being put together to form products, and multiple products forming installs and multiple installs forming distributions. Each of these three levels (products, install, dists) have logic and therefore need configuration of that logic. For example, what modules does this product need? What is the name of the product? What native launchers does the product need, and what are it's settings (Xmx, etc.)? Similarly, installs and distributions have configurations as well.

To support this, we have three domain objects in our buildSrc that hold this information. We also have various "xxx_product.gradle" and "xxx_install.gradle" and "xxx_dist.gradle" files in our project that are used depending on what is being built. These special .gradle files are executed on the associated domain object by our settings.gradle. This allows our developers to only say what's important to them, and not have to see our giant build.gradle scripts (or our buildSrc module). What our developers actually think is Gradle is all these special scripts, they never see "true" Gradle.

The thing is that I want these special Gradle files to be very similar in treatment to normal Gradle files. All I'm really doing is extending the concepts that Gradle knows about into my own custom domain. (This ability is at the heart of what we love so much about Gradle.) Unfortunately, to do this right now I had to copy-paste some Gradle implementation code into our buildSrc (the stuff than runs a script, knows when/where to cache it, knows when to ignore the cache and rebuild it, knows how to "delegate" to an object, etc.) Every time you guys touch that stuff it breaks us, because we are using internal APIs of Gradle. The idea of this feature is to make an easy to use public API so that we don't get broken so much. It will also make it easier for others to do this same thing.

As a matter of fact, we've talked to Hans about our idea that large projects should generally be structured this way. I don't want to go into details right now (I intended to write up something more complete eventually), but most large projects have lots of concepts centered around what they are doing and the way they work. Formalizing those concepts into "extensions" to Gradle can product a much easier to use build engine that is designed for them. It's why I've always agreed that Gradle should be a toolkit. One that works out-of-the-box for simple projects, and one that lets large projects implement their own custom build engine on top of it. Part of the power of Gradle is that it can be both.

Thanks for writing this up. I agree 100% with you on the goal. I think this is an excellent pattern for large builds, where the 'build scripts' describe what to build in some high-level build language (custom or otherwise), and some build logic in the root script/buildSrc/some plugin takes care of how to build those things.

I have a different suggestion for how we solve this problem. To me, it feels like we want some unified theory of build logic composition. That is, these all feel like the same thing:

Things we do now:
- configure a Project using a plugin
- configure a Project using a build script
- configure a Gradle instance using an init script
- configure a Settings instance using a settings script

Things we want to be able to do:
- implement a plugin using a script
- configure a Project using an arbitrary script
- configure a Gradle instance using a plugin
- configure a SourceSet/Configuration/RepositoryContainer/etc using a plugin/extension
- configure an arbitrary domain object using an arbitrary script
- auto-configure a Project using scripts or plugins or java source in a well-know location (such as buildSrc)
- ...

So, I think we could get rid of Project.usePlugin(), and replace it with a general method. Let's call it 'configure' for now. In any script you would be able to do:

configure(object) { a closure }
- this is a generalisation of Project.configure(), available from any script

configure(object, 'path/to/a/script.gradle')
- executes the given script with the given object as its delegate

configure(object, SomePluginClass)
- configures the given object using the given plugin, i.e. a generalisation of Project.usePlugin()

The target object would default to the delegate of the current script, ie in a build script the target object is a Project:

configure('path/to/a/script.gradle')
configure(SomePluginClass)

We could also add some additional ways to locate the build logic artifact:

configure(object, 'path/to/a/plugin.jar')
- locates the plugin(s) in the provided jar and applies them to the given object

configure(object, 'http://some.corporate.server/global-config.gradle')
- uses the artifact (script or jar) from the given url

configure(object, 'path/to/some/directory')
- treats the directory as a Gradle project which produces a plugin jar, ie exactly the same as buildSrc

configure(object) {
dependency 'some.org:sharedConfig:1.4+'
}
- uses the artifacts (scripts or jars) from the given dependency.

Then, our existing behaviours can be implemented in terms of configure()

- init script -> configure(gradle, initScriptPath)
- settings script -> configure(settings, settingsScriptPath)
- build script -> configure(project, buildScriptPath)
- buildSrc -> configure(gradle, "$rootDir/buildSrc")
- usePlugin('name') -> configure(project, getClassForName('name'))
- usePlugin(pluginClass) -> configure(project, pluginClass)

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Gradle Repository

2009-11-22T18:15:30Z

Hi,

at the moment the Gradle build has only first level dependencies. We introduced this a while ago because there were some issues with multi-project builds and module dependencies. As module-dependencies have still issues with being published and having flat dependencies being pretty inconvenient, I'd like to switch to a standard repository based approach for dealing with transitive dependencies.

Artifactory is offering free hosting for open source projects. So we would have a nice repository manage for managing our module descriptors.

Thoughts?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding two new features to Gradle

2009-11-22T15:28:29Z

On Sun, Nov 22, 2009 at 7:24 AM, Tom Eyckmans <teyckmans@...> wrote:

I'm currently working in this area (reporting / listeners) of the native test stuff, I have added a basic to console report based on the events the test execution provides. The next step would be to have the reports as a realy listener and add the listener infrastructure. One thing we need to keep in mind is that the execution is really parallel and the CI listeners are probably expecting serial invocation, so we have to foresee this. If you'd like we can have a skype-session about this.

I'm gonna have to get my head around what I want/need before I could talk about it with any clarity. I might be able to talk next week (23 through 27) while on vacation, or I might have to wait until the following week. I'll ping you when/if I'm ready to talk about it. Thanks for the offer!

--
John Murph
Automated Logic Research Team

exec handle - shutdown hook action stuff

2009-11-22T14:47:32Z

Hi all,

Just wanted to let you all know that I've added a general purpose shutdown hook.

You can add/remove actions that need to be performed when the Gradle processes is canceled by using the org.gradle.util.shutdown.ShutdownHookActionRegister class.

Currently only the DefaultExecHandle class uses this, when you call start on an exec handle now a shutdown hook action is registered to cancel the external process when the Gradle process is canceled. When the external process fails or finishes the shutdown hook action is removed from the register.

This way we clean up nicely when we start external processes by using the exec handle classes.

Kr,

Tom

Re: Adding two new features to Gradle

2009-11-22T04:24:33Z

2009/11/20 Adam Murdoch <a@...>

John Murph wrote:

Hans and Adam (and anyone else who might care),

I'm about to start hacking at Gradle again.

Excellent.

I've got two tasks on my list. I wanted to let both of you know that I'm working on these and see if you had any ideas or concerns before I get to far into it. I hope to work on these next week while I'm on Thanksgiving vacation (I have no idea how much I'll actually get done...).

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task, so that the events are available just below the surface of the NativeTest task. We'd need to add some methods for adding a TestListener to NativeTest, with an impl of that used a ListenerManager to create its broadcaster. Then, the TestListener events would be available in the init script.

I don't think we should bother with trying to fit this into the AntTest task as well, and should instead focus on getting the NativeTest stuff ready.

I'm currently working in this area (reporting / listeners) of the native test stuff, I have added a basic to console report based on the events the test execution provides. The next step would be to have the reports as a realy listener and add the listener infrastructure. One thing we need to keep in mind is that the execution is really parallel and the CI listeners are probably expecting serial invocation, so we have to foresee this. If you'd like we can have a skype-session about this.

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

Why do you need to do the configuration using external scripts? What do they configure? I want to get a feel for the use case before we discuss a solution.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Adding two new features to Gradle

2009-11-20T13:20:43Z

On Fri, Nov 20, 2009 at 3:53 PM, Adam Murdoch <a@...> wrote:

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task, so that the events are available just below the surface of the NativeTest task. We'd need to add some methods for adding a TestListener to NativeTest, with an impl of that used a ListenerManager to create its broadcaster. Then, the TestListener events would be available in the init script.

I don't think we should bother with trying to fit this into the AntTest task as well, and should instead focus on getting the NativeTest stuff ready.

OK, I'll have a look at the NativeTest stuff and see what I can figure out. This is the change that is most pressing for us as we currently don't have a workaround, so hopefully I can figure something out.

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

Why do you need to do the configuration using external scripts? What do they configure? I want to get a feel for the use case before we discuss a solution.

We showed and explained this to Hans when he was here. It's a bit difficult to explain in an email, but let me try. We have the concept of multiple modules being put together to form products, and multiple products forming installs and multiple installs forming distributions. Each of these three levels (products, install, dists) have logic and therefore need configuration of that logic. For example, what modules does this product need? What is the name of the product? What native launchers does the product need, and what are it's settings (Xmx, etc.)? Similarly, installs and distributions have configurations as well.

To support this, we have three domain objects in our buildSrc that hold this information. We also have various "xxx_product.gradle" and "xxx_install.gradle" and "xxx_dist.gradle" files in our project that are used depending on what is being built. These special .gradle files are executed on the associated domain object by our settings.gradle. This allows our developers to only say what's important to them, and not have to see our giant build.gradle scripts (or our buildSrc module). What our developers actually think is Gradle is all these special scripts, they never see "true" Gradle.

The thing is that I want these special Gradle files to be very similar in treatment to normal Gradle files. All I'm really doing is extending the concepts that Gradle knows about into my own custom domain. (This ability is at the heart of what we love so much about Gradle.) Unfortunately, to do this right now I had to copy-paste some Gradle implementation code into our buildSrc (the stuff than runs a script, knows when/where to cache it, knows when to ignore the cache and rebuild it, knows how to "delegate" to an object, etc.) Every time you guys touch that stuff it breaks us, because we are using internal APIs of Gradle. The idea of this feature is to make an easy to use public API so that we don't get broken so much. It will also make it easier for others to do this same thing.

As a matter of fact, we've talked to Hans about our idea that large projects should generally be structured this way. I don't want to go into details right now (I intended to write up something more complete eventually), but most large projects have lots of concepts centered around what they are doing and the way they work. Formalizing those concepts into "extensions" to Gradle can product a much easier to use build engine that is designed for them. It's why I've always agreed that Gradle should be a toolkit. One that works out-of-the-box for simple projects, and one that lets large projects implement their own custom build engine on top of it. Part of the power of Gradle is that it can be both.

--
John Murph
Automated Logic Research Team

Re: Adding two new features to Gradle

2009-11-20T12:53:09Z

John Murph wrote:
> Hans and Adam (and anyone else who might care),
>
> I'm about to start hacking at Gradle again.

Excellent.

> I've got two tasks on my list. I wanted to let both of you know
> that I'm working on these and see if you had any ideas or concerns
> before I get to far into it. I hope to work on these next week while
> I'm on Thanksgiving vacation (I have no idea how much I'll actually
> get done...).
>
> First is TestListener. This (if you can recall that far back) was the
> reason I did the listener manager changes. We need to have an init
> script that can register a listener that gets testing feedback from
> JUnit. This will allow us to improve our Gradle TeamCity runner so
> that it gets better (and real time) test results. I'm thinking along
> the lines of "if a listener of a certain type is registered with the
> listener manager, then give a remoting listener to JUnit that sends
> messages to an in-process peer that forwards the messages on to the
> registered listener." Do that make sense?

This would be nice to have.

I suspect most of the work has been done already in the NativeTest task,
so that the events are available just below the surface of the
NativeTest task. We'd need to add some methods for adding a TestListener
to NativeTest, with an impl of that used a ListenerManager to create its
broadcaster. Then, the TestListener events would be available in the
init script.

I don't think we should bother with trying to fit this into the AntTest
task as well, and should instead focus on getting the NativeTest stuff
ready.

>
> Second is extension support. This is the idea that a script can ask
> for some external script to be executed against a given delegate
> object. Doing this through Gradle would allow for all the normal
> caching stuff to be reused. We need to be able to run such scripts
> from the settings.gradle (and from inside build scripts, but that is
> obvious). We would use this feature to define our own custom domain
> objects that are configured via external script files. I'm not sure
> what the interface to Gradle should be, a method on Gradle called
> "executeExtension" that takes a file and a delegate object? Or maybe
> a "getExtensionSupport" method that returns an ExtensionSupport class
> that provides an execute method? What stateful information could
> ExtensionSupport have that justifies a separate class? Or maybe the
> justification is that it provides more than one method, like what?
> I'm not sure what you guys might be thinking about this feature as we
> have not discussed it much before.
>

Why do you need to do the configuration using external scripts? What do
they configure? I want to get a feel for the use case before we discuss
a solution.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Adding two new features to Gradle

2009-11-20T12:22:42Z

Hans and Adam (and anyone else who might care),

I'm about to start hacking at Gradle again. I've got two tasks on my list. I wanted to let both of you know that I'm working on these and see if you had any ideas or concerns before I get to far into it. I hope to work on these next week while I'm on Thanksgiving vacation (I have no idea how much I'll actually get done...).

First is TestListener. This (if you can recall that far back) was the reason I did the listener manager changes. We need to have an init script that can register a listener that gets testing feedback from JUnit. This will allow us to improve our Gradle TeamCity runner so that it gets better (and real time) test results. I'm thinking along the lines of "if a listener of a certain type is registered with the listener manager, then give a remoting listener to JUnit that sends messages to an in-process peer that forwards the messages on to the registered listener." Do that make sense?

Second is extension support. This is the idea that a script can ask for some external script to be executed against a given delegate object. Doing this through Gradle would allow for all the normal caching stuff to be reused. We need to be able to run such scripts from the settings.gradle (and from inside build scripts, but that is obvious). We would use this feature to define our own custom domain objects that are configured via external script files. I'm not sure what the interface to Gradle should be, a method on Gradle called "executeExtension" that takes a file and a delegate object? Or maybe a "getExtensionSupport" method that returns an ExtensionSupport class that provides an execute method? What stateful information could ExtensionSupport have that justifies a separate class? Or maybe the justification is that it provides more than one method, like what? I'm not sure what you guys might be thinking about this feature as we have not discussed it much before.

--
John Murph
Automated Logic Research Team

Re: performance

2009-11-20T12:09:26Z

Steve Appling wrote:
> I'll send a snapshot to both of you off of the list. It looks to me like
> 40% of the time is spent in
> o.g.a.i.changedetection.CachingHasher.hash. That's why I was thinking
> it was the up to date checks. How about an option to make this just
> based on timestamp and length instead of hashing the contents?

It should calculate a hash only when timestamp or length changes. Of
course, it may be broken ...

>
> Adam Murdoch wrote:
>>
>>
>> Steve Appling wrote:
>>> After Hans' dependency resolution performance fix, the huge
>>> performance problem we saw has been fixed (thanks Hans!). I still
>>> find, however, that the overhead of all the up to date checking is
>>> not worth it. When everything is up to date and there is nothing to
>>> do, running "build -xtest" for our big project in the 0.8 version
>>> takes about 1:11 (min:sec) and doing the same thing with the current
>>> trunk version takes 1:24.
>>>
>>> Is there a way to disable the up to date checks for particular
>>> tasks? I don't think it is currently useful for compileJava or Copy
>>> type of tasks and would like to try disabling it there.
>>>
>>
>> How about we make the checking faster, instead? The new stuff has not
>> been heavily profiled or optimised. I was hoping to get back into
>> making this faster next week. I'm pretty confident we can get close
>> for 'build -x test'. Of course, plain 'build' should already be faster.
>>
>> Of course, your numbers don't really say anything more than something
>> is slower in trunk. It could be anything, so let's measure before we
>> optimise. Any chance you could send me a profiling snapshot of the
>> above build. Or if not, I can add some logging and we can see where
>> the time is being taken.
>>
>

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: performance

2009-11-20T11:58:01Z

I'll send a snapshot to both of you off of the list. It looks to me like
40% of the time is spent in o.g.a.i.changedetection.CachingHasher.hash. That's
why I was thinking it was the up to date checks. How about an option to make
this just based on timestamp and length instead of hashing the contents?

Adam Murdoch wrote:

>
>
> Steve Appling wrote:
>> After Hans' dependency resolution performance fix, the huge
>> performance problem we saw has been fixed (thanks Hans!). I still
>> find, however, that the overhead of all the up to date checking is not
>> worth it. When everything is up to date and there is nothing to do,
>> running "build -xtest" for our big project in the 0.8 version takes
>> about 1:11 (min:sec) and doing the same thing with the current trunk
>> version takes 1:24.
>>
>> Is there a way to disable the up to date checks for particular tasks?
>> I don't think it is currently useful for compileJava or Copy type of
>> tasks and would like to try disabling it there.
>>
>
> How about we make the checking faster, instead? The new stuff has not
> been heavily profiled or optimised. I was hoping to get back into making
> this faster next week. I'm pretty confident we can get close for 'build
> -x test'. Of course, plain 'build' should already be faster.
>
> Of course, your numbers don't really say anything more than something is
> slower in trunk. It could be anything, so let's measure before we
> optimise. Any chance you could send me a profiling snapshot of the above
> build. Or if not, I can add some logging and we can see where the time
> is being taken.
>

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: performance

2009-11-20T11:57:03Z

On Nov 20, 2009, at 8:47 PM, Steve Appling wrote:

> Do you want another profile snapshot from us now that your fix has been applied? If so, is sampling ok?

As Adam said, that would be good to have. Sampling would be OK I think.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

>
> Hans Dockter wrote:
>> On Nov 20, 2009, at 8:05 PM, Steve Appling wrote:
>>> After Hans' dependency resolution performance fix, the huge performance problem we saw has been fixed (thanks Hans!). I still find, however, that the overhead of all the up to date checking is not worth it. When everything is up to date and there is nothing to do, running "build -xtest" for our big project in the 0.8 version takes about 1:11 (min:sec) and doing the same thing with the current trunk version takes 1:24.
>> In my test project I had the following profiling results. For a build were nothing needed to be done, 40 percent of the time consumed Ivy for coming up with the dependencies. The state change checking needs the classpath to do comparisons. 10 percent of the time was consumed by our Ivy result translation (we might be able to improve this). This test project did not have many source files. It will be interesting to see whether with a larger codebase source change detection will play an important role here. - Hans
>> --
>> Hans Dockter
>> Gradle Project Manager
>> http://www.gradle.org
>>> Is there a way to disable the up to date checks for particular tasks? I don't think it is currently useful for compileJava or Copy type of tasks and would like to try disabling it there.
>>> --
>>> Steve Appling
>>> Automated Logic Research Team
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>> http://xircles.codehaus.org/manage_email
>
> --
> Steve Appling
> Automated Logic Research Team
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: performance

2009-11-20T11:49:26Z

Steve Appling wrote:

> After Hans' dependency resolution performance fix, the huge
> performance problem we saw has been fixed (thanks Hans!). I still
> find, however, that the overhead of all the up to date checking is not
> worth it. When everything is up to date and there is nothing to do,
> running "build -xtest" for our big project in the 0.8 version takes
> about 1:11 (min:sec) and doing the same thing with the current trunk
> version takes 1:24.
>
> Is there a way to disable the up to date checks for particular tasks?
> I don't think it is currently useful for compileJava or Copy type of
> tasks and would like to try disabling it there.
>

How about we make the checking faster, instead? The new stuff has not
been heavily profiled or optimised. I was hoping to get back into making
this faster next week. I'm pretty confident we can get close for 'build
-x test'. Of course, plain 'build' should already be faster.

Of course, your numbers don't really say anything more than something is
slower in trunk. It could be anything, so let's measure before we
optimise. Any chance you could send me a profiling snapshot of the above
build. Or if not, I can add some logging and we can see where the time
is being taken.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: performance

2009-11-20T11:47:05Z

Do you want another profile snapshot from us now that your fix has been applied?
If so, is sampling ok?

Hans Dockter wrote:

> On Nov 20, 2009, at 8:05 PM, Steve Appling wrote:
>
>> After Hans' dependency resolution performance fix, the huge performance problem we saw has been fixed (thanks Hans!). I still find, however, that the overhead of all the up to date checking is not worth it. When everything is up to date and there is nothing to do, running "build -xtest" for our big project in the 0.8 version takes about 1:11 (min:sec) and doing the same thing with the current trunk version takes 1:24.
>
> In my test project I had the following profiling results. For a build were nothing needed to be done, 40 percent of the time consumed Ivy for coming up with the dependencies. The state change checking needs the classpath to do comparisons. 10 percent of the time was consumed by our Ivy result translation (we might be able to improve this). This test project did not have many source files. It will be interesting to see whether with a larger codebase source change detection will play an important role here.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>> Is there a way to disable the up to date checks for particular tasks? I don't think it is currently useful for compileJava or Copy type of tasks and would like to try disabling it there.
>
>
>> --
>> Steve Appling
>> Automated Logic Research Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

Re: performance

2009-11-20T11:44:14Z

On Nov 20, 2009, at 8:05 PM, Steve Appling wrote:

> After Hans' dependency resolution performance fix, the huge performance problem we saw has been fixed (thanks Hans!). I still find, however, that the overhead of all the up to date checking is not worth it. When everything is up to date and there is nothing to do, running "build -xtest" for our big project in the 0.8 version takes about 1:11 (min:sec) and doing the same thing with the current trunk version takes 1:24.

In my test project I had the following profiling results. For a build were nothing needed to be done, 40 percent of the time consumed Ivy for coming up with the dependencies. The state change checking needs the classpath to do comparisons. 10 percent of the time was consumed by our Ivy result translation (we might be able to improve this). This test project did not have many source files. It will be interesting to see whether with a larger codebase source change detection will play an important role here.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

>
> Is there a way to disable the up to date checks for particular tasks? I don't think it is currently useful for compileJava or Copy type of tasks and would like to try disabling it there.

>
> --
> Steve Appling
> Automated Logic Research Team
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

performance

2009-11-20T11:05:30Z

After Hans' dependency resolution performance fix, the huge performance problem
we saw has been fixed (thanks Hans!). I still find, however, that the overhead
of all the up to date checking is not worth it. When everything is up to date
and there is nothing to do, running "build -xtest" for our big project in the
0.8 version takes about 1:11 (min:sec) and doing the same thing with the current
trunk version takes 1:24.

Is there a way to disable the up to date checks for particular tasks? I don't
think it is currently useful for compileJava or Copy type of tasks and would
like to try disabling it there.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: userguide to epub script

2009-11-19T19:59:07Z

P. Siegmann wrote:

> Hi All,
>
> I've written a script that generates an epub document from the gradle
> userguide html.
>
> The output is not perfect.
> The biggest problem right now is that there is some tabs/spaces wrongness
> going on in the code samples.
> However, it does work and the result can be seen at
> http://www.siegmann.nl/gradleuserguide.epub.
>
> If more people are interested in this capability the script could be
> integrated into the regular gradle userguide build, but that is currently
> beyond my gradle capabilities.
> Is there someone willing to integrate the script in the userguide build
> procedure?
>

Thanks for providing this. I will have a look at integrating it into
Gradle's build.

--
Adam Murdoch
Gradle Developer
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Install doesn't work: Is this a Breaking Change?

2009-11-17T23:26:01Z

In ~/.gradle/gradle.properties I have:

gradle_installPath = /${user.home}/lib/JavaPackages/gradle-trunk

till today this worked fine -- the string was interpreted as a GString
and the property expanded at install time. As of this morning this is
not the case, the string appears not to be treated as a GString, but as
a String which means no property expansion :-(

Is there an alternative that is now to be used?

Thanks.

--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: russel@...
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@...
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder

signature.asc (204 bytes) Download Attachment

Re: Some archive stuff

2009-11-16T14:06:48Z

> fileMode = 755
> fileMode = "rwxr-xr-x",
> fileMode = "ugo+x"
would be really nice to be able to use all of them

but if I had to choose I would vote for the first one

--
Tomek

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Some archive stuff

2009-11-16T14:04:40Z

On Nov 16, 2009, at 10:06 PM, Adam Murdoch wrote:

Hans Dockter wrote:
one more issue:

If I create the following zip:

task permissions(type: Zip) {
   baseName = "permissions"
   from('foo') {
      fileMode = 755
   }
}

After unzipping the zip, I have the following permissions for foo: --wxrw--wx  1 hans  hans   12 Nov 16 20:15 foo

  
You need to use octal for 755 to work, ie fileMode = 0755. You've asked for 0363, above, which is what you got.

I understand. I guess I was in Ant mode, which uses 3-digit octal notation.

Perhaps an integer type is not the best option for this property. Maybe a string would be better instead, something like fileMode = "rwxr-xr-x", or fileMode = "ugo+x"

May be. Although I'm fine with the integer notation.

- Hans

Hans Dockter

Gradle Project Manager

http://www.gradle.org

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

On Nov 16, 2009, at 8:28 PM, Hans Dockter wrote:

There are some issues left with our very nice new archive handling.

usePlugin('base')

task topLevelInclude(type: Zip) {
  baseName = "topLevelInclude"
  include "foo"
}

task inheritInto(type: Zip) {
  baseName = "inheritInfo"
  into "bar"
  from('foo')
}

- The topLevelInclude zip is empty. I would expect it to include foo.
- The inheritInto zip has foo as a first level file. I would expect it to be in bar/foo.

I have attached a zip with the test project.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org





<archivetest.zip>---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Re: Some archive stuff

2009-11-16T13:06:47Z

Hans Dockter wrote:

one more issue:

If I create the following zip:

task permissions(type: Zip) {
   baseName = "permissions"
   from('foo') {
      fileMode = 755
   }
}

After unzipping the zip, I have the following permissions for foo: --wxrw--wx  1 hans  hans   12 Nov 16 20:15 foo

You need to use octal for 755 to work, ie fileMode = 0755. You've asked for 0363, above, which is what you got.

Perhaps an integer type is not the best option for this property. Maybe a string would be better instead, something like fileMode = "rwxr-xr-x", or fileMode = "ugo+x"

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

On Nov 16, 2009, at 8:28 PM, Hans Dockter wrote:

There are some issues left with our very nice new archive handling.

usePlugin('base')

task topLevelInclude(type: Zip) {
  baseName = "topLevelInclude"
  include "foo"
}

task inheritInto(type: Zip) {
  baseName = "inheritInfo"
  into "bar"
  from('foo')
}

- The topLevelInclude zip is empty. I would expect it to include foo.
- The inheritInto zip has foo as a first level file. I would expect it to be in bar/foo.

I have attached a zip with the test project.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org





<archivetest.zip>---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org