gradlefile cleaning?

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

gradlefile cleaning?

JerodLass
I have a groovy method that I use in my gradlefile to add a bunch of .jars to the unmanagedClasspath.  Is there a way for the top-level project to call it to add these .jars (which are needed by more or less every subproject) to the classpaths of all subprojects?  This would allow me to cut the number of lines of every subproject's gradlefile almost in half.  If I just call it from the top-level gradlefile, the subprojects have trouble finding the .jars.  Thanks.

-Jerod
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator

On Jun 4, 2008, at 6:14 PM, JerodLass wrote:

>
> I have a groovy method that I use in my gradlefile to add a bunch  
> of .jars to
> the unmanagedClasspath.  Is there a way for the top-level project  
> to call it
> to add these .jars (which are needed by more or less every  
> subproject) to
> the classpaths of all subprojects?  This would allow me to cut the  
> number of
> lines of every subproject's gradlefile almost in half.  If I just  
> call it
> from the top-level gradlefile, the subprojects have trouble finding  
> the
> .jars.  Thanks.

In the toplevel gradlefile you can type:

allprojects {
     compile.unmanagedClasspath('x.jar', 'y.jar')
}

See user's guide section 13.1 and 13.2 for more details.

- Hans

>
> -Jerod
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17650512.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
When I do this, it appears to add the .jars to each classpath (per my debugging statements), but after adding the correct number of .jars the correct number of times, it then comes up with compiling errors as if  the .jars weren't added.  Not sure what's going on...


hdockter wrote
On Jun 4, 2008, at 6:14 PM, JerodLass wrote:

>
> I have a groovy method that I use in my gradlefile to add a bunch  
> of .jars to
> the unmanagedClasspath.  Is there a way for the top-level project  
> to call it
> to add these .jars (which are needed by more or less every  
> subproject) to
> the classpaths of all subprojects?  This would allow me to cut the  
> number of
> lines of every subproject's gradlefile almost in half.  If I just  
> call it
> from the top-level gradlefile, the subprojects have trouble finding  
> the
> .jars.  Thanks.

In the toplevel gradlefile you can type:

allprojects {
     compile.unmanagedClasspath('x.jar', 'y.jar')
}

See user's guide section 13.1 and 13.2 for more details.

- Hans

>
> -Jerod
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17650512.html
> Sent from the gradle-user 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

Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
In reply to this post by hans_d
Is there something I'm doing wrong?  The code I currently have in the toplevel gradlefile is:


//List jars = populateJars()
allprojects{

    compile.unmanagedClasspath(populateJars())
    //compile.unmanagedClasspath(jars)

    dependencies{
        addMavenRepo()
    }

}

where populateJars() is a method in the same gradlefile that populates and returns a List object of all jars in the common code directory.  This method works if placed in the individual gradlefiles with the same unmanagedClasspath code.  I also tried the commented-out portion and achieved the same result.  Does the compile.unmanagedClasspath change when accessed from a higher-level project?

hdockter wrote
On Jun 4, 2008, at 6:14 PM, JerodLass wrote:

>
> I have a groovy method that I use in my gradlefile to add a bunch  
> of .jars to
> the unmanagedClasspath.  Is there a way for the top-level project  
> to call it
> to add these .jars (which are needed by more or less every  
> subproject) to
> the classpaths of all subprojects?  This would allow me to cut the  
> number of
> lines of every subproject's gradlefile almost in half.  If I just  
> call it
> from the top-level gradlefile, the subprojects have trouble finding  
> the
> .jars.  Thanks.

In the toplevel gradlefile you can type:

allprojects {
     compile.unmanagedClasspath('x.jar', 'y.jar')
}

See user's guide section 13.1 and 13.2 for more details.

- Hans

>
> -Jerod
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17650512.html
> Sent from the gradle-user 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

Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator
Can there be a file path isssue or does populateJars return absolute  
paths?

- Hans

On Jun 5, 2008, at 3:36 PM, JerodLass wrote:

>
> Is there something I'm doing wrong?  The code I currently have in the
> toplevel gradlefile is:
>
>
> //List jars = populateJars()
> allprojects{
>
>     compile.unmanagedClasspath(populateJars())
>     //compile.unmanagedClasspath(jars)
>
>     dependencies{
>         addMavenRepo()
>     }
>
> }
>
> where populateJars() is a method in the same gradlefile that  
> populates and
> returns a List object of all jars in the common code directory.  
> This method
> works if placed in the individual gradlefiles with the same
> unmanagedClasspath code.  I also tried the commented-out portion and
> achieved the same result.  Does the compile.unmanagedClasspath  
> change when
> accessed from a higher-level project?
>
>
> hdockter wrote:
>>
>>
>> On Jun 4, 2008, at 6:14 PM, JerodLass wrote:
>>
>>>
>>> I have a groovy method that I use in my gradlefile to add a bunch
>>> of .jars to
>>> the unmanagedClasspath.  Is there a way for the top-level project
>>> to call it
>>> to add these .jars (which are needed by more or less every
>>> subproject) to
>>> the classpaths of all subprojects?  This would allow me to cut the
>>> number of
>>> lines of every subproject's gradlefile almost in half.  If I just
>>> call it
>>> from the top-level gradlefile, the subprojects have trouble finding
>>> the
>>> .jars.  Thanks.
>>
>> In the toplevel gradlefile you can type:
>>
>> allprojects {
>>      compile.unmanagedClasspath('x.jar', 'y.jar')
>> }
>>
>> See user's guide section 13.1 and 13.2 for more details.
>>
>> - Hans
>>
>>>
>>> -Jerod
>>> --
>>> View this message in context: http://www.nabble.com/gradlefile-
>>> cleaning--tp17650512p17650512.html
>>> Sent from the gradle-user 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17669975.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
populateJars() returns absolute paths. Here is the method:

List populateJars(){
    List jarList = []
    projectDir.eachFile {
                if(it.name =~ /\w+common/) {
                        new File(it, "lib").eachFile {
                                jarList.add(it.getAbsolutePath())
                        }
                }
        }
    return jarList
}

Right now, to make sure the right projectDir is used, I have it create this list once, before the allprojects section and just add the list to each project's unmanagedClasspath (like the commented-out code in earlier post)

I threw some debugging statements in and got output like:
added c:\workspace\codecommon\commons-io.jar to classpath

and made sure the project names that it added to were on point, but it still compiled the source as if these jars are missing.


hdockter wrote
Can there be a file path isssue or does populateJars return absolute  
paths?

- Hans

On Jun 5, 2008, at 3:36 PM, JerodLass wrote:

>
> Is there something I'm doing wrong?  The code I currently have in the
> toplevel gradlefile is:
>
>
> //List jars = populateJars()
> allprojects{
>
>     compile.unmanagedClasspath(populateJars())
>     //compile.unmanagedClasspath(jars)
>
>     dependencies{
>         addMavenRepo()
>     }
>
> }
>
> where populateJars() is a method in the same gradlefile that  
> populates and
> returns a List object of all jars in the common code directory.  
> This method
> works if placed in the individual gradlefiles with the same
> unmanagedClasspath code.  I also tried the commented-out portion and
> achieved the same result.  Does the compile.unmanagedClasspath  
> change when
> accessed from a higher-level project?
>
>
> hdockter wrote:
>>
>>
>> On Jun 4, 2008, at 6:14 PM, JerodLass wrote:
>>
>>>
>>> I have a groovy method that I use in my gradlefile to add a bunch
>>> of .jars to
>>> the unmanagedClasspath.  Is there a way for the top-level project
>>> to call it
>>> to add these .jars (which are needed by more or less every
>>> subproject) to
>>> the classpaths of all subprojects?  This would allow me to cut the
>>> number of
>>> lines of every subproject's gradlefile almost in half.  If I just
>>> call it
>>> from the top-level gradlefile, the subprojects have trouble finding
>>> the
>>> .jars.  Thanks.
>>
>> In the toplevel gradlefile you can type:
>>
>> allprojects {
>>      compile.unmanagedClasspath('x.jar', 'y.jar')
>> }
>>
>> See user's guide section 13.1 and 13.2 for more details.
>>
>> - Hans
>>
>>>
>>> -Jerod
>>> --
>>> View this message in context: http://www.nabble.com/gradlefile-
>>> cleaning--tp17650512p17650512.html
>>> Sent from the gradle-user 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17669975.html
> Sent from the gradle-user 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

Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator
Hi Jerod,

could you send me a zip with a complete project setup reproducing  
this problem?

- Hans

On Jun 5, 2008, at 5:09 PM, JerodLass wrote:

>
> populateJars() returns absolute paths. Here is the method:
>
> List populateJars(){
>     List jarList = []
>     jarCount = 0
>     root = projectDir
>     root.eachFile {
> if(it.name =~ /\w+common/) {
> new File(it, "lib").eachFile {
>                                 jarList.add(it.getAbsolutePath())
> }
> }
> }
>     return jarList
> }
>
> I threw some debugging statements in and got output like:
> added c:\workspace\codecommon\commons-io.jar to classpath
>
> and made sure the project names that it added to were on point, but  
> it still
> compiled the source as if these jars are missing.
>
>
>
> hdockter wrote:
>>
>> Can there be a file path isssue or does populateJars return absolute
>> paths?
>>
>> - Hans
>>
>> On Jun 5, 2008, at 3:36 PM, JerodLass wrote:
>>
>>>
>>> Is there something I'm doing wrong?  The code I currently have in  
>>> the
>>> toplevel gradlefile is:
>>>
>>>
>>> //List jars = populateJars()
>>> allprojects{
>>>
>>>     compile.unmanagedClasspath(populateJars())
>>>     //compile.unmanagedClasspath(jars)
>>>
>>>     dependencies{
>>>         addMavenRepo()
>>>     }
>>>
>>> }
>>>
>>> where populateJars() is a method in the same gradlefile that
>>> populates and
>>> returns a List object of all jars in the common code directory.
>>> This method
>>> works if placed in the individual gradlefiles with the same
>>> unmanagedClasspath code.  I also tried the commented-out portion and
>>> achieved the same result.  Does the compile.unmanagedClasspath
>>> change when
>>> accessed from a higher-level project?
>>>
>>>
>>> hdockter wrote:
>>>>
>>>>
>>>> On Jun 4, 2008, at 6:14 PM, JerodLass wrote:
>>>>
>>>>>
>>>>> I have a groovy method that I use in my gradlefile to add a bunch
>>>>> of .jars to
>>>>> the unmanagedClasspath.  Is there a way for the top-level project
>>>>> to call it
>>>>> to add these .jars (which are needed by more or less every
>>>>> subproject) to
>>>>> the classpaths of all subprojects?  This would allow me to cut the
>>>>> number of
>>>>> lines of every subproject's gradlefile almost in half.  If I just
>>>>> call it
>>>>> from the top-level gradlefile, the subprojects have trouble  
>>>>> finding
>>>>> the
>>>>> .jars.  Thanks.
>>>>
>>>> In the toplevel gradlefile you can type:
>>>>
>>>> allprojects {
>>>>      compile.unmanagedClasspath('x.jar', 'y.jar')
>>>> }
>>>>
>>>> See user's guide section 13.1 and 13.2 for more details.
>>>>
>>>> - Hans
>>>>
>>>>>
>>>>> -Jerod
>>>>> --
>>>>> View this message in context: http://www.nabble.com/gradlefile-
>>>>> cleaning--tp17650512p17650512.html
>>>>> Sent from the gradle-user 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
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/gradlefile-
>>> cleaning--tp17650512p17669975.html
>>> Sent from the gradle-user 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17672148.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
I'll have to ask around to find out if that's okay with everyone.  It could be reproduced by the structure:

-DProjects
    -DProject1
        -Dsrc
        -Fgradlefile
    -DProject2
        -Dsrc
        -Fgradlefile
    -Djarscommon
    -Fgradlefile
    -Fgradlesettings

where the top-level gradlefile is as described, and the subprojects are to be made into jars themselves.  my project2 has a compile time dependency on project 1, and it seems important that the projects actually do need the classes in the jars that exist in the jarscommon directory.

I'm also having trouble specifying what files or fileSets to jar.  Could you possibly give a quick example of how to make a specific jar archive of a project to include specific files/directories that are in the project directory?  e.g. 'build/classes/', 'lib/', 'data/', and 'gradlefile'


hdockter wrote
Hi Jerod,

could you send me a zip with a complete project setup reproducing  
this problem?

- Hans

On Jun 5, 2008, at 5:09 PM, JerodLass wrote:

>
> populateJars() returns absolute paths. Here is the method:
>
> List populateJars(){
>     List jarList = []
>     jarCount = 0
>     root = projectDir
>     root.eachFile {
> if(it.name =~ /\w+common/) {
> new File(it, "lib").eachFile {
>                                 jarList.add(it.getAbsolutePath())
> }
> }
> }
>     return jarList
> }
>
> I threw some debugging statements in and got output like:
> added c:\workspace\codecommon\commons-io.jar to classpath
>
> and made sure the project names that it added to were on point, but  
> it still
> compiled the source as if these jars are missing.
>
>
>
> hdockter wrote:
>>
>> Can there be a file path isssue or does populateJars return absolute
>> paths?
>>
>> - Hans
>>
>> On Jun 5, 2008, at 3:36 PM, JerodLass wrote:
>>
>>>
>>> Is there something I'm doing wrong?  The code I currently have in  
>>> the
>>> toplevel gradlefile is:
>>>
>>>
>>> //List jars = populateJars()
>>> allprojects{
>>>
>>>     compile.unmanagedClasspath(populateJars())
>>>     //compile.unmanagedClasspath(jars)
>>>
>>>     dependencies{
>>>         addMavenRepo()
>>>     }
>>>
>>> }
>>>
>>> where populateJars() is a method in the same gradlefile that
>>> populates and
>>> returns a List object of all jars in the common code directory.
>>> This method
>>> works if placed in the individual gradlefiles with the same
>>> unmanagedClasspath code.  I also tried the commented-out portion and
>>> achieved the same result.  Does the compile.unmanagedClasspath
>>> change when
>>> accessed from a higher-level project?
>>>
>>>
>>> hdockter wrote:
>>>>
>>>>
>>>> On Jun 4, 2008, at 6:14 PM, JerodLass wrote:
>>>>
>>>>>
>>>>> I have a groovy method that I use in my gradlefile to add a bunch
>>>>> of .jars to
>>>>> the unmanagedClasspath.  Is there a way for the top-level project
>>>>> to call it
>>>>> to add these .jars (which are needed by more or less every
>>>>> subproject) to
>>>>> the classpaths of all subprojects?  This would allow me to cut the
>>>>> number of
>>>>> lines of every subproject's gradlefile almost in half.  If I just
>>>>> call it
>>>>> from the top-level gradlefile, the subprojects have trouble  
>>>>> finding
>>>>> the
>>>>> .jars.  Thanks.
>>>>
>>>> In the toplevel gradlefile you can type:
>>>>
>>>> allprojects {
>>>>      compile.unmanagedClasspath('x.jar', 'y.jar')
>>>> }
>>>>
>>>> See user's guide section 13.1 and 13.2 for more details.
>>>>
>>>> - Hans
>>>>
>>>>>
>>>>> -Jerod
>>>>> --
>>>>> View this message in context: http://www.nabble.com/gradlefile-
>>>>> cleaning--tp17650512p17650512.html
>>>>> Sent from the gradle-user 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
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/gradlefile-
>>> cleaning--tp17650512p17669975.html
>>> Sent from the gradle-user 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17672148.html
> Sent from the gradle-user 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

Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator

On Jun 5, 2008, at 8:56 PM, JerodLass wrote:

>
> I'll have to ask around to find out how much I should show
>
>
>
> hdockter wrote:
>>
>> Hi Jerod,
>>
>> could you send me a zip with a complete project setup reproducing
>> this problem?

I mean a complete test project which simulates the problem.

- Hans

>>
>> - Hans
>>
>> On Jun 5, 2008, at 5:09 PM, JerodLass wrote:
>>
>>>
>>> populateJars() returns absolute paths. Here is the method:
>>>
>>> List populateJars(){
>>>     List jarList = []
>>>     jarCount = 0
>>>     root = projectDir
>>>     root.eachFile {
>>> if(it.name =~ /\w+common/) {
>>> new File(it, "lib").eachFile {
>>>                                 jarList.add(it.getAbsolutePath())
>>> }
>>> }
>>> }
>>>     return jarList
>>> }
>>>
>>> I threw some debugging statements in and got output like:
>>> added c:\workspace\codecommon\commons-io.jar to classpath
>>>
>>> and made sure the project names that it added to were on point, but
>>> it still
>>> compiled the source as if these jars are missing.
>>>
>>>
>>>
>>> hdockter wrote:
>>>>
>>>> Can there be a file path isssue or does populateJars return  
>>>> absolute
>>>> paths?
>>>>
>>>> - Hans
>>>>
>>>> On Jun 5, 2008, at 3:36 PM, JerodLass wrote:
>>>>
>>>>>
>>>>> Is there something I'm doing wrong?  The code I currently have in
>>>>> the
>>>>> toplevel gradlefile is:
>>>>>
>>>>>
>>>>> //List jars = populateJars()
>>>>> allprojects{
>>>>>
>>>>>     compile.unmanagedClasspath(populateJars())
>>>>>     //compile.unmanagedClasspath(jars)
>>>>>
>>>>>     dependencies{
>>>>>         addMavenRepo()
>>>>>     }
>>>>>
>>>>> }
>>>>>
>>>>> where populateJars() is a method in the same gradlefile that
>>>>> populates and
>>>>> returns a List object of all jars in the common code directory.
>>>>> This method
>>>>> works if placed in the individual gradlefiles with the same
>>>>> unmanagedClasspath code.  I also tried the commented-out  
>>>>> portion and
>>>>> achieved the same result.  Does the compile.unmanagedClasspath
>>>>> change when
>>>>> accessed from a higher-level project?
>>>>>
>>>>>
>>>>> hdockter wrote:
>>>>>>
>>>>>>
>>>>>> On Jun 4, 2008, at 6:14 PM, JerodLass wrote:
>>>>>>
>>>>>>>
>>>>>>> I have a groovy method that I use in my gradlefile to add a  
>>>>>>> bunch
>>>>>>> of .jars to
>>>>>>> the unmanagedClasspath.  Is there a way for the top-level  
>>>>>>> project
>>>>>>> to call it
>>>>>>> to add these .jars (which are needed by more or less every
>>>>>>> subproject) to
>>>>>>> the classpaths of all subprojects?  This would allow me to  
>>>>>>> cut the
>>>>>>> number of
>>>>>>> lines of every subproject's gradlefile almost in half.  If I  
>>>>>>> just
>>>>>>> call it
>>>>>>> from the top-level gradlefile, the subprojects have trouble
>>>>>>> finding
>>>>>>> the
>>>>>>> .jars.  Thanks.
>>>>>>
>>>>>> In the toplevel gradlefile you can type:
>>>>>>
>>>>>> allprojects {
>>>>>>      compile.unmanagedClasspath('x.jar', 'y.jar')
>>>>>> }
>>>>>>
>>>>>> See user's guide section 13.1 and 13.2 for more details.
>>>>>>
>>>>>> - Hans
>>>>>>
>>>>>>>
>>>>>>> -Jerod
>>>>>>> --
>>>>>>> View this message in context: http://www.nabble.com/gradlefile-
>>>>>>> cleaning--tp17650512p17650512.html
>>>>>>> Sent from the gradle-user 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://www.nabble.com/gradlefile-
>>>>> cleaning--tp17650512p17669975.html
>>>>> Sent from the gradle-user 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
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/gradlefile-
>>> cleaning--tp17650512p17672148.html
>>> Sent from the gradle-user 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
>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17677115.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator
In reply to this post by JerodLass

On Jun 4, 2008, at 6:14 PM, JerodLass wrote:

>
> I have a groovy method that I use in my gradlefile to add a bunch  
> of .jars to
> the unmanagedClasspath.  Is there a way for the top-level project  
> to call it
> to add these .jars (which are needed by more or less every  
> subproject) to
> the classpaths of all subprojects?  This would allow me to cut the  
> number of
> lines of every subproject's gradlefile almost in half.  If I just  
> call it
> from the top-level gradlefile, the subprojects have trouble finding  
> the
> .jars.  Thanks.

As much as I would like to find out whether this is a Gradle bug or  
not. Why not using normal dependencies instead of the unmanaged ones?

- Hans

>
> -Jerod
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17650512.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
If by normal you mean regular compile dependencies on artifacts, the normal dependency declarations had the specific [group]:[artifact]:[version]:[type] format, and not many of the jars in the common directory had these conventions.  Just based on the name, unmanagedClasspath seemed to make more sense.  The common directory, as of yet, is just a local directory with a big pile of unmanaged and mostly unversioned jars .  If there is a way to declare a normal dependency of each project on the jars in that directory without versioning all of the jars and/or listing them all individually (there are 100+), I would be interested to know.

As far as the issue goes, it was solved in two steps.  First, I got a lot of help creating a task to add the jars and making each projects compile task depend on that task.  This worked.  We found that there was come quirky context issue where it was adding the jars to different classpaths than expected (probably the same one each time).  Then, earlier today, I tried to revert back so I could describe the problem to you more effectively, and all I left in was compile.unmanagedClasspath(jars) in the allprojects section and everything worked.  I had moved some other things into allprojects, so it's possible that things were happening in the wrong order, but it works now and it makes as much sense as I thought it should when I was having problems before.
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator

On Jun 6, 2008, at 5:32 PM, JerodLass wrote:

>
> If by normal you mean regular compile dependencies on artifacts,  
> the normal
> dependency declarations had the specific [group]:[artifact]:
> [version]:[type]
> format, and not many of the jars in the common directory had these
> conventions.  Just based on the name, unmanagedClasspath seemed to  
> make more
> sense.  The common directory, as of yet, is just a local directory  
> with a
> big pile of unmanaged and mostly unversioned jars .  If there is a  
> way to
> declare a normal dependency of each project on the jars in that  
> directory
> without versioning all of the jars and/or listing them all  
> individually
> (there are 100+), I would be interested to know.

Didn't setting the artifactPattern of the flatdir resolver did the job?

>
> As far as the issue goes, it was solved in two steps.  First, I got  
> a lot of
> help creating a task to add the jars and making each projects  
> compile task
> depend on that task.  This worked.  We found that there was come  
> quirky
> context issue where it was adding the jars to different classpaths  
> than
> expected (probably the same one each time).  Then, earlier today, I  
> tried to
> revert back so I could describe the problem to you more  
> effectively, and all
> I left in was compile.unmanagedClasspath(jars) in the allprojects  
> section
> and everything worked.  I had moved some other things into  
> allprojects, so
> it's possible that things were happening in the wrong order, but it  
> works
> now and it makes as much sense as I thought it should when I was  
> having
> problems before.

Cool

> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17695093.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
This post was updated on .
I figured unmanagedClasspath out (or at least I thought I did) before looking too hard at finishing getting artifact dependencies working.  Maybe I'll have to to solve my next problem, though.  How can I make sure that when I jar a project it includes the dependencies it has in order to run.  If gradle resolves a dependency that I specify, how do I make sure that file ends up in the ear folder?

-Jerod
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator
Hi Jerod,

On Jun 6, 2008, at 6:26 PM, JerodLass wrote:

>
> I figured unmanagedClasspath out (or at least I thought I did)  
> before looking
> too hard at finishing getting artifact dependencies working.  Maybe  
> I'll
> have to to solve my next problem, though.  How can I make sure that  
> when I
> jar a project it includes the dependencies it has in order to run.  
> I like
> the default jar gradle creates which includes only the compiled  
> classes, but
> then I would like to make a bigger jar with those and everything  
> else it
> depends on.  Is example 9.7.3 (dist/zip example) the most relevant  
> for doing
> so?  Thanks again for all of your help.

0.1.5 will have merge functionality. In fact, this is already  
implemented in svn. 0.1.5 is probably going to be released this week.  
If you want to use merge right now, you have to build from svn (or  
ask me, and I can upload a snapshot).

- Hans

>
> -Jerod
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17696356.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
I am now having problems with getting the flatDirResolver to work, which I plan to use rather than the unmanagedClasspath.  I have added:
addFlatDirResolver('common', commonLib).addArtifactPattern('[artifact].[ext]')
in the dependencies portion, followed by:
compile "common-lib:jar"
and I have tried combinations by playing with the compile "common-lib:jar" to get different notations, like:
compile "common-lib.jar"
compile ":common-lib::jar"
etc
and I also tried changing the addFlatDirResolver line:
addArtifactPattern('[artifact]:[ext]')
addArtifactPattern('[artifact]:[type]')
addArtifactPattern('[artifact].[type]')
The closest I came was when it looked for the jar (combination [artifact].[ext], ":common-lib::jar") but couldn't find it because it was still concatenating a - on the end.  Any idea what I'm doing wrong? Thanks for the help.

-Jerod
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
This post was updated on .
update: worked (very slow, however) when I changed the resolver declaration to:

addFlatDirResolver('common', commonLib).addArtifactPattern(commonLib.path+'/[artifact].[ext]')
with compile dependencies in the form of ":[artifact]::[type]"

Now, is there some way to generate these sets of compile statements?  I am moving from Ant, so I wrote a script to generate a file full of xml classpath junk into a list of gradle compile statements, but is there a better way than copy/pasting them over to the gradlefile?
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator

On Jun 9, 2008, at 5:58 PM, JerodLass wrote:

>
> update: worked when I changed the resolver declaration to:
>
> addFlatDirResolver('common',
> commonLib).addArtifactPattern(commonLib.path+'/[artifact].[ext]')
> with compile dependencies in the form of ":[artifact]::[type]"
>
> Now, is there some way to generate these sets of compile  
> statements?  I am
> moving from Ant, so I wrote a script to generate a file full of xml
> classpath junk into a list of gradle compile statements, but is  
> there a
> better way than copy/pasting them over to the gradlefile?

Not yet. But we want to provide conversion tools from Ant and Maven  
files to Gradle in the future.

- Hans


> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17735903.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
In the meantime, is there a way to access a list of dependencies I've declared as objects (and work with them within a gradle task)? Right now, it looks like I'll have to run a script on the gradlefile to convert compile dependencies back to xml format for a .classpath file. The reason for this is I might add dependencies to a project I'm building with gradle and someone I'm working with may decide to build it with ant since they're used to it and their IDE is already ant-friendly.
Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

hans_d
Administrator

On Jun 10, 2008, at 3:59 PM, JerodLass wrote:

>
> In the meantime, is there a way to access a list of dependencies I've
> declared as objects (and work with them within a gradle task)?

You can write in any task for example:

dependencies.resolve('compile')

which returns a list of File objects pointing to the resolved  
dependencies.

- Hans

> Right now, it
> looks like I'll have to run a script on the gradlefile to convert  
> compile
> dependencies back to xml format for a .classpath file. The reason  
> for this
> is I might add dependencies to a project I'm building with gradle and
> someone I'm working with may decide to build it with ant since  
> they're used
> to it and their IDE is already ant-friendly.
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17756151.html
> Sent from the gradle-user 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


Reply | Threaded
Open this post in threaded view
|

Re: gradlefile cleaning?

JerodLass
I am trying to do this from within a task defined in the subprojects{} section.  For now, before I get too excited about generating xml, I just want it to print out the resolved files.  When I add this task to the subprojects section:
    createTask('cpGenXML', dependsOn: 'compile'){
        println 'Project ' + project.name + ' getting resolved dependencies...'
        dependencies.resolve('compile').each {file->
            println 'File ' + file.name + ' resolved.'
        }
    }
The resulting output is:
Executing: :compile
Executing: :project1:cpGenXML
Project project2 getting resolved dependencies...
File proj2dep1.jar resolved.
File proj2dep2.jar resolved.
etc...
Executing: :project2:cpGenXML
Project project2 getting resolved dependencies...
File proj2dep1.jar resolved.
File proj2dep2.jar resolved.
etc...

It is supposed to be doing this for each project individually, but the context is having a problem and it is getting project2's dependency list no matter which project it is executing the task from.  Am I declaring this task wrong or in the wrong section?  In the end, I'm going for a task that operated the same for eac project, taking the list of that project's resolved dependencies and generating some xml.  Note: project2 depends on project1.

Update: changed task to:
    createTask('cpGenXML', dependsOn: 'compile'){task->
        println 'Project ' + task.project.name + ' getting resolved dependencies...'
        task.project.dependencies.resolve('compile').each {file->
            println 'File ' + file.name + ' resolved.'
        }
    }

and it works.  I just need to be a bit more careful :) ...
hdockter wrote
On Jun 10, 2008, at 3:59 PM, JerodLass wrote:

>
> In the meantime, is there a way to access a list of dependencies I've
> declared as objects (and work with them within a gradle task)?

You can write in any task for example:

dependencies.resolve('compile')

which returns a list of File objects pointing to the resolved  
dependencies.

- Hans

> Right now, it
> looks like I'll have to run a script on the gradlefile to convert  
> compile
> dependencies back to xml format for a .classpath file. The reason  
> for this
> is I might add dependencies to a project I'm building with gradle and
> someone I'm working with may decide to build it with ant since  
> they're used
> to it and their IDE is already ant-friendly.
> --
> View this message in context: http://www.nabble.com/gradlefile- 
> cleaning--tp17650512p17756151.html
> Sent from the gradle-user 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

12