Nabble - gradle-user

Re: Gradle not building if there's no network connection

2009-11-10T22:59:49Z

I noticed the other day that my build fails while trying to update snapshot dependencies if there's no network connection. Since all the dependencies are in my cache is there anyway to make the build to continue?

This occurs when dynamic dependencies are used. For example Maven snapshots or something like "junit:junit:4.4+". We do this in the integration test. Is this where your build stalls?

Yep.

Re: How to do a copy filter the gradle way?

2009-11-10T08:41:05Z

On Nov 10, 2009, at 3:01 PM, Narco wrote:

>
> Yes, it works. However, I don`t see any improvements of copying task
> from
> gradle. It doesn`t support even filtersfile and overwrite
> attributes. I`m
> going to use normal project.ant instead... Why not?

Ant is our friend. I don't see fundamental issues with using it. But
Gradle's copy has important advantages depending on your use case.

- It can accept Gradle's file system abstractions:

copy {
from configurations.runtime
}

- I really like the nested way of doing things and the syntax.
- You can copy subsets from archive and the archives will be never be
temporarily unpacked but only streamed.
- You can set file permissions (depending on the context)
- It is an common pattern used for copying into the file system as
well as filling an archive (in 0.9).
- We will listen to our user's and add the missing bits soon ;)

> What is not working for me is replacing tokens in target folder
> without
> copying. "Copy" seems simply skipping task when source and target is
> the
> same.

Could you file a Jira?

- Hans

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

> If Gradle could do that it will give performance and simpler scripts.
>
>
> Steve Appling wrote:
>>
>> Sorry, I had only looked at the ant ReplaceTokens documentation and
>> not at
>> the
>> source. It does not support a setPropertiesfile method to allow
>> access to
>> this
>> feature :(
>>
>> But (again without having tried this myself) perhaps this is
>> sufficient:
>>
>> Properties props = new Props()
>> props.load(...)
>>
>> copy {
>> from 'path_to_file_to_be_filtered'
>> into ...
>> filter(ReplaceTokens, tokens: props)
>> }
>>
>> I'm not clear why Hans had a props.each surrounding the filter in his
>> example.
>>
>> Narco wrote:
>>> on gradle0.8 filter(ReplaceTokens, propertiesfile:
>>> 'mysettings.properties')
>>> gives:
>>> Cause: Error - Invalid filter specification for
>>> org.apache.tools.ant.filters.ReplaceTokens
>>>
>>>
>>> Steve Appling wrote:
>>>>
>>>>
>>>> Hans Dockter wrote:
>>>>> On Nov 4, 2009, at 3:04 PM, Jason Porter wrote:
>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Nov 4, 2009, at 4:43, Levi Hoogenberg
>>>>>> <levihoogenberg@...
>>>>>> <mailto:levihoogenberg@...>> wrote:
>>>>>>
>>>>>>> Hi Jason,
>>>>>>>
>>>>>>> I don't know if it's the Gradle way, but in one of my projects'
>>>>>>> build.gradle I have the following:
>>>>>>>
>>>>>>> processResources {
>>>>>>> filter(org.apache.tools.ant.filters.ReplaceTokens, tokens:
>>>>>>> [version: project.version])
>>>>>>> }
>>>>>>>
>>>>>>> This replaces @version@ in a property file, so that it can be
>>>>>>> read
>>>>>>> from the code.
>>>>> The processResources task is of type Copy.
>>>>>
>>>>> See
>>>>> Javadoc:
>>>>> http://gradle.org/0.8/docs/javadoc/index.html?org/gradle/api/tasks/Copy.html
>>>>>
>>>>> What you could do in your case:
>>>>>
>>>>> Properties props = new Props()
>>>>> props.load(...)
>>>>>
>>>>> copy {
>>>>> from 'path_to_file_to_be_filtered'
>>>>> into ...
>>>>> props.each { key, value ->
>>>>> filter(ReplaceTokens, tokens: props) // It depends on you
>>>>> set up
>>>>> if this is exactly what you want.
>>>>> }
>>>>> }
>>>>>
>>>>> - Hans
>>>>>
>>>>> --
>>>>> Hans Dockter
>>>>> Gradle Project Manager
>>>>> http://www.gradle.org
>>>> I haven't tried this, but I think the ReplaceTokens filter can
>>>> read from
>>>> a
>>>> properties file all by itself so you can do:
>>>> copy {
>>>> from 'path_to_file_to_be_filtered'
>>>> into ...
>>>> filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
>>>> }
>>>>
>>>>
>>>>>>> Regards,
>>>>>>> Levi
>>>>>>>
>>>>>>> On Wed, Nov 4, 2009 at 7:46 AM, Jason Porter <
>>>>>>> <http://lightguard.jp/>lightguard.jp <http://lightguard.jp/>@
>>>>>>> <http://gmail.com/>gmail.com <http://gmail.com/>> wrote:
>>>>>>>
>>>>>>> In a war I've got I'd like to filter a file that ultimately
>>>>>>> ends
>>>>>>> up in
>>>>>>> the WEB-INF directory (chances are I'll just put it here
>>>>>>> under
>>>>>>> webapp/WEB-INF anyway), but I want to replace some tokens
>>>>>>> in it
>>>>>>> (preferably with items that exist in a properties file). I
>>>>>>> know
>>>>>>> how
>>>>>>> I'd do this in ant, but what's the gradle way of doing it?
>>>>>>>
>>>>>>> --
>>>>>>> Jason Porter
>>>>>>> Real Programmers think better when playing Adventure or
>>>>>>> Rogue.
>>>>>>>
>>>>>>> PGP key id: 926CCFF5
>>>>>>> PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C
>>>>>>> CFF5
>>>>>>> PGP key available at: <http://keyserver.net/>keyserver.net
>>>>>>> <http://keyserver.net/>, <http://pgp.mit.edu/>pgp.mit.edu
>>>>>>> <http://pgp.mit.edu/>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <http://xircles.codehaus.org/manage_email>http://
>>>>>>> xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> That would work fine, but I don't want to list the tokens and
>>>>>> their
>>>>>> values in the build file. I'd rather have them pulled from a
>>>>>> properties file (so it can change from box / environment).
>>>>>> Think stuff
>>>>>> like user names and passwords, external locations, etc.
>>>> --
>>>> Steve Appling
>>>> Automated Logic Research Team
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>> http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Steve Appling
>> Automated Logic Research Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/How-to-do-a-copy-filter-the-gradle-way--tp26191753p26283890.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
>
>

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

http://xircles.codehaus.org/manage_email

Re: Gradle not building if there's no network connection

2009-11-10T08:17:59Z

On Nov 8, 2009, at 11:47 PM, Adam Murdoch wrote:

>
>
> Andrew Pietsch wrote:
>> Hi there,
>>
>> I noticed the other day that my build fails while trying to update
>> snapshot dependencies if there's no network connection. Since all
>> the dependencies are in my cache is there anyway to make the build
>> to continue?

This occurs when dynamic dependencies are used. For example Maven
snapshots or something like "junit:junit:4.4+". We do this in the
integration test. Is this where your build stalls?

- Hans

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

>>
>
> No built-in way, yet. There's a JIRA issue for this: http://jira.codehaus.org/browse/GRADLE-320
>
> It is possible to script an 'offline' mode in your build script.
> Here is an example which uses the maven central repository when
> online, and the local Gradle cache when offline:
>
> repositories {
> if (rootProject.hasProperty('offline')) {
> add(new FileSystemResolver()) {
> name = 'gradleCache'
> addArtifactPattern("${gradle.gradleUserHomeDir}/cache/$
> {ResolverContainer.DEFAULT_CACHE_ARTIFACT_PATTERN}")
> addIvyPattern("${gradle.gradleUserHomeDir}/cache/$
> {ResolverContainer.DEFAULT_CACHE_IVY_PATTERN}")
> }
> }
> else {
> repositories { mavenCentral() }
> }
> }
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

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

http://xircles.codehaus.org/manage_email

Re: classpath for ant.java and project jar

2009-11-10T08:13:43Z

On Nov 10, 2009, at 2:52 AM, Adam Murdoch wrote:

>
>
> Philip Crotwell wrote:
>> I am trying to create a task that will run java code that is built in
>> the current project. The user guide seems to indicate here:
>> http://gradle.org/0.8/docs/userguide/artifact_management.html#project_libraries
>> that the "default" configuration will be all runtime dependencies
>> plus
>> archives. I assumed that this meant that the default java artifact
>> jar
>> of my project would be part of "default" and so I could do something
>> like this:
>>
>> task makeSodSite(dependsOn: jar) << { task ->
>> myArgs = '--run-once -p sod.prop'
>> ant.java(dir:'build/output',
>> classname:'edu.sc.seis.seiswww.MakeSite',
>> args:myArgs,
>> fork:true,
>> classpath:configurations.default.asPath,
>>
>
> Try:
>
> classpath: sourceSets.main.runtimeClasspath.asPath
>
> This will include build/main/classes, plus the dependencies in
> configurations.runtime.
>
> You should also change the dependsOn to
>
> task makeSodSite(dependsOn: sourceSets.main.runtimeClasspath) << {
> ...
> }
>
> This will ensure everything in the runtimeClasspath has been built.
>
>> output:project.projectDir.path+'/build/output/
>> makeSodSite.out')
>> }
>>
>> But it doesn't work, with a NoClassDefFoundError. I put in a few
>> prints, like this:
>> println configurations.runtime.asPath
>> println configurations.archives.asPath
>> println configurations.default.asPath
>>
>> and found that runtime and default seem to be identical and
>> archives is empty.
>>
>> Should the default artifact created by the java plugin be part of the
>> default configuration?
>
> I think it should always include the jar. Oddly, if you add a
> project dependency on the default configuration from another
> project, then it does include the jar, but when you use it from the
> same project, it does not include the jar.

This is the Ivy way of viewing the world which leaks into Gradle here.
I agree that Gradle should behave differently here.

- Hans

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

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

http://xircles.codehaus.org/manage_email

From the pomGeneration example

2009-11-10T06:10:23Z

What the heck is up with group, group1, group2, group3 etc?

dependencies {
compile("group1:compile:1.0") {
exclude(group: 'excludeGroup', module: 'excludeArtifact')
}
providedCompile "group2:providedCompile:1.0@jar"
runtime "group3:runtime:1.0"
providedRuntime("group4:providedRuntime:1.0@zip") {
artifact {
name = 'providedRuntime-util'
type = 'war'
}
}
testCompile "group5:testCompile:1.0"
testRuntime "group6:testRuntime:1.0"
}

The mysteries of Gradle! haha

Roger

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

http://xircles.codehaus.org/manage_email

Re: How to do a copy filter the gradle way?

2009-11-10T06:01:34Z

Yes, it works. However, I don`t see any improvements of copying task from gradle. It doesn`t support even filtersfile and overwrite attributes. I`m going to use normal project.ant instead... Why not?
What is not working for me is replacing tokens in target folder without copying. "Copy" seems simply skipping task when source and target is the same. If Gradle could do that it will give performance and simpler scripts.

Steve Appling wrote:

Sorry, I had only looked at the ant ReplaceTokens documentation and not at the
source. It does not support a setPropertiesfile method to allow access to this
feature :(

But (again without having tried this myself) perhaps this is sufficient:

Properties props = new Props()
props.load(...)

copy {
from 'path_to_file_to_be_filtered'
into ...
filter(ReplaceTokens, tokens: props)
}

I'm not clear why Hans had a props.each surrounding the filter in his example.

Narco wrote:
> on gradle0.8 filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
> gives:
> Cause: Error - Invalid filter specification for
> org.apache.tools.ant.filters.ReplaceTokens
>
>
> Steve Appling wrote:
>>
>>
>> Hans Dockter wrote:
>>> On Nov 4, 2009, at 3:04 PM, Jason Porter wrote:
>>>
>>>> Sent from my iPhone
>>>>
>>>> On Nov 4, 2009, at 4:43, Levi Hoogenberg <levihoogenberg@gmail.com
>>>> <mailto:levihoogenberg@gmail.com>> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> I don't know if it's the Gradle way, but in one of my projects'
>>>>> build.gradle I have the following:
>>>>>
>>>>> processResources {
>>>>> filter(org.apache.tools.ant.filters.ReplaceTokens, tokens:
>>>>> [version: project.version])
>>>>> }
>>>>>
>>>>> This replaces @version@ in a property file, so that it can be read
>>>>> from the code.
>>> The processResources task is of type Copy.
>>>
>>> See
>>> Javadoc:
>>> http://gradle.org/0.8/docs/javadoc/index.html?org/gradle/api/tasks/Copy.html
>>>
>>> What you could do in your case:
>>>
>>> Properties props = new Props()
>>> props.load(...)
>>>
>>> copy {
>>> from 'path_to_file_to_be_filtered'
>>> into ...
>>> props.each { key, value ->
>>> filter(ReplaceTokens, tokens: props) // It depends on you set up
>>> if this is exactly what you want.
>>> }
>>> }
>>>
>>> - Hans
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project Manager
>>> http://www.gradle.org
>> I haven't tried this, but I think the ReplaceTokens filter can read from a
>> properties file all by itself so you can do:
>> copy {
>> from 'path_to_file_to_be_filtered'
>> into ...
>> filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
>> }
>>
>>
>>>>> Regards,
>>>>> Levi
>>>>>
>>>>> On Wed, Nov 4, 2009 at 7:46 AM, Jason Porter <
>>>>> <http://lightguard.jp/>lightguard.jp <http://lightguard.jp/>@
>>>>> <http://gmail.com/>gmail.com <http://gmail.com/>> wrote:
>>>>>
>>>>> In a war I've got I'd like to filter a file that ultimately ends
>>>>> up in
>>>>> the WEB-INF directory (chances are I'll just put it here under
>>>>> webapp/WEB-INF anyway), but I want to replace some tokens in it
>>>>> (preferably with items that exist in a properties file). I know
>>>>> how
>>>>> I'd do this in ant, but what's the gradle way of doing it?
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> Real Programmers think better when playing Adventure or Rogue.
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
>>>>> PGP key available at: <http://keyserver.net/>keyserver.net
>>>>> <http://keyserver.net/>, <http://pgp.mit.edu/>pgp.mit.edu
>>>>> <http://pgp.mit.edu/>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>
>>>>>
>>>>> <http://xircles.codehaus.org/manage_email>http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>> That would work fine, but I don't want to list the tokens and their
>>>> values in the build file. I'd rather have them pulled from a
>>>> properties file (so it can change from box / environment). Think stuff
>>>> like user names and passwords, external locations, etc.
>> --
>> Steve Appling
>> Automated Logic Research Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Re: Two questions

2009-11-10T05:30:39Z

Thanks for the insight. I'm coming from a "download them all and use
Ant" background :) I did some build scripts with Ivy in Summer 2008,
but that was about it (1.4.1 even).

I tried transitive=true to start things out, but was having so many
problems (spring + hibernate + transitive.. and things got interesting
fast hah).

But yeah, goal is to let it sort things out.. "trust the tool" :)

I've been using grails/groovy for a long time, so Gradle is a natural
fit.

It all started because I wanted to try Jboss RESTEasy.. which is like
90 jars (slight exaggeration).. and then 'only' provide the
dependencies for "what you need" via Maven.. and thus I figured.. time
to finally get this all worked out.

It is because of great user communities like this.. that these things
ahappen.

Roger

On Nov 10, 2009, at 8:21 AM, Steve Ebersole wrote:

> On Tue, 2009-11-10 at 08:00 -0500, Roger Studner wrote:
>> First.. just a simple "is this really how a dependencies() section
>> looks:
>> repositories {
>> mavenCentral()
>> }
>>
>> dependencies {
>> groovy 'org.codehaus.groovy:groovy:1.6.5'
>> compile group:'org.springframework', name:'spring',
>> version:'2.5.6'
>> compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
>> compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
>> compile group: 'org.hibernate', name: 'ejb3-persistence', version:
>> '1.0.2.GA'
>> compile group: 'org.hibernate', name: 'hibernate-annotations',
>> version: '3.4.0.GA'
>> compile group: 'org.hibernate', name: 'hibernate', version:
>> '3.2.1.ga'
>> compile group: 'org.hibernate', name: 'hibernate-entitymanager',
>> version: '3.4.0.GA'
>> compile group: 'org.hibernate', name: 'hibernate-commons-
>> annotations', version: '3.3.0.ga'
>> compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
>> compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
>> compile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
>> FINAL'
>> compile group: 'org.apache.poi', name:'poi-scratchpad',
>> version:'3.5-
>> FINAL'
>> compile group: 'log4j', name:'log4j', version:'1.2.15'
>> compile group: 'commons-logging', name: 'commons-logging', version:
>> '1.1.1'
>> testCompile group:'junit', name:'junit', version:'3.8.2'
>> testCompile group: 'junit', name: 'junit', version: '4.7'
>> testCompile group:'org.springframework', name:'spring',
>> version:'2.5.6'
>> testCompile group:'org.springframework', name:'spring-test',
>> version:'2.5.6'
>> testCompile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
>> testCompile group: 'org.slf4j', name: 'slf4j-log4j12', version:
>> '1.5.2'
>> testCompile group: 'org.hibernate', name: 'ejb3-persistence',
>> version: '1.0.2.GA'
>> testCompile group: 'org.hibernate', name: 'hibernate-annotations',
>> version: '3.4.0.GA'
>> testCompile group: 'org.hibernate', name: 'hibernate', version:
>> '3.2.1.ga'
>> testCompile group: 'org.hibernate', name: 'hibernate-entitymanager',
>> version: '3.4.0.GA'
>> testCompile group: 'org.hibernate', name: 'hibernate-commons-
>> annotations', version: '3.3.0.ga'
>> testCompile group: 'dom4j', name: 'dom4j', version: '1.6.1'
>> testCompile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
>> testCompile group: 'org.apache.poi', name:'poi-contrib',
>> version:'3.5-
>> FINAL'
>> testCompile group: 'org.apache.poi', name:'poi-scratchpad',
>> version:'3.5-FINAL'
>> testCompile group: 'log4j', name:'log4j', version:'1.2.15'
>> testCompile group: 'commons-logging', name: 'commons-logging',
>> version: '1.1.1'
>> }
> No, the configuration are "additive" following the pattern described
> at
> http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:java_plugin_and_dependency_management
>
> testCompile extends from compile meaning any dependency defined in
> compile is automatically available in testCompile.
>
> Also you should consider whether to utilize transitive dependencies.
> This really depends on taste a bit, bu personally, for example, I'd
> say
> to not specify dependency on hibernate-commons-annotations unless your
> project itself is actually using it. That is a "transitive
> dependency"
> that will be pulled into your project by both hibernate-annotations
> and
> hibernate-entity-manager. Same for slf4j, although there slf4j-
> log4j12
> should really be a runtime dep not s compile dep as well.
>
> --
> Steve Ebersole <steve@...>
> Hibernate.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

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

http://xircles.codehaus.org/manage_email

Re: Two questions

2009-11-10T05:22:32Z

Thanks Steve! I somehow avoided Maven (thankfully!) for so long.. but the aging Ant just can't keep up anymore. I did lots of projects with Ant/Ivy.. but now that i'm full speed on the Grails/Groovy train.. it is Gradle or bust.

Another thing I think is "hard" about picking up gradle, is that all the examples, on the web etc, always look soo different.

Like people doing thinks like this:

compile: "c3p0:c3p0:0.9.1.2"
03.compile: "com.fonterra.tams:msg-classes:1.0.0"
04.compile: "oracle.jdbc.driver:OracleDriver:10.2.0.3"
05.addDependency(['compile'], "org.apache.struts:struts-core:1.3.8" ) {
06.   exclude(module: 'commons-logging' )
07.}

(that is from Anthony's "convert Maven POM to Gradle script post)

I mean.. seeing "addDependency" which is a method on Configuration.. in the build.gradle.. versus then seeing all the 0.8 docs doing dependencies { }  (with the closure).

I know it ends up doing the same thing.. but man.. hurt the brain! (especially in the morning, before coffee.. very dangerous time hah)

Thanks for your quick response!

Roger

On Nov 10, 2009, at 8:17 AM, Steve Appling wrote:

Roger Studner wrote:
First.. just a simple "is this really how a dependencies() section looks:
repositories {
   mavenCentral()
}
dependencies {
   groovy 'org.codehaus.groovy:groovy:1.6.5'
   compile group:'org.springframework', name:'spring', version:'2.5.6'       compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
   compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
   compile group: 'org.hibernate', name: 'ejb3-persistence', version: '1.0.2.GA'
   compile group: 'org.hibernate', name: 'hibernate-annotations', version: '3.4.0.GA'
   compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
   compile group: 'org.hibernate', name: 'hibernate-entitymanager', version: '3.4.0.GA'
   compile group: 'org.hibernate', name: 'hibernate-commons-annotations', version: '3.3.0.ga'
   compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
   compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
   compile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-FINAL'
   compile group: 'org.apache.poi', name:'poi-scratchpad', version:'3.5-FINAL'       compile group: 'log4j', name:'log4j', version:'1.2.15'
   compile group: 'commons-logging', name: 'commons-logging', version: '1.1.1'       testCompile group:'junit', name:'junit', version:'3.8.2'
   testCompile group: 'junit', name: 'junit', version: '4.7'
   testCompile group:'org.springframework', name:'spring', version:'2.5.6'       testCompile group:'org.springframework', name:'spring-test', version:'2.5.6'       testCompile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
   testCompile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
   testCompile group: 'org.hibernate', name: 'ejb3-persistence', version: '1.0.2.GA'
   testCompile group: 'org.hibernate', name: 'hibernate-annotations', version: '3.4.0.GA'
   testCompile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
   testCompile group: 'org.hibernate', name: 'hibernate-entitymanager', version: '3.4.0.GA'
   testCompile group: 'org.hibernate', name: 'hibernate-commons-annotations', version: '3.3.0.ga'
   testCompile group: 'dom4j', name: 'dom4j', version: '1.6.1'
   testCompile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
   testCompile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-FINAL'
   testCompile group: 'org.apache.poi', name:'poi-scratchpad', version:'3.5-FINAL'       testCompile group: 'log4j', name:'log4j', version:'1.2.15'
   testCompile group: 'commons-logging', name: 'commons-logging', version: '1.1.1'   }
Basically, I took all the things in compile, and just duplicated them... Since most of the tests are integration (thus use spring/hibernate/poi etc).

testCompile extends compile, so you don't need to duplicate anything that is already in compile. Just add things needed only for tests (like Junit).

You may find the String notation for dependencies to be a little more compact for you:
    compile 'dom4j:dom4j:1.6.1'

Just wanting to make sure i'm not starting my adventures with Gradle like a fool hah.
Second...
I keep getting told I'm missing a dependency:
* What went wrong:
Execution failed for task ':test'.
Cause: Could not resolve all dependencies for configuration 'testRuntime':
   - download failed: javax.jms#jms;1.1!jms.jar
   - download failed: com.sun.jdmk#jmxtools;1.2.1!jmxtools.jar
   - download failed: com.sun.jmx#jmxri;1.2.1!jmxri.jar
(first, odd I need javax.jms.. Imean, since I use no JMS, of any kind, anywhere).
So, I go to mvnrepository.com, and I lookup the dependency.. and I add it.. something like
compile group:'javax.jms', name:'jms", version:"1.1"
and I do the same for testCompile.
I got the group/name/version from mvnrepository.com
Then, I get this error:
:: problems summary ::
:::: WARNINGS
       [NOT FOUND ] javax.jms#jms;1.1!jms.jar (470ms)
   ==== MavenRepo: tried
     http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.jar
       ::::::::::::::::::::::::::::::::::::::::::::::
       ::              FAILED DOWNLOADS            ::
       :: ^ see resolution messages for details ^ ::
       ::::::::::::::::::::::::::::::::::::::::::::::
       :: javax.jms#jms;1.1!jms.jar
       ::::::::::::::::::::::::::::::::::::::::::::::
I freely admit, I used ivy "some" and maven basically not at all. So possibly all these dependency quirks, sadly, are just "part of the problem" with trying to use a tool to resolve dependencies.
Anyone have any insight/tips to the above?
>
> Thanks,
> Roger
>
You are picking up a transitive dependency. Run a dependency report to see where it is coming from.
  gradle -q --dependencies

See http://gradle.org/0.8/docs/userguide/tutorial_gradle_command_line.html#para:commandline_dependency_report

Once you have found a transitive dependency you don't need, you can exclude it. See http://gradle.org/0.8/docs/userguide/dependency_management.html#sub:exclude_transitive_dependencies
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
  http://xircles.codehaus.org/manage_email

--
Steve Appling
Automated Logic Research Team

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

  http://xircles.codehaus.org/manage_email

Re: Two questions

2009-11-10T05:21:21Z

On Tue, 2009-11-10 at 08:00 -0500, Roger Studner wrote:

> First.. just a simple "is this really how a dependencies() section
> looks:
> repositories {
> mavenCentral()
> }
>
> dependencies {
> groovy 'org.codehaus.groovy:groovy:1.6.5'
> compile group:'org.springframework', name:'spring',
> version:'2.5.6'
> compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
> compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
> compile group: 'org.hibernate', name: 'ejb3-persistence', version:
> '1.0.2.GA'
> compile group: 'org.hibernate', name: 'hibernate-annotations',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
> compile group: 'org.hibernate', name: 'hibernate-entitymanager',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name: 'hibernate-commons-
> annotations', version: '3.3.0.ga'
> compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
> compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
> compile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
> FINAL'
> compile group: 'org.apache.poi', name:'poi-scratchpad', version:'3.5-
> FINAL'
> compile group: 'log4j', name:'log4j', version:'1.2.15'
> compile group: 'commons-logging', name: 'commons-logging', version:
> '1.1.1'
> testCompile group:'junit', name:'junit', version:'3.8.2'
> testCompile group: 'junit', name: 'junit', version: '4.7'
> testCompile group:'org.springframework', name:'spring',
> version:'2.5.6'
> testCompile group:'org.springframework', name:'spring-test',
> version:'2.5.6'
> testCompile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
> testCompile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
> testCompile group: 'org.hibernate', name: 'ejb3-persistence',
> version: '1.0.2.GA'
> testCompile group: 'org.hibernate', name: 'hibernate-annotations',
> version: '3.4.0.GA'
> testCompile group: 'org.hibernate', name: 'hibernate', version:
> '3.2.1.ga'
> testCompile group: 'org.hibernate', name: 'hibernate-entitymanager',
> version: '3.4.0.GA'
> testCompile group: 'org.hibernate', name: 'hibernate-commons-
> annotations', version: '3.3.0.ga'
> testCompile group: 'dom4j', name: 'dom4j', version: '1.6.1'
> testCompile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
> testCompile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
> FINAL'
> testCompile group: 'org.apache.poi', name:'poi-scratchpad',
> version:'3.5-FINAL'
> testCompile group: 'log4j', name:'log4j', version:'1.2.15'
> testCompile group: 'commons-logging', name: 'commons-logging',
> version: '1.1.1'
> }

No, the configuration are "additive" following the pattern described at
http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:java_plugin_and_dependency_management

testCompile extends from compile meaning any dependency defined in
compile is automatically available in testCompile.

Also you should consider whether to utilize transitive dependencies.
This really depends on taste a bit, bu personally, for example, I'd say
to not specify dependency on hibernate-commons-annotations unless your
project itself is actually using it. That is a "transitive dependency"
that will be pulled into your project by both hibernate-annotations and
hibernate-entity-manager. Same for slf4j, although there slf4j-log4j12
should really be a runtime dep not s compile dep as well.

--
Steve Ebersole <steve@...>
Hibernate.org

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

http://xircles.codehaus.org/manage_email

Re: Two questions

2009-11-10T05:17:53Z

Roger Studner wrote:

> First.. just a simple "is this really how a dependencies() section looks:
> repositories {
> mavenCentral()
> }
>
> dependencies {
> groovy 'org.codehaus.groovy:groovy:1.6.5'
> compile group:'org.springframework', name:'spring', version:'2.5.6'
> compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
> compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
> compile group: 'org.hibernate', name: 'ejb3-persistence', version:
> '1.0.2.GA'
> compile group: 'org.hibernate', name: 'hibernate-annotations',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
> compile group: 'org.hibernate', name: 'hibernate-entitymanager',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name:
> 'hibernate-commons-annotations', version: '3.3.0.ga'
> compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
> compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
> compile group: 'org.apache.poi', name:'poi-contrib',
> version:'3.5-FINAL'
> compile group: 'org.apache.poi', name:'poi-scratchpad',
> version:'3.5-FINAL'
> compile group: 'log4j', name:'log4j', version:'1.2.15'
> compile group: 'commons-logging', name: 'commons-logging', version:
> '1.1.1'
> testCompile group:'junit', name:'junit', version:'3.8.2'
> testCompile group: 'junit', name: 'junit', version: '4.7'
> testCompile group:'org.springframework', name:'spring',
> version:'2.5.6'
> testCompile group:'org.springframework', name:'spring-test',
> version:'2.5.6'
> testCompile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
> testCompile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
> testCompile group: 'org.hibernate', name: 'ejb3-persistence',
> version: '1.0.2.GA'
> testCompile group: 'org.hibernate', name: 'hibernate-annotations',
> version: '3.4.0.GA'
> testCompile group: 'org.hibernate', name: 'hibernate', version:
> '3.2.1.ga'
> testCompile group: 'org.hibernate', name: 'hibernate-entitymanager',
> version: '3.4.0.GA'
> testCompile group: 'org.hibernate', name:
> 'hibernate-commons-annotations', version: '3.3.0.ga'
> testCompile group: 'dom4j', name: 'dom4j', version: '1.6.1'
> testCompile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
> testCompile group: 'org.apache.poi', name:'poi-contrib',
> version:'3.5-FINAL'
> testCompile group: 'org.apache.poi', name:'poi-scratchpad',
> version:'3.5-FINAL'
> testCompile group: 'log4j', name:'log4j', version:'1.2.15'
> testCompile group: 'commons-logging', name: 'commons-logging',
> version: '1.1.1'
> }
>
> Basically, I took all the things in compile, and just duplicated them...
> Since most of the tests are integration (thus use spring/hibernate/poi
> etc).

testCompile extends compile, so you don't need to duplicate anything that is
already in compile. Just add things needed only for tests (like Junit).

You may find the String notation for dependencies to be a little more compact
for you:
compile 'dom4j:dom4j:1.6.1'

>
> Just wanting to make sure i'm not starting my adventures with Gradle
> like a fool hah.
>
> Second...
>
> I keep getting told I'm missing a dependency:
> * What went wrong:
> Execution failed for task ':test'.
> Cause: Could not resolve all dependencies for configuration 'testRuntime':
> - download failed: javax.jms#jms;1.1!jms.jar
> - download failed: com.sun.jdmk#jmxtools;1.2.1!jmxtools.jar
> - download failed: com.sun.jmx#jmxri;1.2.1!jmxri.jar
>
> (first, odd I need javax.jms.. Imean, since I use no JMS, of any kind,
> anywhere).
>
> So, I go to mvnrepository.com, and I lookup the dependency.. and I add
> it.. something like
> compile group:'javax.jms', name:'jms", version:"1.1"
>
> and I do the same for testCompile.
>
> I got the group/name/version from mvnrepository.com
>
> Then, I get this error:
>
> :: problems summary ::
> :::: WARNINGS
> [NOT FOUND ] javax.jms#jms;1.1!jms.jar (470ms)
>
> ==== MavenRepo: tried
>
> http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.jar
>
> ::::::::::::::::::::::::::::::::::::::::::::::
>
> :: FAILED DOWNLOADS ::
>
> :: ^ see resolution messages for details ^ ::
>
> ::::::::::::::::::::::::::::::::::::::::::::::
>
> :: javax.jms#jms;1.1!jms.jar
>
> ::::::::::::::::::::::::::::::::::::::::::::::
>
>
> I freely admit, I used ivy "some" and maven basically not at all. So
> possibly all these dependency quirks, sadly, are just "part of the
> problem" with trying to use a tool to resolve dependencies.
>
> Anyone have any insight/tips to the above?

>
> Thanks,
> Roger
>
You are picking up a transitive dependency. Run a dependency report to see
where it is coming from.
gradle -q --dependencies

See
http://gradle.org/0.8/docs/userguide/tutorial_gradle_command_line.html#para:commandline_dependency_report

Once you have found a transitive dependency you don't need, you can exclude it.
See
http://gradle.org/0.8/docs/userguide/dependency_management.html#sub:exclude_transitive_dependencies
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Semi-Progress update

2009-11-10T05:10:18Z

I solved the crazy javax.jms transitive dependency issue. Log4j
1.2.15 is not dependent on them. Boo Log4j.

Roger

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

http://xircles.codehaus.org/manage_email

Re: How to do a copy filter the gradle way?

2009-11-10T05:05:03Z

Sorry, I had only looked at the ant ReplaceTokens documentation and not at the
source. It does not support a setPropertiesfile method to allow access to this
feature :(

But (again without having tried this myself) perhaps this is sufficient:

Properties props = new Props()
props.load(...)

copy {
from 'path_to_file_to_be_filtered'
into ...
filter(ReplaceTokens, tokens: props)
}

I'm not clear why Hans had a props.each surrounding the filter in his example.

Narco wrote:

> on gradle0.8 filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
> gives:
> Cause: Error - Invalid filter specification for
> org.apache.tools.ant.filters.ReplaceTokens
>
>
> Steve Appling wrote:
>>
>>
>> Hans Dockter wrote:
>>> On Nov 4, 2009, at 3:04 PM, Jason Porter wrote:
>>>
>>>> Sent from my iPhone
>>>>
>>>> On Nov 4, 2009, at 4:43, Levi Hoogenberg <levihoogenberg@...
>>>> <mailto:levihoogenberg@...>> wrote:
>>>>
>>>>> Hi Jason,
>>>>>
>>>>> I don't know if it's the Gradle way, but in one of my projects'
>>>>> build.gradle I have the following:
>>>>>
>>>>> processResources {
>>>>> filter(org.apache.tools.ant.filters.ReplaceTokens, tokens:
>>>>> [version: project.version])
>>>>> }
>>>>>
>>>>> This replaces @version@ in a property file, so that it can be read
>>>>> from the code.
>>> The processResources task is of type Copy.
>>>
>>> See
>>> Javadoc:
>>> http://gradle.org/0.8/docs/javadoc/index.html?org/gradle/api/tasks/Copy.html
>>>
>>> What you could do in your case:
>>>
>>> Properties props = new Props()
>>> props.load(...)
>>>
>>> copy {
>>> from 'path_to_file_to_be_filtered'
>>> into ...
>>> props.each { key, value ->
>>> filter(ReplaceTokens, tokens: props) // It depends on you set up
>>> if this is exactly what you want.
>>> }
>>> }
>>>
>>> - Hans
>>>
>>> --
>>> Hans Dockter
>>> Gradle Project Manager
>>> http://www.gradle.org
>> I haven't tried this, but I think the ReplaceTokens filter can read from a
>> properties file all by itself so you can do:
>> copy {
>> from 'path_to_file_to_be_filtered'
>> into ...
>> filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
>> }
>>
>>
>>>>> Regards,
>>>>> Levi
>>>>>
>>>>> On Wed, Nov 4, 2009 at 7:46 AM, Jason Porter <
>>>>> <http://lightguard.jp/>lightguard.jp <http://lightguard.jp/>@
>>>>> <http://gmail.com/>gmail.com <http://gmail.com/>> wrote:
>>>>>
>>>>> In a war I've got I'd like to filter a file that ultimately ends
>>>>> up in
>>>>> the WEB-INF directory (chances are I'll just put it here under
>>>>> webapp/WEB-INF anyway), but I want to replace some tokens in it
>>>>> (preferably with items that exist in a properties file). I know
>>>>> how
>>>>> I'd do this in ant, but what's the gradle way of doing it?
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> Real Programmers think better when playing Adventure or Rogue.
>>>>>
>>>>> PGP key id: 926CCFF5
>>>>> PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
>>>>> PGP key available at: <http://keyserver.net/>keyserver.net
>>>>> <http://keyserver.net/>, <http://pgp.mit.edu/>pgp.mit.edu
>>>>> <http://pgp.mit.edu/>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>
>>>>>
>>>>> <http://xircles.codehaus.org/manage_email>http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>> That would work fine, but I don't want to list the tokens and their
>>>> values in the build file. I'd rather have them pulled from a
>>>> properties file (so it can change from box / environment). Think stuff
>>>> like user names and passwords, external locations, etc.
>> --
>> Steve Appling
>> Automated Logic Research Team
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Two questions

2009-11-10T05:00:25Z

First.. just a simple "is this really how a dependencies() section
looks:
repositories {
mavenCentral()
}

dependencies {
groovy 'org.codehaus.groovy:groovy:1.6.5'
compile group:'org.springframework', name:'spring',
version:'2.5.6'
compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
compile group: 'org.hibernate', name: 'ejb3-persistence', version:
'1.0.2.GA'
compile group: 'org.hibernate', name: 'hibernate-annotations',
version: '3.4.0.GA'
compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
compile group: 'org.hibernate', name: 'hibernate-entitymanager',
version: '3.4.0.GA'
compile group: 'org.hibernate', name: 'hibernate-commons-
annotations', version: '3.3.0.ga'
compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
compile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
FINAL'
compile group: 'org.apache.poi', name:'poi-scratchpad', version:'3.5-
FINAL'
compile group: 'log4j', name:'log4j', version:'1.2.15'
compile group: 'commons-logging', name: 'commons-logging', version:
'1.1.1'
testCompile group:'junit', name:'junit', version:'3.8.2'
testCompile group: 'junit', name: 'junit', version: '4.7'
testCompile group:'org.springframework', name:'spring',
version:'2.5.6'
testCompile group:'org.springframework', name:'spring-test',
version:'2.5.6'
testCompile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
testCompile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
testCompile group: 'org.hibernate', name: 'ejb3-persistence',
version: '1.0.2.GA'
testCompile group: 'org.hibernate', name: 'hibernate-annotations',
version: '3.4.0.GA'
testCompile group: 'org.hibernate', name: 'hibernate', version:
'3.2.1.ga'
testCompile group: 'org.hibernate', name: 'hibernate-entitymanager',
version: '3.4.0.GA'
testCompile group: 'org.hibernate', name: 'hibernate-commons-
annotations', version: '3.3.0.ga'
testCompile group: 'dom4j', name: 'dom4j', version: '1.6.1'
testCompile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
testCompile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
FINAL'
testCompile group: 'org.apache.poi', name:'poi-scratchpad',
version:'3.5-FINAL'
testCompile group: 'log4j', name:'log4j', version:'1.2.15'
testCompile group: 'commons-logging', name: 'commons-logging',
version: '1.1.1'
}

Basically, I took all the things in compile, and just duplicated
them... Since most of the tests are integration (thus use spring/
hibernate/poi etc).

Just wanting to make sure i'm not starting my adventures with Gradle
like a fool hah.

Second...

I keep getting told I'm missing a dependency:
* What went wrong:
Execution failed for task ':test'.
Cause: Could not resolve all dependencies for configuration
'testRuntime':
- download failed: javax.jms#jms;1.1!jms.jar
- download failed: com.sun.jdmk#jmxtools;1.2.1!jmxtools.jar
- download failed: com.sun.jmx#jmxri;1.2.1!jmxri.jar

(first, odd I need javax.jms.. Imean, since I use no JMS, of any kind,
anywhere).

So, I go to mvnrepository.com, and I lookup the dependency.. and I add
it.. something like
compile group:'javax.jms', name:'jms", version:"1.1"

and I do the same for testCompile.

I got the group/name/version from mvnrepository.com

Then, I get this error:

:: problems summary ::
:::: WARNINGS
[NOT FOUND ] javax.jms#jms;1.1!jms.jar (470ms)

==== MavenRepo: tried

http://repo1.maven.org/maven2/javax/jms/jms/1.1/jms-1.1.jar

::::::::::::::::::::::::::::::::::::::::::::::

:: FAILED DOWNLOADS ::

:: ^ see resolution messages for details ^ ::

::::::::::::::::::::::::::::::::::::::::::::::

:: javax.jms#jms;1.1!jms.jar

::::::::::::::::::::::::::::::::::::::::::::::

I freely admit, I used ivy "some" and maven basically not at all. So
possibly all these dependency quirks, sadly, are just "part of the
problem" with trying to use a tool to resolve dependencies.

Anyone have any insight/tips to the above?

Thanks,
Roger

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

http://xircles.codehaus.org/manage_email

Re: How to do a copy filter the gradle way?

2009-11-10T01:19:10Z

on gradle0.8 filter(ReplaceTokens, propertiesfile: 'mysettings.properties') gives:
Cause: Error - Invalid filter specification for org.apache.tools.ant.filters.ReplaceTokens

Steve Appling wrote:

Hans Dockter wrote:
>
> On Nov 4, 2009, at 3:04 PM, Jason Porter wrote:
>
>> Sent from my iPhone
>>
>> On Nov 4, 2009, at 4:43, Levi Hoogenberg <levihoogenberg@gmail.com
>> <mailto:levihoogenberg@gmail.com>> wrote:
>>
>>> Hi Jason,
>>>
>>> I don't know if it's the Gradle way, but in one of my projects'
>>> build.gradle I have the following:
>>>
>>> processResources {
>>> filter(org.apache.tools.ant.filters.ReplaceTokens, tokens:
>>> [version: project.version])
>>> }
>>>
>>> This replaces @version@ in a property file, so that it can be read
>>> from the code.
>
> The processResources task is of type Copy.
>
> See
> Javadoc: http://gradle.org/0.8/docs/javadoc/index.html?org/gradle/api/tasks/Copy.html
>
> What you could do in your case:
>
> Properties props = new Props()
> props.load(...)
>
> copy {
> from 'path_to_file_to_be_filtered'
> into ...
> props.each { key, value ->
> filter(ReplaceTokens, tokens: props) // It depends on you set up
> if this is exactly what you want.
> }
> }
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
I haven't tried this, but I think the ReplaceTokens filter can read from a
properties file all by itself so you can do:
copy {
from 'path_to_file_to_be_filtered'
into ...
filter(ReplaceTokens, propertiesfile: 'mysettings.properties')
}

>
>>>
>>> Regards,
>>> Levi
>>>
>>> On Wed, Nov 4, 2009 at 7:46 AM, Jason Porter <
>>> <http://lightguard.jp/>lightguard.jp <http://lightguard.jp/>@
>>> <http://gmail.com/>gmail.com <http://gmail.com/>> wrote:
>>>
>>> In a war I've got I'd like to filter a file that ultimately ends
>>> up in
>>> the WEB-INF directory (chances are I'll just put it here under
>>> webapp/WEB-INF anyway), but I want to replace some tokens in it
>>> (preferably with items that exist in a properties file). I know how
>>> I'd do this in ant, but what's the gradle way of doing it?
>>>
>>> --
>>> Jason Porter
>>> Real Programmers think better when playing Adventure or Rogue.
>>>
>>> PGP key id: 926CCFF5
>>> PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
>>> PGP key available at: <http://keyserver.net/>keyserver.net
>>> <http://keyserver.net/>, <http://pgp.mit.edu/>pgp.mit.edu
>>> <http://pgp.mit.edu/>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>
>>> <http://xircles.codehaus.org/manage_email>http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>> That would work fine, but I don't want to list the tokens and their
>> values in the build file. I'd rather have them pulled from a
>> properties file (so it can change from box / environment). Think stuff
>> like user names and passwords, external locations, etc.
>

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Re: classpath for ant.java and project jar

2009-11-09T17:52:48Z

Philip Crotwell wrote:

> I am trying to create a task that will run java code that is built in
> the current project. The user guide seems to indicate here:
> http://gradle.org/0.8/docs/userguide/artifact_management.html#project_libraries
> that the "default" configuration will be all runtime dependencies plus
> archives. I assumed that this meant that the default java artifact jar
> of my project would be part of "default" and so I could do something
> like this:
>
> task makeSodSite(dependsOn: jar) << { task ->
> myArgs = '--run-once -p sod.prop'
> ant.java(dir:'build/output',
> classname:'edu.sc.seis.seiswww.MakeSite',
> args:myArgs,
> fork:true,
> classpath:configurations.default.asPath,
>

Try:

classpath: sourceSets.main.runtimeClasspath.asPath

This will include build/main/classes, plus the dependencies in
configurations.runtime.

You should also change the dependsOn to

task makeSodSite(dependsOn: sourceSets.main.runtimeClasspath) << {
...
}

This will ensure everything in the runtimeClasspath has been built.

> output:project.projectDir.path+'/build/output/makeSodSite.out')
> }
>
> But it doesn't work, with a NoClassDefFoundError. I put in a few
> prints, like this:
> println configurations.runtime.asPath
> println configurations.archives.asPath
> println configurations.default.asPath
>
> and found that runtime and default seem to be identical and archives is empty.
>
> Should the default artifact created by the java plugin be part of the
> default configuration?

I think it should always include the jar. Oddly, if you add a project
dependency on the default configuration from another project, then it
does include the jar, but when you use it from the same project, it does
not include the jar.

Could you add a JIRA issue for this?

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

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

http://xircles.codehaus.org/manage_email

Re: Flat Dir repositories

2009-11-09T17:41:08Z

Roger Studner wrote:

> Can't seem to find much doc on this (probably in the 200 pages of
> docs.. which are great docs.. I just can't find it hah)
>
> I've successfully used maven repo's with my gradle builds.
>
> Was curious, for a flatDir repository, is it looking for a local
> filesystem that is built up like maven (pom's etc)..
>
> or what I see all the examples doing this:
>
> repositories {
> flatDir name: 'localRepository', dirs: 'lib'
> }
>
> Is it just looking for jar files in a folder called lib?
>

Pretty much. For each dependency that you declare in the build script,
Gradle will look for a corresponding file in the 'lib' directory. For
example, for a dependency on 'junit:junit:4.7', Gradle would look for
lib/junit-4.7.jar or lib/junit.jar. It assumes there are no transitive
dependencies.

> I am guessing the maven/pom route, only because how could it then
> resolve spring 2.5.6 "intelligently" from a lib folder that just
> luckily had exactly the right jars to support the group/name/version
> for spring.
>

They can be used along with client modules, where the transitive
dependency info is provided in the build script:
http://gradle.org/0.8/docs/userguide/dependency_management.html#sub:client_module_dependencies

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

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

http://xircles.codehaus.org/manage_email

classpath for ant.java and project jar

2009-11-09T13:06:46Z

I am trying to create a task that will run java code that is built in
the current project. The user guide seems to indicate here:
http://gradle.org/0.8/docs/userguide/artifact_management.html#project_libraries
that the "default" configuration will be all runtime dependencies plus
archives. I assumed that this meant that the default java artifact jar
of my project would be part of "default" and so I could do something
like this:

task makeSodSite(dependsOn: jar) << { task ->
myArgs = '--run-once -p sod.prop'
ant.java(dir:'build/output',
classname:'edu.sc.seis.seiswww.MakeSite',
args:myArgs,
fork:true,
classpath:configurations.default.asPath,
output:project.projectDir.path+'/build/output/makeSodSite.out')
}

But it doesn't work, with a NoClassDefFoundError. I put in a few
prints, like this:
println configurations.runtime.asPath
println configurations.archives.asPath
println configurations.default.asPath

and found that runtime and default seem to be identical and archives is empty.

Should the default artifact created by the java plugin be part of the
default configuration? Is there something besides depending on the jar
task that is required to get it there, or does it have to be done
manually? As an alternative, I could add "build/classes" to the
classpath manually, but that feels wrong to me.

Gradle 0.8

thanks,
Philip

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

http://xircles.codehaus.org/manage_email

Flat Dir repositories

2009-11-09T11:52:13Z

Begin forwarded message:

From: Roger Studner <rstudner@...>
Date: November 8, 2009 8:25:24 PM EST
To: user@...
Subject: Flat Dir repositories

Can't seem to find much doc on this (probably in the 200 pages of docs.. which are great docs.. I just can't find it hah)

I've successfully used maven repo's with my gradle builds.

Was curious, for a flatDir repository, is it looking for a local filesystem that is built up like maven (pom's etc)..

or what I see all the examples doing this:

repositories {
flatDir name: 'localRepository', dirs: 'lib'
}

Is it just looking for jar files in a folder called lib?

I am guessing the maven/pom route, only because how could it then resolve spring 2.5.6 "intelligently" from a lib folder that just luckily had exactly the right jars to support the group/name/version for spring.

Thanks
Roger

Re: Creating task descriptions

2009-11-09T11:07:19Z

It's done during the configuration phase, not when the task is executed. That
way it is available for the task list (-t) without executing any tasks. You can
set it in a configuration closure for a task (without the <<).

Russel Winder wrote:
> One can set the description attribute of a task in the parameter list:
>
> task blah ( description : 'Something.' ) << { . . . }
>
> but is there a way of setting the description in the closure that is the
> body of the task?
>
> Thanks.
>

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

Creating task descriptions

2009-11-09T11:03:07Z

One can set the description attribute of a task in the parameter list:

task blah ( description : 'Something.' ) << { . . . }

but is there a way of setting the description in the closure that is the
body of the task?

Thanks.

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

signature.asc (204 bytes) Download Attachment

Re: Flat Dir repositories

2009-11-09T00:42:27Z

As you assume it just looks for jars/wars/whatever in the 'lib' folder. It resolves versions by looking at the version number in the filename. for instance:

myveryownjar-1.2.0.jar

spring-2.5.6.jar

etc.

At least that is my experience. Maybe someone has a more detailed understanding.

Eske

2009/11/9 Roger Studner <rstudner@...>

Can't seem to find much doc on this (probably in the 200 pages of docs.. which are great docs.. I just can't find it hah)

I've successfully used maven repo's with my gradle builds.

Was curious, for a flatDir repository, is it looking for a local filesystem that is built up like maven (pom's etc)..

or what I see all the examples doing this:

repositories {
flatDir name: 'localRepository', dirs: 'lib'
}

Is it just looking for jar files in a folder called lib?

I am guessing the maven/pom route, only because how could it then resolve spring 2.5.6 "intelligently" from a lib folder that just luckily had exactly the right jars to support the group/name/version for spring.

Thanks
Roger

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

http://xircles.codehaus.org/manage_email

Re: Creating a distribution from multi-project

2009-11-08T21:32:25Z

Here are the exact steps I need:
1) Grab all the subprojects and combine the contents of their jar
artifacts into a new jar artifact.
2) Take that "uber jar", transitive dependencies, sources and
documentation and create the TGZ & ZIP archives

It sounds like, for now, you are saying I will in fact need to stage the
archive contents (or duplicate the "copy spec" definition) to create the
two archives. Am I reading that correctly?

Also I was curious whether your approach below wrt defining 'distLibs'
would cause all the referenced subprojects to be built all the time?

On Mon, 2009-11-09 at 10:02 +1100, Adam Murdoch wrote:

>
> Steve Ebersole wrote:
> > I am trying to figure out the best way to create my distribution against
> > a multi-project build. Two specific things I am unsure about:
> >
> > 1) I need to write out multiple distribution formats (ok 2 : zip and
> > tgz) but the contents will remain the same in each format. So obviously
> > I would like to define the source for these distribution archives just
> > once. The only thing I could think of was to manually create a
> > CopySpec, configure it appropriately and then manually call the Zip and
> > Tar
>
> This is pretty much the plan, but it's not quite implemented in trunk
> yet. It might work something like this:
>
> 1. allow the CopySpec for a task to be included in the CopySpec for another:
>
> task distZip(type: Zip) {
> from 'some-dir'
> include '...'
> ....
> }
>
> task DistTgz(type: Tar) {
> // Use the spec from distZip task
> from distZip.rootSpec
> compression = Compression.GZIP
> }
>
>
> 2. possibly provide some factory method for a copy spec:
>
> def distContents = copySpec {
> from 'some-dir'
> ...
> }
>
> task distZip(type: Zip) {
> from distContents
> }
>
> task distTgz(type: Tar) {
> from distContents
> compression = Compression.GZIP
> }
>
> > (does this only create the tar? is there an option to have it
> > create the gz?)
> >
>
> You use the compression property of the Tar task.
>
> > 2) I need the CopySpec, however it gets defined, to include stuff from
> > the subprojects. Specifically the artifact produced by the subproject
> > and its dependencies.
> >
>
> For the Gradle build, we use project dependencies for this, as we also
> want the transitive runtime dependencies. For example:
>
> configurations {
> distLibs
> }
>
> dependencies {
> distLibs project(path: ':subproject1'), project(':subproject2')
> }
>
> task distZip(type: Zip) {
> into('lib') {
> from configurations.distLibs
> }
> }
>
> This has the advantage that it drags in all the runtime jars, and the
> task dependencies are all automatically wired up for you.
>
> There are other ways of achieving similar things, depending on what you
> need.
>
>

--
Steve Ebersole <steve@...>
Hibernate.org

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

http://xircles.codehaus.org/manage_email

Flat Dir repositories

2009-11-08T17:25:24Z

Can't seem to find much doc on this (probably in the 200 pages of
docs.. which are great docs.. I just can't find it hah)

I've successfully used maven repo's with my gradle builds.

Was curious, for a flatDir repository, is it looking for a local
filesystem that is built up like maven (pom's etc)..

or what I see all the examples doing this:

repositories {
flatDir name: 'localRepository', dirs: 'lib'
}

Is it just looking for jar files in a folder called lib?

I am guessing the maven/pom route, only because how could it then
resolve spring 2.5.6 "intelligently" from a lib folder that just
luckily had exactly the right jars to support the group/name/version
for spring.

Thanks
Roger

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

http://xircles.codehaus.org/manage_email

Re: Creating a distribution from multi-project

2009-11-08T15:02:54Z

Steve Ebersole wrote:
> I am trying to figure out the best way to create my distribution against
> a multi-project build. Two specific things I am unsure about:
>
> 1) I need to write out multiple distribution formats (ok 2 : zip and
> tgz) but the contents will remain the same in each format. So obviously
> I would like to define the source for these distribution archives just
> once. The only thing I could think of was to manually create a
> CopySpec, configure it appropriately and then manually call the Zip and
> Tar

This is pretty much the plan, but it's not quite implemented in trunk
yet. It might work something like this:

1. allow the CopySpec for a task to be included in the CopySpec for another:

task distZip(type: Zip) {
from 'some-dir'
include '...'
....
}

task DistTgz(type: Tar) {
// Use the spec from distZip task
from distZip.rootSpec
compression = Compression.GZIP
}

2. possibly provide some factory method for a copy spec:

def distContents = copySpec {
from 'some-dir'
...
}

task distZip(type: Zip) {
from distContents
}

task distTgz(type: Tar) {
from distContents
compression = Compression.GZIP
}

> (does this only create the tar? is there an option to have it
> create the gz?)
>

You use the compression property of the Tar task.

> 2) I need the CopySpec, however it gets defined, to include stuff from
> the subprojects. Specifically the artifact produced by the subproject
> and its dependencies.
>

For the Gradle build, we use project dependencies for this, as we also
want the transitive runtime dependencies. For example:

configurations {
distLibs
}

dependencies {
distLibs project(path: ':subproject1'), project(':subproject2')
}

task distZip(type: Zip) {
into('lib') {
from configurations.distLibs
}
}

This has the advantage that it drags in all the runtime jars, and the
task dependencies are all automatically wired up for you.

There are other ways of achieving similar things, depending on what you
need.

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

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

http://xircles.codehaus.org/manage_email

Re: Gradle not building if there's no network connection

2009-11-08T14:47:30Z

Andrew Pietsch wrote:
> Hi there,
>
> I noticed the other day that my build fails while trying to update
> snapshot dependencies if there's no network connection. Since all the
> dependencies are in my cache is there anyway to make the build to
> continue?
>

No built-in way, yet. There's a JIRA issue for this:
http://jira.codehaus.org/browse/GRADLE-320

It is possible to script an 'offline' mode in your build script. Here is
an example which uses the maven central repository when online, and the
local Gradle cache when offline:

repositories {
if (rootProject.hasProperty('offline')) {
add(new FileSystemResolver()) {
name = 'gradleCache'

addArtifactPattern("${gradle.gradleUserHomeDir}/cache/${ResolverContainer.DEFAULT_CACHE_ARTIFACT_PATTERN}")

addIvyPattern("${gradle.gradleUserHomeDir}/cache/${ResolverContainer.DEFAULT_CACHE_IVY_PATTERN}")
}
}
else {
repositories { mavenCentral() }
}
}

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

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

http://xircles.codehaus.org/manage_email

Re: Can't seem to resolve junit, ever.

2009-11-07T18:07:47Z

HOLY.

My apologies.

My brain did this:

log4j =-> junit.

Somehow I almost think of these things as part of the JVM after too
many years of writing unit tests and using logging.

Sheesh... (crawling under rock now)

Roger

On Nov 7, 2009, at 8:58 PM, Paul Speed wrote:

> I'm just a newbie myself, but it looks like your code depends on
> log4j but that you don't have the dependency in your build file.
>
> -Paul
>
> Roger Studner wrote:
>> This is my dependencies from my build.gradle:
>> dependencies {
>> groovy 'org.codehaus.groovy:groovy:1.6.5'
>> compile 'org.springframework:spring:2.5.6' compile group:
>> 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
>> compile group: 'org.slf4j', name: 'slf4j-log4j12', version:
>> '1.5.2'
>> compile group: 'org.hibernate', name: 'ejb3-persistence',
>> version: '1.0.2.GA'
>> compile group: 'org.hibernate', name: 'hibernate-annotations',
>> version: '3.4.0.GA'
>> compile group: 'org.hibernate', name: 'hibernate', version:
>> '3.2.1.ga'
>> compile group: 'org.hibernate', name: 'hibernate-entitymanager',
>> version: '3.4.0.GA'
>> compile group: 'org.hibernate', name: 'hibernate-commons-
>> annotations', version: '3.3.0.ga'
>> compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
>> compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
>> compile group: 'org.apache.poi', name:'poi-contrib',
>> version:'3.5-FINAL'
>> compile group: 'org.apache.poi', name:'poi-scratchpad',
>> version:'3.5-FINAL' testCompile group:'junit', name:'junit',
>> version:'3.8.2'
>> testCompile group: 'junit', name: 'junit', version: '4.+'
>> }
>> I've tried compile vs testCompile for both junit lines... I've
>> tried using one and not the other.
>> What I do gradle build, in the compileGroovy step (it is a mixed
>> java/groovy project) I see these (many):
>> /Users/someone/com/project/src/main/groovy/com/project//excel/
>> Workbook.groovy: 41: unable to resolve class org.apache.log4j.Logger
>> @ line 41, column 7.
>> logger.error(e1);
>> Every class that uses it, has this error.
>> Any ideas :)?
>> Thanks,
>> Roger
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>> http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

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

http://xircles.codehaus.org/manage_email

Re: Can't seem to resolve junit, ever.

2009-11-07T17:58:58Z

I'm just a newbie myself, but it looks like your code depends on log4j
but that you don't have the dependency in your build file.

-Paul

Roger Studner wrote:

> This is my dependencies from my build.gradle:
>
> dependencies {
> groovy 'org.codehaus.groovy:groovy:1.6.5'
> compile 'org.springframework:spring:2.5.6'
> compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
> compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
> compile group: 'org.hibernate', name: 'ejb3-persistence', version:
> '1.0.2.GA'
> compile group: 'org.hibernate', name: 'hibernate-annotations',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
> compile group: 'org.hibernate', name: 'hibernate-entitymanager',
> version: '3.4.0.GA'
> compile group: 'org.hibernate', name:
> 'hibernate-commons-annotations', version: '3.3.0.ga'
> compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
> compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
> compile group: 'org.apache.poi', name:'poi-contrib',
> version:'3.5-FINAL'
> compile group: 'org.apache.poi', name:'poi-scratchpad',
> version:'3.5-FINAL'
> testCompile group:'junit', name:'junit', version:'3.8.2'
> testCompile group: 'junit', name: 'junit', version: '4.+'
> }
>
> I've tried compile vs testCompile for both junit lines... I've tried
> using one and not the other.
>
> What I do gradle build, in the compileGroovy step (it is a mixed
> java/groovy project) I see these (many):
>
> /Users/someone/com/project/src/main/groovy/com/project//excel/Workbook.groovy:
> 41: unable to resolve class org.apache.log4j.Logger
> @ line 41, column 7.
> logger.error(e1);
> Every class that uses it, has this error.
>
> Any ideas :)?
>
> Thanks,
> Roger
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

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

http://xircles.codehaus.org/manage_email

Can't seem to resolve junit, ever.

2009-11-07T17:56:34Z

This is my dependencies from my build.gradle:

dependencies {
groovy 'org.codehaus.groovy:groovy:1.6.5'
compile 'org.springframework:spring:2.5.6'
compile group: 'org.slf4j', name: 'slf4j-api', version: '1.5.2'
compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.5.2'
compile group: 'org.hibernate', name: 'ejb3-persistence', version:
'1.0.2.GA'
compile group: 'org.hibernate', name: 'hibernate-annotations',
version: '3.4.0.GA'
compile group: 'org.hibernate', name: 'hibernate', version: '3.2.1.ga'
compile group: 'org.hibernate', name: 'hibernate-entitymanager',
version: '3.4.0.GA'
compile group: 'org.hibernate', name: 'hibernate-commons-
annotations', version: '3.3.0.ga'
compile group: 'dom4j', name: 'dom4j', version: '1.6.1'
compile group: 'org.apache.poi', name:'poi', version:'3.5-FINAL'
compile group: 'org.apache.poi', name:'poi-contrib', version:'3.5-
FINAL'
compile group: 'org.apache.poi', name:'poi-scratchpad', version:'3.5-
FINAL'
testCompile group:'junit', name:'junit', version:'3.8.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}

I've tried compile vs testCompile for both junit lines... I've tried
using one and not the other.

What I do gradle build, in the compileGroovy step (it is a mixed java/
groovy project) I see these (many):

/Users/someone/com/project/src/main/groovy/com/project//excel/
Workbook.groovy: 41: unable to resolve class org.apache.log4j.Logger
@ line 41, column 7.
logger.error(e1);
Every class that uses it, has this error.

Any ideas :)?

Thanks,
Roger

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

http://xircles.codehaus.org/manage_email

Re: Produce multiple jars from the same project

2009-11-07T12:17:11Z

ptornagh wrote:

> I'm currently porting and our current build system to gradle and have the
> following situation:
>
> One of the projects contains two source directories (2 packages) and
> produces two jar files (one for each source directory).
>
> example:
> com.mycompany.package1
> com.mycompany.package2
>
>

Do these packages share the same parent directory? I'm going to assume
they do.

> I want gradle to produce 1 jar for each package...how can I do?
>
> I know that ideally these would be two seperate projects (or subprojects)
> but I would like to avoid that option at the moment.
>
>

You don't have to split them into separate projects if you don't want.
It's not necessarily the best way to go if the 2 sets of source are
closely related. Gradle quite happily deals with projects that produce
more than one artifact.

There's a couple of approaches to your problem. One approach is to
compile everything in one go, and generate separate jars. Assuming all
source is under 'src/main/java', you really only need to do:

jar {
include 'com/mycompany/package1/**'
}

task otherJar(type: Jar) {
from sourceSets.main.classes
include 'com/mycompany/package2/**'
// you will need something to distinguish this jar from the other,
one of:
// baseName = 'myotherjar'
// classifier = 'someclassifier'
// customName = 'myotherjar.jar'
}

The other approach is to add a source set for each of the packages. This
is useful if the 2 packages need to be compiled with different compile
classpaths, for example.

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

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

http://xircles.codehaus.org/manage_email

Creating a distribution from multi-project

2009-11-07T06:54:56Z

I am trying to figure out the best way to create my distribution against
a multi-project build. Two specific things I am unsure about:

1) I need to write out multiple distribution formats (ok 2 : zip and
tgz) but the contents will remain the same in each format. So obviously
I would like to define the source for these distribution archives just
once. The only thing I could think of was to manually create a
CopySpec, configure it appropriately and then manually call the Zip and
Tar (does this only create the tar? is there an option to have it
create the gz?)

2) I need the CopySpec, however it gets defined, to include stuff from
the subprojects. Specifically the artifact produced by the subproject
and its dependencies.

This is trying to replace a Maven assembly if that sheds light on what I
am trying to do.

I realize I could "stage" the archive contents and then do the Zip/Tar
tasks against the staged contents, but I'd rather avoid that if I can.

Thanks

--
Steve Ebersole <steve@...>
Hibernate.org

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

http://xircles.codehaus.org/manage_email

Gradle not building if there's no network connection

2009-11-06T14:15:44Z

Hi there,

I noticed the other day that my build fails while trying to update snapshot dependencies if there's no network connection. Since all the dependencies are in my cache is there anyway to make the build to continue?

Cheers
Andrew

Re: Gradle or Buildr?

2009-11-06T13:55:37Z

* A good gwt plugin - gwt compile/run. This is simple enough since it has a ant task.

I've written a gwt plugin for myself (compile, shell, gwt-test) and would be happy to share it, although it's in a "works for me" state and would need someone better at both gradle and gwt to make it more 'production ready'.

Cheers
Andrew

Re: A couple questions

2009-11-06T11:04:18Z

ewhauser wrote:
> I've been working on a Gradle script for the last few days and have
> successfully: setup dependencies, call optional Ant tasks, use buildSrc,
> etc. However, there are a couple of things I could not figure out from the
> docs that would allow me to clean up my script a bit:
>
> 1. Can you invoke a task from inside another task programatically?
While it is possible to execute a task from another, I think you would have to
use an internal method to do so (AbstractTask.execute). I would not recommend
doing this.

Most of the time these needs can be met by factoring some of the body of a task
out into a shared groovy method (this is just a DSL on top of groovy after all),
or using task dependency.

> 2. How do you set a property from inside a task and retrieve it from another
> task? I tried using the DSL setProperty method, but it complained every
> time saying the property did not exist. I just used system properties as a
> temporary workaround.

task sometask << {
sometask.myprop = 'dynamic property'}

task anothertask << { println "from anothertask,
sometask.myprop=${sometask.myprop}" }

--
Steve Appling
Automated Logic Research Team

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

http://xircles.codehaus.org/manage_email

A couple questions

2009-11-06T10:09:30Z

I've been working on a Gradle script for the last few days and have successfully: setup dependencies, call optional Ant tasks, use buildSrc, etc. However, there are a couple of things I could not figure out from the docs that would allow me to clean up my script a bit:

1. Can you invoke a task from inside another task programatically?
2. How do you set a property from inside a task and retrieve it from another task? I tried using the DSL setProperty method, but it complained every time saying the property did not exist. I just used system properties as a temporary workaround.

Thanks.

Produce multiple jars from the same project

2009-11-06T07:47:38Z

I'm currently porting and our current build system to gradle and have the following situation:

One of the projects contains two source directories (2 packages) and produces two jar files (one for each source directory).

example:
com.mycompany.package1
com.mycompany.package2

I want gradle to produce 1 jar for each package...how can I do?

I know that ideally these would be two seperate projects (or subprojects) but I would like to avoid that option at the moment.

Thanks a lot.