hi gradle-users,
we use an inhouse-built buildsystem that is
based on ant+ivy+hudson. this works quite good. but
as always and everywhere ... improvement is possible.
so, after reading the gradle-usersguide, i decided to
give gradle a try.
as we already use ivy, we have a set of common-used i
ok thanks. i will watch it. its easy for me to live with
that prospect for now. if its an essential requirement,
time will come to implement it the right way ...
--
View this message in context:
http://www.nabble.com/configuring-gradle-from-ivysettings.xml---tp19212832p19226246.html
Sent from t
hello gradle-users,
is there a decent way, to let gradle retrieve lib-sources
to the ide-workspace (or another proper location), so that
a comfortable debug into thirdparty-code is possible ?
in our 'pre-gradle' ;-) builds we do kind of this:
(we retrieve all artifacts
repository .
im afraid there is another topic in my mind, that i will ask stupid
questions
about soon: release-build ;-) ... sometimes stupid questions are helpful
too, are'nt they ?
thank you & have a successful day
hdockter wrote:
>
> Hi Helmut,
>
> On Sep 2, 200
hello gradle,
some remarks on release-management as i saw this is an
item on gradle's road-map ... this may help to identify or
exclude gradle requirements and/or to identify possible
improvements in my companys release-management-process.
i think traditionally there are 2 different kinds of vi
hi gradle users,
to share common resolver-setup across multiple gradle-builds
i implemented a class 'ResolverSetup' and use it like this:
*** schnipp ***
subprojects {
usePlugin('groovy')
sourceCompatibility = 1.4
targetCompatibility = 1.4
group = 'com.mycompany'
v
hallo hans,
very helpful. thanks.
i'll try it out and give feedback.
have a nice weekend.
--
View this message in context:
http://www.nabble.com/common-resolver-setup-across-multiple-gradle-builds-tp19570795p19582901.html
Sent from the gradle-user mailing list archive at Nabble.com.
---
hallo hans,
hdockter wrote:
>
> I'm not sure if it would make sense to provide a framework for
> complex release management ...
>
i think you are right.
IMO a possible use-case for gradle or ivy, is 'deployment-tooling'.
gradle can be used to support the implementation of
a deploy-tool,
hallo hans,
i put everything in plugins and it seems to work.
build.gradle now looks like this:
subprojects {
usePlugin('custom-groovy')
sourceCompatibility = 1.4
targetCompatibility = 1.4
group = 'com.mycompany'
version = '1.0'
}
for those who are interested in d
hdockter wrote:
>
> I think the default should be that regardless of the name
> any executable TestCase should be executed.
>
yes, this sounds like a better solution than
the class-name-filter-pattern.
-> increasing the abstraction-level over unit-testing-tools
(junit3, junit4, testng).
there is already a jira regarding this:
http://jira.codehaus.org/browse/GRADLE-243
default-pattern should IMO be:
test {
include '**/*.Test.class'
include '**/*.Tests.class'
exclude '**/Abstract*'
}
-> different people want to have different
defaults per gradle-installation ...
hi,
levi_h wrote:
>
> how do you (or other Eclipse users who might read this) handle the
> filtering case you described
> when you're running tests inside Eclipse?
>
i do not have /src/main/resources or /src/test/resources
registered as eclipse 'Source-Folders'.
if something changes in the
to automate this, a eclipse-plugin could
hook into eclipse and do a 'gradle resources'
when appropriate.
gradle should have some kind of embedded-mode
to save startup-time then ... i think i have read
about embedded-mode somewhere in the docs but
don't remember where it was
very interesting discussion ...
russel does a great job in promoting gradle.
this is esp. remarkable as there were/are 'tensions'
between gant and gradle - as he expresses himself.
dportello wrote:
>
> Very exciting news, I believe this project has great potential. It
> certainly
> has solv
an article, that may be worth an eye:
http://groovy.dzone.com/articles/fusemetrics-build-metrics-dash
--
View this message in context:
http://www.nabble.com/fusemetrics---Build-Metrics-Dashboard-tp19896364p19896364.html
Sent from the gradle-user mailing list archive at Nabble.com.
---
hi gradle-users,
i try to express dependencies like this with gradle:
how do i express: conf="compile->runtime" ?
i tried:
dependencies {
dependency(['compile->runtime'],"javax.servlet:com.springsource.javax.servlet:2.4.0")
}
but have no luck so far.
thank you and have a nice da
hallo martin,
hallo hans
the suggested workaround seems to work.
thanks
--
View this message in context:
http://www.nabble.com/how-to-express-configuration-mappingtp20118174p20126802.html
Sent from the gradle-user mailing list archive at Nabble.com.
--
hi gradle-users,
i try to migrate a build for a spring-webflow-project that
resolves artefacts from http://www.springsource.com/repository.
i noticed that i get a NPE if some of the dependencys can not
be resolved ...
if i do the same build with pure ant+ ivy i get a message what
artifacts cou
if i fix the dependencys so that they can be resolved by
gradle, no NPE is thrown ...
i get a compile-error then, but that's not a gradle-
problem ... ;-)
--
View this message in context:
http://www.nabble.com/NullPointerException-if-dependencys-can-not-be-resolved-tp20128584p20128783.html
Se
you may want to take a look at
http://www.nabble.com/common-resolver-setup-across-multiple-gradle-builds-td19570795.html
further improvement:
i put the gradle-customizations.jar
into the $GRADLE_HOME/libs.
mvlcek wrote:
>
> In my build script I have written a function to configure the buil
i would like to do that too ...
for now i build a customized gradle-distribution (zip)
and publish it on a shared volumn.
gradle-users are triggered by mail if distribution has
changed.
mvlcek wrote:
>
> Thank you, I know that I can customize a plugin or add code in buildSrc.
>
> However, th
hi gradle-users,
how can i set 'dual' and 'returnFirst' Attributes
for a resolver-chain in my build.gradle ?
i tried:
project.getDependencies().setChainConfigurer {
...
}
but was n
Oct 28, 2008, at 11:30 AM, Helmut Denk wrote:
>
>>
>> hi gradle-users,
>>
>> how can i set 'dual' and 'returnFirst' Attributes
>> for a resolver-chain in my build.gradle ?
>>
>>
>>
>>
>>
hi gradle,
running with the trunk (teamcity-windows-build #488) i get
numbers of error-messages 'error in opening zip file'.
the build runs successful nevertheless.
grüsse
-
| |mo
Russel Winder-4 wrote:
>
> Is that actually necessary to have the jars in the Gradle repository,
> is it not possible to use Ivy to get the jars as needed so as to avoid
> having them in the Gradle repository?
>
where would you get the artifacts from then ?
security aspects do'nt allow 'u
Russel Winder-4 wrote:
>
> The implication here is that you run your own repository internally
> behind the corporate firewall. This can then be populated with chosen
> materials that are trusted. This is no different from downloading
> Gradle and trusting it. Or am I missing something?
>
n
hi gradle,
*item 1*
just a note on the 'Unable to delete file'-problem:
after manual deletion of the .gradle dirs
gradle-0.5.1 works fine for me under windows-xp.
*item 2*
as there are some investigation of gradle on
windows going on ...
another thing i noticed when building todays trunk
according to my testruns the exitcode of the 'bad'-call
is 1 and the the exitcode of the 'good'-call is 0.
F:\workspaces\current\gradle-test\some-utils>gradle --version
Gradle 0.6-20090107152318+0100
-
hi gradle-community,
this may be a known issue ... its not critical IMO
because it can be overcome by simply repeating the
command.
running gradle 0.5.2 under xp i get sporadic errors
like this:
>gradle libs
:preisliste-common:init
:preisliste-common:resources
:preisliste-common:compile
:p
hi gradle,
i have a project like this:
-D myproject
-D common
-D componentA
-D componentB
where 'componentA' and 'componentB' are grails-apps
and both dependent on 'common', which is a simple
java-project with a gradle-build.
it would be nice to be able to build myproject
wi
hi all,
still seems desirable to me ...
i had no time to step further into this.
instead i integrated the grails-build with our inhouse
buildsystem by using ant + ivy - that took me
about 2 hours. i classify this solution as temporary
but it works for now.
as grails 1.1 is targeted for the
also it would be interesting to know, if peter ledbrook has
some 'extended gradle-plans' and what they are ...
[for us the key-target is: integration of grails-app-build with
our inhouse artefact-repository-infrastucture and release-
build-process.]
--
View this message in context:
http://www
and it seems like adam murdoch made a right decision by
choosing docbook.
i think it would be very attractive for many
projects to have this way of doing documentations
at hand.
IMO offering docbook/usersguide-tasks via a gradle-plugin
could be a winner ...
gruesse
--
View this messag
hallo hans,
i am still following gradles progress with much interest.
i was/am involved in is a huge inhouse-project that
sucks away almost all of my time. *stöhn*
the 4 gradle-builds we have so far run without
problems ;-)
>>So why not file a Jira?
yep -> http://jira.codehaus.org/browse/GRAD
i asked this question some month ago.
at that time i had to integrate the grails-builds
into myCompanys ant+ivy-based build-system.
first i thought of setting up such a plugin by myself,
but because of my limited time and skills i
finally used pure ant+ivy for the integration,
which was quite
hi gradle-users,
i am just about to upgrade and improve my
http://www.nabble.com/common-resolver-setup-across-multiple-gradle-builds-to19570795.html
gradle-customization and want to
share the results ... maybe get some feedback ;-)
here my gradle-build for a spring-web-mvc-project, that
uses c
another thing, i am not sure about is:
artifacts {
archives war
}
from the usersguide: "The archives configuration is the
standard configuration to assign your artifacts to. The
Java plugin automatically assigns the default jar to this
configuration."
does this mean, that the 'War plugi
hallo hans,
thank you for the valuable feedback.
initially my plugin was implemented in groovy.
i changed it to java to see how this is done in
java and to have a better eclipse-support (eclipses
groovy-support is still quite limited).
but you are right. to implement custom-plugins
in groovy
hi gradle-community,
for a project, that uses groovy only for testing ...
how can i achieve, that groovy-all-*.jar is not
packaged into the jar or war ?
thanks & have a nice day
--
View this message in context:
http://www.nabble.com/configuration-when-using-groovy-for-testing-only---tp2373879
aha ... the following seems to do the job:
war.libExcludeConfigurations('groovy')
Helmut Denk wrote:
>
> hi gradle-community,
>
> for a project, that uses groovy only for testing ...
> how can i achieve, that groovy-all-*.jar is not
> packaged into the jar or war
hdockter wrote:
>
> Is this really an issue for the jar? I would assume this is only an
> issue for the war?
>
your right. this affects only war.
--
View this message in context:
http://www.nabble.com/configuration-when-using-groovy-for-testing-only---tp23738798p23771267.html
Sent from th
this is a nice thread ...
i think, what adam writes, gives a clear answer
to the initial question.
IMO gradle should have an ear-task that makes
the use of Ant's Ear/Zip task obsolete and there
should be added an example for building the ear
on base of the sample-multi-project-build.
not mu
hi hans,
i ran it against myCompanys gradle-builds and it worked
as expected.
jettyRun and jettyRunWar is cool.
have a successful time
hdockter wrote:
>
> A release candidate for the planned 0.6.1 release is available:
>
> http://snapshots.dist.codehaus.org/gradle/gradle-0.6.1-200905291244
hi peter,
something off-topic ...
i played a little bit with spock today and took
a look at the docs and sourcecode ... it looks
quite promising to me.
i would like to try it against grails-apps. have
you done that already ?
i tried easyb against grails via grails-easyb-plugin
but that was
hi gradle-users and developers,
for myCompanys ant+ivy-based buildsystem we use 2
repository caches. One for the SNAPSHOT-artefacts and
one for all the other artefacts. we do this because we
want to be able to run the command 'cleanSnapshotCache'
that wipes out all the cached SNAPSHOT-artefacts
hallo hans,
thanks for the hints. i had no time to step into this
subject so far ... but i will do so, because it's the final
step to get gradle 100% congruent with our ant+ivy
build-logik.
hdockter wrote:
>
> Are those simply Ivy bugs? If so, are there Jira's for this?
>
hmm i don't know .
hi gradle,
one thing, that could be useful IMO
is a retrieve-command that supports
switching from ivy/maven-repositories
to flatDir.
in ant+ivy it is like this:
*** snip ***
ivy.retrieve.pattern=${lib.dir}/[conf]/[artifact].[ext]
*** snap ***
the default-behaviour of a command 'gradle ret
hi gradle-users,
with help from the mailinglist and some try & error
i managed to create the manifest-file i want.
my script looks like this:
manifestCp = new StringBuffer()
configurations.runtime.allDependencies.each { dep ->
manifestCp.append(' ')
manifestCp.append("lib/${dep.getN
correction: the ivy.retrieve.pattern for flatDir
must be like this:
ivy.retrieve.pattern=lib/[artifact]-[revision].[ext]
Helmut Denk wrote:
>
>
> *** snip ***
> ivy.retrieve.pattern=${lib.dir}/[conf]/[artifact].[ext]
>
>
> *** snap ***
>
>
--
View thi
for the interested user ...
one way to do this is:
task retrieveRuntimeLibs << {
Set files = configurations.runtime.resolve()
ant {
files.each {
copy(file: it, todir: 'runtimeLibs')
}
}
}
--
View this message in context:
http://www.nabble.com/retrieveL
samples are always a good startingpoint ...
maybe a wiki-page or snipplr.com could become source
for a collection of useful gradle-snippets.
Adam Murdoch-2 wrote:
>
> I wonder if this is the start of a 'java-application' plugin
>
such a plugin targets a typical usecase but
implicates the
hi gradle,
as i noted in an earlier post, i think that gradle-support
for building grails-apps would be a useful thing.
unfortunately i dont feel like the man to do a proper gradle-plugin
for grails (this is mainly a matter of skills but also a matter
of time). i also think, that regarding the
hi carsten,
looks like the right time for discussions about
this topic.
the step-list you pointed to, gives a good overview
of what has to be done during the release-process.
points that come to my mind are:
- scm-abstraction that allows to update, commit,
branch, tag against most common
and release number
> increment (unless desired).
>
> I could release the source for this as I did for the eclipse and
> dependency plugins if there's any interest.
>
> Phil.
>
>
> Helmut Denk wrote:
>>
>> hi carsten,
>>
>> looks like th
let me correct myself a little bit:
Helmut Denk wrote:
>
> on the long run there should be a process that defines how
> to publish and maintain community-plugins and keep them separate
> from the core.
>
i think the gradle-team should consider to make
this part of 1.0.
i just noticed that the famous mrhaki's blog
has a gradle-branch now ...
http://mrhaki.blogspot.com/search/label/Gradle%3AGoodness
mrhaki is incredible ... excellent promotion for gradle
--
View this message in context:
http://old.nabble.com/Gradle-Goodness-tp26351575p26351575.html
Sent from
thanks robert for publishing your code.
to make my plugin (i only have one atm) distributable,
i build a jar and copy it to the lib/ dir of the gradle-distribution
+ add a line in plugins.properties.
setup of an 'official' gradle-plugins project @hithub
and definition of a ruleset for plugin-d
hi robert,
*1* = plugin-build
my build.gradle for the plugin-build:
(you may have to adjust the dependencys if
you use another version of gradle)
usePlugin('groovy')
sourceCompatibility = 1.5
targetCompatibility = 1.5
group = 'com.myCompany.gradle'
version = 'x.y'
manifest.mainAttributes(pro
hi gradle,
i noticed that a sample for dsl-customization was
checked in lately ...
would something like this be possible too ?:
usePlugin 'java'
usePlugin com.mycompany.gradle.plugins.CustomRepositoriesPlugin
repositories {
// reference single custom-repo and/or custom-repo-chain that a
hi adam,
i guess the repo-interference/mixin can be
implemented in many ways ...
something that came to my mind:
[excuse me, if this is stupid, i still know very
few about gradle internals]
1. the call to myRepositoryChain() in the
repositories-closure triggers missing-method
2. a placehol
hi gradle,
how about a minimalistic plugin-sdk that makes
out of the box plugin-development possible ?
with a preconfigured gradle-build and (mock-)support for
running unit-tests on plugins.
like this(?):
class SomeCustomPluginTest extends GroovyTestCase {
private final Project project
here one that is truly 'real-world':
https://fisheye.springsource.org/browse/spring-security
--
View this message in context:
http://old.nabble.com/sample-gradle-builds-tp27113994p27170517.html
Sent from the gradle-user mailing list archive at Nabble.com.
---
hi rene,
that looks very nice. thank you for sharing.
how did you find out how to do things like
this ?:
dependencies {
groovy files(org.gradle.util.BootstrapUtil.gradleClasspath)
}
gruesse
--
View this message in context:
http://old.nabble.com/Fertile-soil-for-the-Gradle-Plugin-Ecosystem
hi gradle-community,
i just downloaded and tried the latest snapshot
gradle-0.9-20100203071151+1100.
i noticed that gradle does not find my 'home-grown' plugins by id any more
but only
by type.
(i build my plugins as jar and place them into $GRADLE_HOME/lib/plugins.)
it seems like META-INF/g
thanks adam. that's good news.
--
View this message in context:
http://old.nabble.com/gradle-plugins.properties-not-respected-by-latest-snapshot---tp27442370p2709.html
Sent from the gradle-user mailing list archive at Nabble.com.
---
Hans Dockter wrote:
>
> Excellent. That's a long awaited feature. Quite a few users have asked for
> that during the last year.
>
> @Helmut: We are finally there :). It would be great if you could try it
> out.
>
> - Hans
>
hi hans,
i have done so and it works for me .. though i am not
sure
> This is fixed now.
>
ah - thats nice. i have a working build-script like this now:
apply id: 'java'
apply id: 'custom-resolvers'
group = 'myCompany'
version = '1.0'
repositories {
customDownstreamRepos()
}
uploadArchives {
repositories {
customUpstreamRep
here a simplified version of plugin 'custom-resolvers':
(it is a bit strange to extend the DSL like this and maybe not the
best way to do it ... mavenCentral() comes in quite differently)
class CustomResolversPlugin implements Plugin {
def void use(Project project) {
/
hi gradle-community,
is there a conventient way to resolve dependencies from
$GRADLE_HOME/lib for a gradle-plugin-build ?
in rene groeschke's growlPlugin i found:
dependencies {
...
compile files(org.gradle.util.BootstrapUtil.gradleClasspath)
}
looks good at first glance, but i gue
hi adam,
thank you very much for the hint.
i should have read the users-guide
more carefully ...
this works for me:
dependencies {
compile gradleApi()
groovy localGroovy()
testCompile "junit:junit:4.7"
}
now - only integration-tests are missing ;-)
... must checkout the
hi groovy-users,
from the new overview section:
Why Groovy ?
>
> ... It's funny that the 'if Java had that syntax' syntax in this
> article is actually the Groovy syntax.
>
from http://www.paulgraham.com/icad.html Revenge of the Nerds :
"If you look at these languages in order, Java, Pe
for people interested in some deeper insights
i recommend:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
http://clojure.googlegroups.com/web/AreWeThereYet.pdf
(good to know, but a little bit dangerous for people
who have a a tight schedule ;-)
--
View this message in context
scala may fall short like pascal and modula or it
may rise ... i am old enough to be cautious and
watch the signs.
for gradle groovy is a good choice ... no doubt.
--
View this message in context:
http://old.nabble.com/from-the-new-overview-section%3A-why-groovy---tp28114915p28121833.html
hi jim,
that's an amazing and elegant implementation
of a gradle-plugin.
most likely a very useful one too.
gruesse
--
View this message in context:
http://old.nabble.com/GradleLauncher-for-testing-plugins-tp28470464p28519450.html
Sent from the gradle-user mailing list archive at Nabble.co
doesn't this snippet from the cookbook fit your needs ?:
// Gathering dependencies associated with a configuration
// in one folder
task copyToLib(type: Copy) {
into 'lib'
from configurations.compile
}
IMO build-logic should not depend much on 'cached or not cached'
... despite from se
75 matches
Mail list logo
