http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11374 <pre>Relevant links: * http://wiki.gradle.org/display/GRADLE/Cookbook#Cookbook-Howtorefertomultipleartifactswithinthesamemodule * http://issues.gradle.org/browse/GRADLE-560 ----- Best regards, Evgeny evgeny-goldin.com -- View this message in context: http://gradle.1045684.n5.nabble.com/Gradle-analog-to-Ivy-dependency-include-tp5709837p5709841.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> evgenyg 2012-05-24T14:12:20 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11373 <pre>Right, it works. Thank you! ----- Best regards, Evgeny evgeny-goldin.com -- View this message in context: http://gradle.1045684.n5.nabble.com/Gradle-analog-to-Ivy-dependency-include-tp5709837p5709840.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> evgenyg 2012-05-24T12:47:56 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11372 <pre>Evgeny, Looks like this should help: dependencies { compile('org:bt343:lastSuccessful') { artifact { name='core-upsource/annotations'; type = 'jar' } } } On Thu, May 24, 2012 at 3:00 PM, evgenyg &lt;evgenyg-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Nikita Skvortsov 2012-05-24T11:34:41 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11371 <pre>Here's my "build.gradle": https://github.com/evgeny-goldin/teamcity-download-examples/blob/master/build.gradle ----- Best regards, Evgeny evgeny-goldin.com -- View this message in context: http://gradle.1045684.n5.nabble.com/Gradle-analog-to-Ivy-dependency-include-tp5709837p5709838.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> evgenyg 2012-05-24T11:00:30 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11370 <pre>Hi, In "ivy.xml" I have the following dependency declaration: How can I add this http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency-include.html "inclide" part to Gradle? I can go but then it downloads http://teamcity.jetbrains.com/guestAuth/repository/download/bt343/latest.lastSuccessful/teamcity-ivy.xml all dependencies while I need only one. Thanks! ----- Best regards, Evgeny evgeny-goldin.com -- View this message in context: http://gradle.1045684.n5.nabble.com/Gradle-analog-to-Ivy-dependency-include-tp5709837.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> evgenyg 2012-05-24T10:45:05 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11369 <pre>We have a similar property in our build scripts. I set it up a bit differently. A developer can drop a developer.properties file in their workspace that can override defaults that are in the gradle.properties file. After that our approaches are the same. The developer can use a develop-example.properties file as a starting point. I have to admit I like the gradle-example.properties approach since it doesn't require any coding support in the build scripts. I am assuming all the defaults are probably in the gradle-example.properties file? I will try that out in the next project and see how I like it. These approaches make on-boarding a developer really easy. You tell them just run a gradle setupEnvironment task and they are off the races. I haven't taken it as far as setting up things like Tomcat but to be honest that might be just a matter of time. I can throw away that painful Word document that tells a developer how to setup their environment. On Wed, May 23, 2012 at 12:44 AM, Ken Sipe &lt;kensipe</pre> Jason Hatton 2012-05-23T06:07:44 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11368 <pre>Ken, I agree that there are valid reasons to use gradle.properties. My comments were mostly related to adding additional properties files like dependencies.properties. For settings that are specific to both user and build, I sometimes do this: def userGradleScript = file("gradle/${System.getProperty("user.name")}.gradle") if (userGradleScript.exists()) { apply from: userGradleScript } Now everyone can have his &lt;username&gt;.gradle, and can even check it in (assuming usernames are unique). -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: &lt; at &gt;pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Best-Practices-for-storing-common-configuration-values-tp5709823p5709834.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> Peter Niederwieser 2012-05-23T06:04:14 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11367 <pre>Peter, I do see a value in property files... The gradle.properties file is auto read... so if it isn't there, there isn't a failure... if it is it is used. I use this for properties that are based on individual preference... then I check-in a gradle-example.properties file for the preferred structure. Example: tomcat_dir = /opt/appservers/apache-tomcat-6.0.35 This property is in the gradle.properties file... but isn't checked in... it is specific to my env. Your approach makes sense to me... but do you have a suggestion for this need? Ken Sipe | kensipe-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org | blog: http://kensipe.blogspot.com On May 22, 2012, at 4:35 PM, Peter Niederwieser wrote: </pre> Ken Sipe 2012-05-23T05:44:53 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11366 <pre> Robert Fischer wrote Yes it would. In the case of dependency declarations I don't see a benefit though. -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: &lt; at &gt;pniederw -- View this message in context: http://gradle.1045684.n5.nabble.com/Best-Practices-for-storing-common-configuration-values-tp5709823p5709832.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> Peter Niederwieser 2012-05-23T05:37:26 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11365 <pre>Yeah, I was thinking something like Lift's approach to configuration files, where a series of conventional ones are applied in order (if they exist). At the time when I wrote the plugin, there wasn't "apply from:". Hence the properties files. Could you do "apply from:configFile, to:dependencies"? Would that effectively get you within the dependencies block? ~~ Robert. On Tue, May 22, 2012 at 6:54 PM, Jason Hatton &lt;jashatton-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Fischer 2012-05-23T01:09:38 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11364 <pre>Yeah that aligns with the direction I was thinking for dependencies. What about environment type stuff like databases setup related items or target environment config files? Probably especially those that might not have a viable plugin. Thinking out loud, Jas On May 22, 2012, at 4:35 PM, Peter Niederwieser &lt;pniederw-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Jason Hatton 2012-05-22T23:54:40 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11363 <pre>My recommendation is to keep most, if not all, information in Gradle build scripts. In most cases, I see little value in moving information into a properties file. You lose a lot of flexibility, but what exactly do you gain? You might just as well move the information into a separate .gradle file, a mechanism that is supported out-of-the-box. To give an example, for dependency management I often introduce a dependencies.gradle with content like this: ext.libs = [ junit: "junit:junit:4.10", spring_core: "org.springframework:spring-core:3.1.0.RELEASE", ... ] I then apply this script to the main build script with: apply from: "properties.gradle" And use it like this: dependencies { compile libs.spring_core testCompile libs.junit } Keeping dependency declarations in a build script has several advantages over a properties file: - No code needed for handling properties files - No pollution of global namespace (all properties are prefixed with "libs") - Full Groovy/Gradle language at your disposal </pre> Peter Niederwieser 2012-05-22T21:35:46 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11362 <pre>Yeah. On my list is to pull from multiple property files (a la Lift), and to support *.properties (loaded via Properties#load), *.groovy (executed, and top-level variables are mapped to values), and *.gradle (apply to:'ed) files. I'm currently working on some fixes for Spring-Batch, then a Grails plugin, but as soon as that's done, I'll double back to this. ~~ Robert. On Tue, May 22, 2012 at 3:00 PM, Jason Hatton &lt;jashatton-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Fischer 2012-05-22T20:42:04 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11361 <pre>I figured someone else had already started down that road. I will take a look and maybe see how I can fit that in. I think it is definitely a plugin worth investing in. I thought of doing something as well but, plugins aren't at the top of list of projects usually :). This might be good because it is something I can slowly iterate on. I actually think this is something a future version of Gradle should support because this is going to be a sore spot in the future once we get awesome easy to manage build scripts. Jas On Tue, May 22, 2012 at 12:49 PM, Robert Fischer &lt; robert.fischer-PhQ5OvVyDpbEbydl4kn8rAC/G2K4zDHf&lt; at &gt;public.gmane.org&gt; wrote: </pre> Jason Hatton 2012-05-22T20:00:40 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11360 <pre>I've got the DepNamePlugin which I was planning on spinning out into its own plugin and refining. For the moment, it's packaged into my gradle-plugins. It was intended to solve this bit of annoyance. https://github.com/RobertFischer/gradle-plugins ~~ Robert. On Tue, May 22, 2012 at 10:41 AM, Jason Hatton &lt;jashatton-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Robert Fischer 2012-05-22T17:49:05 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11359 <pre>I guess I sent this by accident. I hadn't finished my example on how to share lists of dependences see the completed version here: On Tue, May 22, 2012 at 10:38 AM, Jason Hatton &lt;jashatton-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; wrote: } </pre> Jason Hatton 2012-05-22T15:41:00 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11358 <pre>I am curious about what others are doing in their projects to store common configuration values. Please give feedback on your approaches and I welcome opinions on the approaches I am sharing here. I use the dynamic properties capability heavily to share common configuration values and, I take advantage of the gradle.properties file do achieve this. With the recent switch to "moving away" from dynamic properties is this solution future proof? Here are examples of how I do it and questions related to it. 1. Holding version numbers in gradle.properties like: SPRING_VERSION=3.0 HIBERNATE=3.4 So you would see in the build.gradle something like this: dependencies { compile { [group: 'org.springframework', name: 'spring-context', version: "$SPRING_VERSION"], [group: 'org.springframework', name: 'spring-jdbc', version: "$SPRING_VERSION"], [group: 'org.hibernate', name: 'hibernate', version: "$HIBERNATE_VERSION"], [group: 'org.hibernat</pre> Jason Hatton 2012-05-22T15:38:10 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11357 <pre>Ok Daz thank you. I will keep my eyes on GRADLE-2318. -- View this message in context: http://gradle.1045684.n5.nabble.com/Can-not-resolve-artifacts-with-dynamic-revisions-from-Ivy-repository-tp5680421p5709816.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> Milan Papzilla 2012-05-21T13:49:57 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11356 <pre>Ok Daz thank you. I will keep my eyes on GRADLE-2318. -- View this message in context: http://gradle.1045684.n5.nabble.com/Can-not-resolve-artifacts-with-dynamic-revisions-from-Ivy-repository-tp5680421p5709815.html Sent from the gradle-user mailing list archive at Nabble.com. </pre> Milan Papzilla 2012-05-21T13:49:57 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11355 <pre>Hi Milan It looks like you have found a bug in Gradle. We are using org.apache.ivy.util.url.ApacheURLLister to obtain a list of versions from a directory listing, and this code is not using the supplied credentials. I've raised http://issues.gradle.org/browse/GRADLE-2318 for this issue. Thanks for the report. cheers Daz On 7 May 2012 08:32, Milan Papzilla &lt;papicino-gM/Ye1E23mwN+BqQ9rBEUg&lt; at &gt;public.gmane.org&gt; wrote: </pre> Daz DeBoer 2012-05-19T05:30:49 http://permalink.gmane.org/gmane.comp.programming.tools.gradle.user/11354 <pre>Correct, my instructions say to use -all (which now I think of it, should be -bin). On 17/05/2012, at 4:06 PM, Jason Hatton wrote: </pre> Luke Daley 2012-05-17T15:49:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.programming.tools.gradle.user