Nabble - gradle-dev

Re: We are about to release a gradle-based scaffolding tool

2008-11-20T03:13:46Z

Hi Hans,

Thanks for your comments! I have just commited the changes.

Kind regards,
Rafa

hdockter wrote:

Hi Rafa,

On Nov 18, 2008, at 8:46 PM, Rafael Serrano wrote:

>
> Hi all,
>
> We are about to release a scaffolding tool with the next release of
> the
> Loom project ( http://loom.extrema-sistemas.org ) that creates a
> eclipse
> project structure based on gradle.

Cool :)

> I attach the
> http://www.nabble.com/file/p20566832/build.gradle build.gradle file
> that would be generated.
>
> Everything works fine, but we wanted to ask the gradle list for
> comments
> regarding the build file. If someone wanted to discuss about it
> (additions / removals / optimizations are most welcome!) or wanted to
> test the scaffolding tool before the release, please drop me a line
> (on-list or off-list, as you prefer).

I had a quick look and it looks good to me. But I had no time to
think myself into the problem space you are trying to solve, so I
might have missed something.

A couple of comments:

1.) task("eclipse").doFirst {
task("gen-lib").execute()
}

Instead of task("eclipse") you can also write eclipse. And instead of
executing you could create a dependsOn relation. The above would turn
into:

eclipse.dependsOn "gen-lib"

2.) There is a predefined dir which is used automatically by the war
plugin. The property is called webAppDir and defaults to src/main/
webApp. If you don't like the location you can say: webAppDirName =
'env'. This name is relative to the src dir. That should spare you the:

archive_war {
fileSet(dir: webappDir)
}

3.) Instead of try {
this["${appServer}Home"]
} catch(MissingPropertyException e) {
// println "The property ${appServer}Home has not been set. Trying
to use $envName"
this["${appServer}Home"] = getEnv(envName)
}

You can use the hasProperty method: if (hasProperty("${appServer}
Home")) { ... }

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: We are about to release a gradle-based scaffolding tool

2008-11-19T11:58:55Z

Hi Rafa,

On Nov 18, 2008, at 8:46 PM, Rafael Serrano wrote:

>
> Hi all,
>
> We are about to release a scaffolding tool with the next release of
> the
> Loom project ( http://loom.extrema-sistemas.org ) that creates a
> eclipse
> project structure based on gradle.

Cool :)

> I attach the
> http://www.nabble.com/file/p20566832/build.gradle build.gradle file
> that would be generated.
>
> Everything works fine, but we wanted to ask the gradle list for
> comments
> regarding the build file. If someone wanted to discuss about it
> (additions / removals / optimizations are most welcome!) or wanted to
> test the scaffolding tool before the release, please drop me a line
> (on-list or off-list, as you prefer).

I had a quick look and it looks good to me. But I had no time to
think myself into the problem space you are trying to solve, so I
might have missed something.

A couple of comments:

1.) task("eclipse").doFirst {
task("gen-lib").execute()
}

Instead of task("eclipse") you can also write eclipse. And instead of
executing you could create a dependsOn relation. The above would turn
into:

eclipse.dependsOn "gen-lib"

2.) There is a predefined dir which is used automatically by the war
plugin. The property is called webAppDir and defaults to src/main/
webApp. If you don't like the location you can say: webAppDirName =
'env'. This name is relative to the src dir. That should spare you the:

archive_war {
fileSet(dir: webappDir)
}

3.) Instead of try {
this["${appServer}Home"]
} catch(MissingPropertyException e) {
// println "The property ${appServer}Home has not been set. Trying
to use $envName"
this["${appServer}Home"] = getEnv(envName)
}

You can use the hasProperty method: if (hasProperty("${appServer}
Home")) { ... }

- Hans

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

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

http://xircles.codehaus.org/manage_email

We are about to release a gradle-based scaffolding tool

2008-11-18T11:46:38Z

Hi all,

We are about to release a scaffolding tool with the next release of the
Loom project ( http://loom.extrema-sistemas.org ) that creates a eclipse
project structure based on gradle. I attach the build.gradle file
that would be generated.

Everything works fine, but we wanted to ask the gradle list for comments
regarding the build file. If someone wanted to discuss about it
(additions / removals / optimizations are most welcome!) or wanted to
test the scaffolding tool before the release, please drop me a line
(on-list or off-list, as you prefer).

The scaffolding tool is a java application that generates a [ JPA +
Hibernate + Spring + Loom + JSP ] project structure with gradle as the
build system. We wanted to release it this same week if possible, so
time is an issue.

Best regards,
Rafa

Re: ditch latex?

2008-11-13T17:10:48Z

i can confirm, what you wrote about fop
and xep.

things, that the discussion has shown IMO:

- the grass isn't so much greener on the
other side of the river

- today there is no perfect solution for doing open-source-docs
like the gradle-users-guide.

(even if some weired people proclaim, that there
could be one in the future ;~)

gruesse

Re: ditch latex?

2008-11-13T15:47:22Z

Hi,

I had the chance today to speak with a computer book author who uses
docbook to write his books. He said he is very happy with docbook.
But he also said that he wasted an enormous amount time in
transforming fo in pdf with Apache FO. He said one big problem is
that when errors occur, Apache FO does not tell you what the reason
is. And you have to do try and error to fix the problem. He said that
this has cost him 2 months. May be we don't have the same problems as
what we want to render is not so difficult. Anyway, he finally turned
to a commercial tool called XEP (http://www.renderx.com/tools/
xep.html). He is very happy with this tool. They offer a free license
for non-profit use, but I doubt that this license allows us to put it
into svn. But at least it means there is a tool that would provide us
book publishing PDF quality.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: -S and -B command line options

2008-11-11T03:07:12Z

On Nov 11, 2008, at 10:59 AM, Adam Murdoch wrote:

> Hi,
>
> Do we need the -S and -B command line options? Can we get rid of them?

I have removed the -B option. The -S option is needed by the unit
test of the main class.

- Hans

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

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

http://xircles.codehaus.org/manage_email

-S and -B command line options

2008-11-11T01:59:33Z

Hi,

Do we need the -S and -B command line options? Can we get rid of them?

Adam

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

http://xircles.codehaus.org/manage_email

Installed HTML

2008-11-10T08:53:18Z

I have just found that all the links in the HTML documentation that gets
created during explodedDists have absolute URL to the Gradle website. I
would say that this is wrong, all the links should be internal to the
installed documentation.

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

[Fwd: [gradle-user] Stability of Subprocess Tests]

2008-11-10T04:32:19Z

OK, this is weird -- but very good.

With the latest Gradle installed, all the Gant tests pass. Seemingly
consistently.

Whatever changed is good :-)

-------- Forwarded Message --------

> From: Russel Winder <russel.winder@...>
> Reply-To: user@...
> To: Gradle Users <user@...>
> Subject: [gradle-user] Stability of Subprocess Tests
> Date: Sun, 09 Nov 2008 19:02:10 +0000
>
> The Gant tests for the Gant Ant task work consistently fine run from Ant
> and Gant. However from an IDE, one of the tests is very unstable.
> Unfortunately Gradle is failing on the same tests but in a fairly
> consistent way. The problem is definitely associated with a test that
> causes a subprocess to be started. The problem appears to be that there
> is some inconsistency in the characters stream sent from the subprocess
> to the main process.
>
> I have been failing to find a way of dealing with the problem. Has
> anyone come across this sort of thing elsewhere?
>
> Thanks.
>

Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: jars and ISO 8601

2008-11-10T04:02:44Z

Hans,

On Mon, 2008-11-10 at 11:41 +0100, Hans Dockter wrote:
> On Nov 10, 2008, at 11:01 AM, Russel Winder wrote:
[ . . . ]
> > gradle-0.5-20081110074402+0000.jar
> > gradle-wrapper-0.5-20081110074402+0000.jar
[ . . . ]
> Fixed.

Splendid. Thanks.

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: jars and ISO 8601

2008-11-10T02:41:29Z

On Nov 10, 2008, at 11:01 AM, Russel Winder wrote:

> I think the naming strategy for the jars should be changed:
>
> gradle-0.5-081110074402+0000.jar
> gradle-wrapper-0.5-081110074402+0000.jar
>
> should be
>
> gradle-0.5-20081110074402+0000.jar
> gradle-wrapper-0.5-20081110074402+0000.jar
>
> without the 20 the names are violating ISO 8601 even though they are
> trying to look like valid dates.

Fixed.

- Hans

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

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

http://xircles.codehaus.org/manage_email

jars and ISO 8601

2008-11-10T02:01:02Z

I think the naming strategy for the jars should be changed:

gradle-0.5-081110074402+0000.jar
gradle-wrapper-0.5-081110074402+0000.jar

should be

gradle-0.5-20081110074402+0000.jar
gradle-wrapper-0.5-20081110074402+0000.jar

without the 20 the names are violating ISO 8601 even though they are
trying to look like valid dates.

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

TestNG newsflash

2008-11-10T01:42:42Z

BTW Good luck with getting 0.5 out today, I hope it goes well.

The TestNG stuff seems to be progressing nicely, the branch compiles and
all the unit tests pass. Moreover, my ADS project now does something
more sensible than it used to:

|> gradle test
TestNGTestPolicy [init]
:init
:resources
:compile
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:testResources
:testCompile
:test

Build failed with an exception.
Run with -s or -d option to get more details. Run with -f option
to get the full (very verbose) stacktrace.

Build file
'/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle'

Execution failed for task :test.
Cause: Expected at least one TestNG suite to execute

BUILD FAILED

Total time: 25.965 secs

So clearly the initial experiment is a success, the question is now:
how to progress this. I won't be able to do any work on this for the
next couple of weeks or so -- I have to prepare for and go to SC08 in
Austin.

There is a Bazaar branch at lp:~russel/gradle/testng and a branch in the
Git repository on GitHub git://github.com/russel/gradle.git

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: Spurious or ?

2008-11-10T01:33:53Z

On Mon, 2008-11-10 at 10:19 +0100, Hans Dockter wrote:
[ . . . ]
> In the long run it would be nice to get rid of the Ant dependency for
> all our core tasks. Once we modularize we don't need a big dependency
> any longer. And the behavior of the Ant tasks are often not as
> flexible as we like.

On the one hand I agree it is good if Gradle Core can have very few
dependencies. On the other hand not using ready-made resource, but
replicating it could be seen as a bad move -- and create negative
publicity.

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: Spurious or ?

2008-11-10T01:19:11Z

On Nov 10, 2008, at 10:13 AM, Russel Winder wrote:

> On Mon, 2008-11-10 at 09:42 +0100, Hans Dockter wrote:
> [ . . . ]
>> I always run into this frequently. There is a Gradle multiproject
>> build where it only occurs if multiple projects are build but not in
>> the case of a single project sub project build. The reports are still
>> OK despite this warning. It would be nice to get rid of it but I
>> don't know how at the moment. When we move away from Ant for this
>> kind of stuff this will be obsolete anyway.
>
> OK, I'll just ignore it then.
>
> Is the "move away from Ant" and indicator that there is a "move to
> XXX"
> for some XXX, or is the intention to reimplement all the Ant tasks?

In the long run it would be nice to get rid of the Ant dependency for
all our core tasks. Once we modularize we don't need a big dependency
any longer. And the behavior of the Ant tasks are often not as
flexible as we like.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: stdout capture

2008-11-10T01:14:10Z

On Nov 7, 2008, at 6:54 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>>
>> On Nov 1, 2008, at 10:07 PM, Adam Murdoch wrote
>>
>> <snip>
>>
>>>
>>> Should there be some kind of inheritance going on, where a
>>> project inherits this setting from its parent, and tasks from
>>> their project?
>>
>> In general I'm not sure if inheritance is a good means to define
>> commons stuff in multi-project builds. Gradle provides inheritance
>> for properties and methods amongst build scripts (which would not
>> enable inheritance for settings stdout capture). But in general my
>> preferred way of configuring things is for example:
>>
>> allprojects {
>> captureStandardOut(LogLevel.INFO)
>> groovydoc.captureStandardOut(LogLevel.DEBUG)
>> }
>>
>> That way you can easily make exceptions for certain projects based
>> on filters.
>>
>> Would you prefer an inheritance approach?
>>
>
> Not really for projects. Not fussed. Perhaps tasks could use the
> level from their project as a default. Having played with this a
> bit, it seems kind of odd that when you set the level on a project,
> its doesn't affect the project's tasks.

We should use it as a default. http://jira.codehaus.org/browse/
GRADLE-309

> Or perhaps we just need to be able to do something like:
>
> alltasks {
> captureStandardOut(LogLevel.INFO)
> }

It probably would make sense to add such a alltasks notation although
right now there are probably not that many use cases for it.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Spurious or ?

2008-11-10T01:12:30Z

On Mon, 2008-11-10 at 09:42 +0100, Hans Dockter wrote:
[ . . . ]
> I always run into this frequently. There is a Gradle multiproject
> build where it only occurs if multiple projects are build but not in
> the case of a single project sub project build. The reports are still
> OK despite this warning. It would be nice to get rid of it but I
> don't know how at the moment. When we move away from Ant for this
> kind of stuff this will be obsolete anyway.

OK, I'll just ignore it then.

Is the "move away from Ant" and indicator that there is a "move to XXX"
for some XXX, or is the intention to reimplement all the Ant tasks?

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Re: Move unmanaged classpath into Configuration?

2008-11-10T00:59:20Z

On Nov 7, 2008, at 11:43 PM, Adam Murdoch wrote:

> Hi,
>
> I think we might get some nice benefits from moving the concept of
> unmanaged classpaths out of the various tasks and into
> Configuration. These are:
>
> - We remove the parallel concepts of configurations and unmanaged
> classpaths from all the tasks, and leave configurations (or more
> likely FileCollections). This means simpler tasks.
>
> - The unmanaged classpaths can be easily reused by multiple tasks.
> Currently, if I add something to the unmanaged classpath for
> compile, I have to hunt down all the other places that use the
> compile configuration and add it there (providing, of course, they
> all support unmanaged classpaths). If I add it to the compile
> configuration, then they all just pick it up.
>
> - We could attach meta-info to the items in the unmanaged
> classpath, such as which tasks produce them.
>
> - We could mix and match the use of ivy and files for a given
> dependency. For instance, I might want to bypass ivy for my intra-
> build dependencies by providing File for them, but still have ivy
> resolution used for those same dependencies when used outside the
> build (actually, its not 'might', I really do want to do this for
> some of my builds).

I like this very much. That would provide also a very convenient way
for projects which want to migrate to Gradle and have a lib folder
with unversioned jars for example.

Regarding the mix and match. This would mean a file dependency is
also part of the Ivy module descriptor?

>
> So, how might this look? I can see a few options:
>
> - Add some methods to Configuration which allow unmanaged files to
> be added to the Configuration. When Configuration.resolve() is
> called, it returns the union of the files provided by ivy and the
> set of unmanaged files.
>
> - Make Configuration polymorphic, so that you can have an Ivy
> Configuration or an unmanaged Configuration.
>
> - Change Dependency so that an implementation can provide either an
> ivy descriptor or a set of files or both, and add an
> UnmanagedDependency impl.
>
> I prefer the last option.

Me too. At the end of the day we might have dependencies being tasks.
We plan this for configurations anyway. But both would serve
different use cases.

>
> We would need a term other then 'unmanaged classpath' for this type
> of artifact because they aren't necessarily unmanaged, or used for
> the classpath.

I would say we can simply skip the term and we can replace it with
file configurations or file dependencies.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Task dynamic properties

2008-11-10T00:48:06Z

On Nov 7, 2008, at 9:33 PM, Adam Murdoch wrote:

> Hi,
>
> I wonder if we should generalise the extension mechanisms we have
> in Project (additional properties, extension using convention
> objects, and inheritance) and apply them to Task.
>
> I've found using convention objects to add behaviour to projects to
> be extremely useful in my own builds and plugins. I imagine the
> same would be true of applying them to tasks as well (and possibly
> a few other common types, such as Settings and DependencyManager).

This is an excellent idea.

I would also like to review the way the convention mechanism is
implemented at the moment.

>
> In addition, I think consistency is important here. Settings,
> Project and Task all have dynamic properties and/or methods, but
> they all work a little differently, and the methods on the
> interfaces are not quite the same (setProperty vs defineProperty).
> I'd rather not have to keep a different set of rules in my head for
> each type of extensible thing.

Definitely. But we have run into a Groovy pecularity here. For any
Groovy object setProperty is automatically added. You can overwrite
this but this gets not inherited. Therefore the way we use it works
for projects, as we only use the default project. But it does not
work for tasks as the tasks inherit from DefaultTask where
setProperty is overwritten. So I guess we have to rename the
setProperty method of the Project class.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Spurious or ?

2008-11-10T00:42:43Z

On Nov 10, 2008, at 8:36 AM, Russel Winder wrote:

> When I build Gradle, I get:
>
> [ . . . ]
> :test
> [ant:junitreport] the file /home/users/russel/Repositories/Git/
> Subversion/GradleCore/build/test-results/TESTS-TestSuites.xml is
> not a valid testsuite XML document
> :archive_jar
> [ . . . ]
>
> Is this to be expected?

I always run into this frequently. There is a Gradle multiproject
build where it only occurs if multiple projects are build but not in
the case of a single project sub project build. The reports are still
OK despite this warning. It would be nice to get rid of it but I
don't know how at the moment. When we move away from Ant for this
kind of stuff this will be obsolete anyway.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Integration test failure

2008-11-09T23:41:32Z

I tried using "gradle install" rather than my install script (which only
goes as far as :explodedDist. I get an integration test failure:

Build file '/home/users/russel/Repositories/Git/Subversion/GradleCore/build.gradle' line(s): 417, 417

Execution failed for task :integTest.
Cause: Cannot run program "/home/users/russel/Repositories/Git/Subversion/GradleCore/build/distributions/exploded/bin/gradle" (in directory "/home/users/russel/Repositories/Git/Subversion/GradleCore/build/distributions/exploded/samples/userguide/multiproject/flat/shark"): java.io.IOException: error=2, No such file or directory

Is this to be expected?

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Spurious or ?

2008-11-09T23:35:36Z

When I build Gradle, I get:

[ . . . ]
:test
[ant:junitreport] the file /home/users/russel/Repositories/Git/Subversion/GradleCore/build/test-results/TESTS-TestSuites.xml is not a valid testsuite XML document
:archive_jar
[ . . . ]

Is this to be expected?

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

signature.asc (196 bytes) Download Attachment

Move unmanaged classpath into Configuration?

2008-11-07T14:43:46Z

Hi,

I think we might get some nice benefits from moving the concept of
unmanaged classpaths out of the various tasks and into Configuration.
These are:

- We remove the parallel concepts of configurations and unmanaged
classpaths from all the tasks, and leave configurations (or more likely
FileCollections). This means simpler tasks.

- The unmanaged classpaths can be easily reused by multiple tasks.
Currently, if I add something to the unmanaged classpath for compile, I
have to hunt down all the other places that use the compile
configuration and add it there (providing, of course, they all support
unmanaged classpaths). If I add it to the compile configuration, then
they all just pick it up.

- We could attach meta-info to the items in the unmanaged classpath,
such as which tasks produce them.

- We could mix and match the use of ivy and files for a given
dependency. For instance, I might want to bypass ivy for my intra-build
dependencies by providing File for them, but still have ivy resolution
used for those same dependencies when used outside the build (actually,
its not 'might', I really do want to do this for some of my builds).

So, how might this look? I can see a few options:

- Add some methods to Configuration which allow unmanaged files to be
added to the Configuration. When Configuration.resolve() is called, it
returns the union of the files provided by ivy and the set of unmanaged
files.

- Make Configuration polymorphic, so that you can have an Ivy
Configuration or an unmanaged Configuration.

- Change Dependency so that an implementation can provide either an ivy
descriptor or a set of files or both, and add an UnmanagedDependency impl.

I prefer the last option.

We would need a term other then 'unmanaged classpath' for this type of
artifact because they aren't necessarily unmanaged, or used for the
classpath.

Adam

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

http://xircles.codehaus.org/manage_email

Task dynamic properties

2008-11-07T12:33:16Z

Hi,

I wonder if we should generalise the extension mechanisms we have in
Project (additional properties, extension using convention objects, and
inheritance) and apply them to Task.

I've found using convention objects to add behaviour to projects to be
extremely useful in my own builds and plugins. I imagine the same would
be true of applying them to tasks as well (and possibly a few other
common types, such as Settings and DependencyManager).

In addition, I think consistency is important here. Settings, Project
and Task all have dynamic properties and/or methods, but they all work a
little differently, and the methods on the interfaces are not quite the
same (setProperty vs defineProperty). I'd rather not have to keep a
different set of rules in my head for each type of extensible thing.

Adam

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

http://xircles.codehaus.org/manage_email

Re: Java plugin task dependencies

2008-11-07T12:18:28Z

Hans Dockter wrote:
> Hi,
>
> I'm wondering if it is a good idea to have the uploadDists task depend
> on the uploadLibs task. I'm thinking about letting uploadDists to
> depend only on libs. Of course this can be easily customized.
>
> What do you think?
>
I think this is good idea. We could possibly also add an 'upload' task
whose role is to upload everything produced by the build (libs, dists,
and anything else added by plugins or the project)

Adam

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

http://xircles.codehaus.org/manage_email

Java plugin task dependencies

2008-11-07T09:03:50Z

Hi,

I'm wondering if it is a good idea to have the uploadDists task
depend on the uploadLibs task. I'm thinking about letting uploadDists
to depend only on libs. Of course this can be easily customized.

What do you think?

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: stdout capture

2008-11-06T21:54:28Z

Hans Dockter wrote:

>
> On Nov 1, 2008, at 10:07 PM, Adam Murdoch wrote
>
> <snip>
>
>>
>> Should there be some kind of inheritance going on, where a project
>> inherits this setting from its parent, and tasks from their project?
>
> In general I'm not sure if inheritance is a good means to define
> commons stuff in multi-project builds. Gradle provides inheritance for
> properties and methods amongst build scripts (which would not enable
> inheritance for settings stdout capture). But in general my preferred
> way of configuring things is for example:
>
> allprojects {
> captureStandardOut(LogLevel.INFO)
> groovydoc.captureStandardOut(LogLevel.DEBUG)
> }
>
> That way you can easily make exceptions for certain projects based on
> filters.
>
> Would you prefer an inheritance approach?
>

Not really for projects. Not fussed. Perhaps tasks could use the level
from their project as a default. Having played with this a bit, it seems
kind of odd that when you set the level on a project, its doesn't affect
the project's tasks. Or perhaps we just need to be able to do something
like:

alltasks {
captureStandardOut(LogLevel.INFO)
}

Adam

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

http://xircles.codehaus.org/manage_email

Re: Hans' new Maven support and build numbers

2008-11-06T15:06:09Z

hdockter wrote:

Could you retrieve this number in your Maven builds?

Nope, but then it wasn't necessary as the functionality I'm writing now was basically built in. The pain of being an early adopter ;)

I've actually bitten the bullet and swapped to pure ivy repositories for internal artifacts. I'm still generating Pom's for everything, but as all of our projects are now converted maven compatibility is no longer a major concern.

Phil.

Re: Hans' new Maven support and build numbers

2008-11-06T14:46:11Z

On Nov 6, 2008, at 5:45 PM, Phil Messenger wrote:

>
>
>
> hdockter wrote:
>>
>> I had a short look at the source code of the Ant Maven tasks, but
>> there was no obvious way of getting the snapshot string. But I have
>> found also no way in my earlier Maven builds to get hold of the
>> snapshot string. Have you?
>>
>> It would be cool to get the snapshot number. We could parse the log
>> output if all else doesn't work.
>>
>
> Yup, saw the use of the ant tasks and the lack of useful functions to
> retrieve the required info. Is there an easy way to capture the log
> output?
>

Nothing really easy yet. You can hook into logback to add an
appender. But it would be nice to tell gradle that you want a String
with the log for a certain area of execution.

I might come up with something tomorrow. Just out of curiosity. Could
you retrieve this number in your Maven builds?

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Hans' new Maven support and build numbers

2008-11-06T08:45:20Z

hdockter wrote:

I had a short look at the source code of the Ant Maven tasks, but
there was no obvious way of getting the snapshot string. But I have
found also no way in my earlier Maven builds to get hold of the
snapshot string. Have you?

It would be cool to get the snapshot number. We could parse the log
output if all else doesn't work.

Yup, saw the use of the ant tasks and the lack of useful functions to retrieve the required info. Is there an easy way to capture the log output?

Phil.

Re: Hans' new Maven support and build numbers

2008-11-06T08:24:11Z

On Nov 6, 2008, at 2:17 PM, Phil Messenger wrote:

>
> Hi,
>
> I've been experimenting with the new Maven support in gradle for
> deploying
> artifacts, rather than using my own hacked up solution. I have a
> "releaseSnapshot" task, which does what it says - tags a SVN repo
> with a
> version and uploads a snapshot to a remote repository.
>
> I'm trying to do the "snapshot to a remote repository" thing with the
> MavenUploader, with mixed success. I can get it to upload snapshots
> and
> increment the version etc:
>
> [INFO] Retrieving previous build number from remote
> Uploading:
> miniweb/library/1.0.3-SNAPSHOT/library-1.0.3-20081106.131330-7.jar
> to remote
> Uploaded 28K
> [INFO] Uploading project information for library
> 1.0.3-20081106.131330-7
> [INFO] Retrieving previous metadata from remote
> [INFO] Uploading repository metadata for: 'artifact miniweb:library'
> [INFO] Retrieving previous metadata from remote
> [INFO] Uploading repository metadata for: 'snapshot
> miniweb:library:1.0.3-SNAPSHOT'
>
> I need to get the build number - "7" in this case - from the upload
> task. I
> can't see a way for doing - am I blind or is it impossible at the
> moment?

We delegate to the Ant Maven tasks for doing this. Reverse
engineering all the Maven meta-manipulation didn't look appealing and
that way we can guarantee 100 percent compatibility.

I had a short look at the source code of the Ant Maven tasks, but
there was no obvious way of getting the snapshot string. But I have
found also no way in my earlier Maven builds to get hold of the
snapshot string. Have you?

It would be cool to get the snapshot number. We could parse the log
output if all else doesn't work.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Hans' new Maven support and build numbers

2008-11-06T05:17:47Z

Hi,

I've been experimenting with the new Maven support in gradle for deploying artifacts, rather than using my own hacked up solution. I have a "releaseSnapshot" task, which does what it says - tags a SVN repo with a version and uploads a snapshot to a remote repository.

I'm trying to do the "snapshot to a remote repository" thing with the MavenUploader, with mixed success. I can get it to upload snapshots and increment the version etc:

[INFO] Retrieving previous build number from remote
Uploading: miniweb/library/1.0.3-SNAPSHOT/library-1.0.3-20081106.131330-7.jar to remote
Uploaded 28K
[INFO] Uploading project information for library 1.0.3-20081106.131330-7
[INFO] Retrieving previous metadata from remote
[INFO] Uploading repository metadata for: 'artifact miniweb:library'
[INFO] Retrieving previous metadata from remote
[INFO] Uploading repository metadata for: 'snapshot miniweb:library:1.0.3-SNAPSHOT'

I need to get the build number - "7" in this case - from the upload task. I can't see a way for doing - am I blind or is it impossible at the moment?

Phil.

Re: Transformers

2008-11-06T01:37:16Z

On Nov 4, 2008, at 12:32 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Hi Adam,
>>
>> I'm excited that we will get your transformer stuff into 0.5. I
>> have applied the transformers also to the SettingsConverter.
>>
>> The name ModuleDescriptorContributor doesn't fit any longer. We
>> could go for something like: IvyObjectConfigurer. But I'm
>> wondering if it wouldn't be best to give it a truly general name
>> like: TransformableContributor
>>
>
> I wonder. The methods will need renaming to something general as well.
>
> I think perhaps it's the pattern we should be reusing, if we come
> across this problem again, rather than the interface.
>
> Regardless, does this interface belong in the public API, or should
> it remain in api.internal? So far, I've been avoiding adding direct
> references to ivy classes to the public API, as I'm not sure its
> the right thing to do. However, there are plenty of references
> already there, so perhaps I should just add them in and worry about
> the coupling later.

Probably. We don't have to care too much about API stability before
1.0. That doesn't mean we shouldn't pay attention but we can let it
evolve into one direction and later, based on experience, review this
approach and decide whether this is the right thing to do.

>
>> One other thing is the behavior of the addIvyTransformer(Closure
>> transformer) method. Right now the closure is executed and we pass
>> the transformable as an argument. In code this would look like:
>>
>> addIvyTransformer { moduleDescriptor ->
>> moduleDescriptor.doThis()
>> moduleDescriptor.doThat()
>> }
>>
>> What about passing no argument to the closure but setting the
>> delegate of the closure to the transformable (like we do it for
>> example in DefaultProject.allprojects)
>>
>> addIvyTransformer {
>> doThis()
>> doThat()
>> }
>>
>
> This is definitely an option. The problem is that some of the ivy
> classes we use are immutable, such as Configuration.

We've been through this but I had forgotten again.

> Perhaps we could do both: pass the transformable object in as a
> parameter, and set it as the delegate. If the closure returns an
> object of the same type as the transformable, we use it as the
> result. Otherwise we use the passed in object as the result.

This is an excellent idea.

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: stdout capture

2008-11-06T01:32:16Z

On Nov 1, 2008, at 10:07 PM, Adam Murdoch wrote

<snip>

>
> Should there be some kind of inheritance going on, where a project
> inherits this setting from its parent, and tasks from their project?

In general I'm not sure if inheritance is a good means to define
commons stuff in multi-project builds. Gradle provides inheritance
for properties and methods amongst build scripts (which would not
enable inheritance for settings stdout capture). But in general my
preferred way of configuring things is for example:

allprojects {
captureStandardOut(LogLevel.INFO)
groovydoc.captureStandardOut(LogLevel.DEBUG)
}

That way you can easily make exceptions for certain projects based on
filters.

Would you prefer an inheritance approach?

- Hans

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

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

http://xircles.codehaus.org/manage_email

Re: Should we use fork equals true as a default for compile.

2008-11-05T01:53:09Z

On Nov 5, 2008, at 2:34 AM, Peter Niederwieser wrote:

>
>
> hdockter wrote:
>>
>> So fork = true is a must have for Groovyc compile.
>>
>
> I think it's a must-have to fix Groovyc's classpath issues. :-)

It definitely is for groovyc (due to a bug in groovyc not considering
includeAntRuntime in non fork mode).

For Java compile we still have non-fork as the default. I'm just
wondering if I have overseen an issue, as Maven and Ant use non-fork
as default. On the other hand, Maven might use it as default because
Ant use it as default :). If nobody objects I will set fork as
default for the Java compile as well.

Should I also specify a default value for maximum memory?

- Hans

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

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

http://xircles.codehaus.org/manage_email