Configuration issues

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Configuration issues

Russel Winder-2
There is currently a lot of chatter about hierarchy configuration.  I
would like to re-poke GRADLE-27 which is about doing something about the
diktat that JUnit is the only supported unit test framework since this
is more of a blocker to use of Gradle for me that the hierarchy
structure.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

hans_d
Administrator

On Aug 31, 2008, at 8:52 AM, Russel Winder wrote:

> There is currently a lot of chatter about hierarchy configuration.  I
> would like to re-poke GRADLE-27 which is about doing something  
> about the
> diktat that JUnit is the only supported unit test framework since this
> is more of a blocker to use of Gradle for me that the hierarchy
> structure.

It is easy to use TestNg with Gradle via its Ant task. This is not as  
convenient as having it as part of our Java plugin but nobody is  
blocked from using TestNG when using the current version of Gradle.

- Hans

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





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

Russel Winder-2
Hans,

On Mon, 2008-09-01 at 05:23 +0200, Hans Dockter wrote:

> On Aug 31, 2008, at 8:52 AM, Russel Winder wrote:
>
> > There is currently a lot of chatter about hierarchy configuration.  I
> > would like to re-poke GRADLE-27 which is about doing something  
> > about the
> > diktat that JUnit is the only supported unit test framework since this
> > is more of a blocker to use of Gradle for me that the hierarchy
> > structure.
>
> It is easy to use TestNg with Gradle via its Ant task. This is not as  
> convenient as having it as part of our Java plugin but nobody is  
> blocked from using TestNG when using the current version of Gradle.
I think this is the wrong position to take.  If I have to start
constructing my own lifecycle framework because the standard one is
insufficiently parameterized and yet I have a standard lifecycle
project, then the Gradle realization of convention over configuration
has failed me.  Alternatively you need to advertise that Gradle supports
only the inferior JUnit and discriminates against the superior TestNG.

If you think the solution is easy, perhaps you can convince me by
showing me what sort of code I should have in my build.gradle file?

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

hans_d
Administrator

On Sep 1, 2008, at 7:40 AM, Russel Winder wrote:

> Hans,
>
> On Mon, 2008-09-01 at 05:23 +0200, Hans Dockter wrote:
>> On Aug 31, 2008, at 8:52 AM, Russel Winder wrote:
>>
>>> There is currently a lot of chatter about hierarchy  
>>> configuration.  I
>>> would like to re-poke GRADLE-27 which is about doing something
>>> about the
>>> diktat that JUnit is the only supported unit test framework since  
>>> this
>>> is more of a blocker to use of Gradle for me that the hierarchy
>>> structure.
>>
>> It is easy to use TestNg with Gradle via its Ant task. This is not as
>> convenient as having it as part of our Java plugin but nobody is
>> blocked from using TestNG when using the current version of Gradle.
>
> I think this is the wrong position to take.  If I have to start
> constructing my own lifecycle framework because the standard one is
> insufficiently parameterized and yet I have a standard lifecycle
> project, then the Gradle realization of convention over configuration
> has failed me.

You don't have to create your own lifecycle framework. You only have  
to customize the provided one.

This is all a question of priorities. Obviously supporting multi-
project builds for Eclipse is significantly more important than  
integrating TestNG in our Java Plugin.

> Alternatively you need to advertise that Gradle supports
> only the inferior JUnit and discriminates against the superior TestNG.
>
> If you think the solution is easy, perhaps you can convince me by
> showing me what sort of code I should have in my build.gradle file?

Please read the manual. Look at Table 9-3. I guess I don't have to  
tell you how to use the AntBuilder to create a TestNG task.

- Hans

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





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

helmut.denk
hallo hans,

hdockter wrote
This is all a question of priorities. Obviously supporting multi-
project builds for Eclipse is significantly more important than  
integrating TestNG in our Java Plugin.
this is exactly true from my perspective.

i migrated one of our 'multi-builds'  (as we call it
'multi-module-build' and you call it 'multi-project-build'
i shortcut the term ;-).

using our existent repositories the gradle-build works
well. even publishing through uploadLibs works - nice
result for a start ...

now next step would be to integrate with eclipse
in a way that .project and .classpath are satisfied
and  unit-tests can be run from inside of eclipse ...

is  there a timeframe for that task ? are
there samples/documentations for eclipse-integrations ?

thank you & have a nice day
Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

hans_d
Administrator
Hallo Helmut,

On Sep 1, 2008, at 11:09 AM, Helmut Denk wrote:

>
> hallo hans,
>
>
> hdockter wrote:
>>
>> This is all a question of priorities. Obviously supporting multi-
>> project builds for Eclipse is significantly more important than
>> integrating TestNG in our Java Plugin.
>>
>
> this is exactly true from my perspective.
>
> i migrated one of our 'multi-builds'  (as we call it
> 'multi-module-build' and you call it 'multi-project-build'
> i shortcut the term ;-).
>
> using our existent repositories the gradle-build works
> well. even publishing through uploadLibs works - nice
> result for a start ...
>
> now next step would be to integrate with eclipse
> in a way that .project and .classpath are satisfied
> and  unit-tests can be run from inside of eclipse ...

In fact this is already implemented in trunk. With trunk you can say:

gradle eclipse

and the files mentioned by you above are generated. The Eclipse task  
are documented by their Javadoc. See the classes. EclipseProject and  
EclipseClasspath. The user's guide does not contain a section on this  
yet.

What we still have to implement is to enable multiproject builds  
which have a non hierarchical structure. That is where the  
gradle.settings file does not have to live in the parent dir of the  
subprojects you want to build.

- Hans

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





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

helmut.denk
nice. as i work with the trunk,
it should be no big act to try that out.

thanks.


hdockter wrote
Hallo Helmut,

On Sep 1, 2008, at 11:09 AM, Helmut Denk wrote:

>
> hallo hans,
>
>
> hdockter wrote:
>>
>> This is all a question of priorities. Obviously supporting multi-
>> project builds for Eclipse is significantly more important than
>> integrating TestNG in our Java Plugin.
>>
>
> this is exactly true from my perspective.
>
> i migrated one of our 'multi-builds'  (as we call it
> 'multi-module-build' and you call it 'multi-project-build'
> i shortcut the term ;-).
>
> using our existent repositories the gradle-build works
> well. even publishing through uploadLibs works - nice
> result for a start ...
>
> now next step would be to integrate with eclipse
> in a way that .project and .classpath are satisfied
> and  unit-tests can be run from inside of eclipse ...

In fact this is already implemented in trunk. With trunk you can say:

gradle eclipse

and the files mentioned by you above are generated. The Eclipse task  
are documented by their Javadoc. See the classes. EclipseProject and  
EclipseClasspath. The user's guide does not contain a section on this  
yet.

What we still have to implement is to enable multiproject builds  
which have a non hierarchical structure. That is where the  
gradle.settings file does not have to live in the parent dir of the  
subprojects you want to build.

- Hans

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





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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

helmut.denk
i tried it out and it works ok for java-projects.

for groovy-projects (src/main/groovy) i
have to set 'source-path' and 'output-folder'
by hand.

i guess that this is a known issue ... is it ?



Helmut Denk wrote
nice. as i work with the trunk,
it should be no big act to try that out.
Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

hans_d
Administrator
Hi Helmut,

On Sep 1, 2008, at 2:09 PM, Helmut Denk wrote:

>
> i tried it out and it works ok for java-projects.
>
> for groovy-projects (src/main/groovy) i
> have to set 'source-path' and 'output-folder'
> by hand.
>
> i guess that this is a known issue ... is it ?

Kind of. Could you please file a Jira?

What other requirements are there for Eclipse Groovy projects (e.g. I  
guess we should assume that the Eclipse Groovy  plugin is used and  
put the proper builder information in the project file). I'm using  
IntelliJ. It would be great if you could give us the details for this.

Cheers,

Hans

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





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

helmut.denk
hdockter wrote
Kind of. Could you please file a Jira?
done.

hdockter wrote
What other requirements are there for Eclipse Groovy projects (e.g. I  
guess we should assume that the Eclipse Groovy  plugin is used ...
i think so.

one of the problems with todays 'greclipse'
will IMO be: http://jira.codehaus.org/browse/GRECLIPSE-51. this is a problem, that gradle and maven have in common.
 
hdockter wrote
put the proper builder information in the project file). I'm using  
IntelliJ. It would be great if you could give us the details for this.
1. in -F .project

- add buildCommand org.codehaus.groovy.eclipse.groovyBuilder
- add nature org.codehaus.groovy.eclipse.groovyNature

2. in -D .settings

add -F .settings/org.codehaus.groovy.eclipse.preferences.prefs

see snippets below ... i am not sure, if this is all.

*** snip1 = -F .project ***
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
        <name>myproject</name>
        <comment></comment>
        <projects>
        </projects>
        <buildSpec>
                <buildCommand>
                        <name>org.eclipse.jdt.core.javabuilder</name>
                        <arguments>
                        </arguments>
                </buildCommand>
                <buildCommand>
                        <name>org.codehaus.groovy.eclipse.groovyBuilder</name>
                        <arguments>
                        </arguments>
                </buildCommand>
        </buildSpec>
        <natures>
                <nature>org.eclipse.jdt.core.javanature</nature>
                <nature>org.codehaus.groovy.eclipse.groovyNature</nature>
        </natures>
</projectDescription>
*** snap1 ***


*** snip2 = -F .settings\org.codehaus.groovy.eclipse.preferences.prefs ***
#Mon Sep 01 14:37:15 CEST 2008
eclipse.preferences.version=1
groovy.compiler.output.path=build/classes
support.groovy=true
*** snap2 ***

Reply | Threaded
Open this post in threaded view
|

Re: Configuration issues

hans_d
Administrator
Hi Helmut,

thanks a lot. This will definitely make it into 0.4. I hope I have  
time to implement it this week.

But before that I want Gradle to be able to deal with multi-project  
builds that have a flat directory structure.

- Hans

On Sep 2, 2008, at 5:23 AM, Helmut Denk wrote:

>
>
> hdockter wrote:
>>
>> Kind of. Could you please file a Jira?
>>
>
> done.
>
>
> hdockter wrote:
>>
>> What other requirements are there for Eclipse Groovy projects (e.g. I
>> guess we should assume that the Eclipse Groovy  plugin is used ...
>>
>
> i think so.
>
> one of the problems with todays 'greclipse'
> will IMO be:  http://jira.codehaus.org/browse/GRECLIPSE-51
> http://jira.codehaus.org/browse/GRECLIPSE-51 . this is a problem, that
> gradle and maven have in common.
>
>
> hdockter wrote:
>>
>> put the proper builder information in the project file). I'm using
>> IntelliJ. It would be great if you could give us the details for  
>> this.
>>
>
> 1. in -F .project
>
> - add buildCommand org.codehaus.groovy.eclipse.groovyBuilder
> - add nature org.codehaus.groovy.eclipse.groovyNature
>
> 2. in -D .settings
>
> add -F .settings/org.codehaus.groovy.eclipse.preferences.prefs
>
> see snippets below ... i am not sure, if this is all.
>
> *** snip1 = -F .project ***
> <?xml version="1.0" encoding="UTF-8"?>
> <projectDescription>
> <name>myproject</name>
> <comment></comment>
> <projects>
> </projects>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.jdt.core.javabuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> <buildCommand>
> <name>org.codehaus.groovy.eclipse.groovyBuilder</name>
> <arguments>
> </arguments>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>org.eclipse.jdt.core.javanature</nature>
> <nature>org.codehaus.groovy.eclipse.groovyNature</nature>
> </natures>
> </projectDescription>
> *** snap1 ***
>
>
> *** snip2 = -F .settings
> \org.codehaus.groovy.eclipse.preferences.prefs ***
> #Mon Sep 01 14:37:15 CEST 2008
> eclipse.preferences.version=1
> groovy.compiler.output.path=build/classes
> support.groovy=true
> *** snap2 ***
>
>
> --
> View this message in context: http://www.nabble.com/Configuration- 
> issues-tp19239895p19263597.html
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

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





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

    http://xircles.codehaus.org/manage_email