On Wed, 2009-05-27 at 01:44 +0100, Luke Taylor wrote:
The point of a convention-based approach is that you don't have
explicitly run compiler tasks or copy files all over the place. You just
stick your files in the place where the Java plugin expects them to be
and it compiles them for you,
On Tue, 2009-05-26 at 17:16 -0700, Dean Schulze wrote:
Gradle is a plugin-based, convention-based system. So whilst you can
create tasks which do all the compilation according to manually set up
rules à la Ant (or better still Gant), people generally just use the
conventions and the plugins à la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Dockter wrote:
configurations.myconfig.asPath
Thanks!
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoc5t0ACgkQXjXn6TzcAQlgJACgj75rZMgDccfPweYlm7zG7Uij
tsMAn2cIhGqwO6X+qeMbjDnFRde6yf6L
=g91K
-END PGP
On May 27, 2009, at 2:16 AM, Dean Schulze wrote:
Those links are the same material that is in the user guide, which
I've read twice and still don't have a clue about how to use gradle
to build a j2ee project.
I've written many Ant builds, some very complex, but your
documentation
On May 26, 2009, at 9:02 PM, Daniel wrote:
Oh, that was something that I was wondering about while browsing the
code (and looking through the Scala Plugin patch): There's no actual
reason to write plugins in Java, or is there?
At least not for custom plugins, except if there are
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 all,
Migrating from 0.5 to 0.6, i was upgrading my script with not much problem.
Anyway, I spent some time fixing my ant task, which uses a custom
configuration for a classpath.
Basicly, adding the configuration is no problem, but getting the
configuration as classpath wasn't so easy because
Yep,
As you said it seems that my issue was related to that of GRADLE-499 and the
latest version of gradle in the trunk (Gradle 0.7-20090527130725+0200) is
working perfectly.
Thanks a lot for your help
Rafa
--
View this message in context:
Hi all,
I'm facing a weird behaviour, which looks like a bug to me...
here's the important parts of my configuration:
configurations {
// Dependencies needed for jibx binding
jibxAntBind
}
dependencies {
compile
Hi together,
I understood that there is a semantic difference which is very important to
understand, in order to use gradle properly.
I tried to state, that I am a bit concerned about the little syntactic
difference between adding actions and configuring a task. May I also add that
describing
On May 27, 2009, at 2:31 PM, Pfau, Matthias wrote:
!-- /* Font Definitions */ @font-face {font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal,
li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-
size:12.0pt; font-family:Times New
I agree with using conventions, but putting Java source into src/main is not a
convention. It goes into src/ or src/java/ by convention.
I recall reading that it was easy to change that convention, so hopefully the
Java plugin can still be used.
Here's why it is important to be able to
On Wed, May 27, 2009 at 9:36 PM, Dean Schulze dean_w_schu...@yahoo.comwrote:
Chapter 15 does look a lot better than Chapter 6. I don't know why they
called Chapter 6 a quick start. It doesn't help you get started at all.
I'm a little worried when you say that you've already spent two days
Hans, thanks again for explaining.
I got your point! You are right: If you are writing a build script that only
uses basic functionality (e.g. compile and create distributions), then there
is no need to append actions.
I missed the original discussion, unfortunately
On Wed, May 27, 2009 at 9:44 PM, Dean Schulze dean_w_schu...@yahoo.comwrote:
I agree with using conventions, but putting Java source into src/main is
not a convention. It goes into src/ or src/java/ by convention.
As stated in another mail from you it's actually src/main/java. That
Just to chime in, many IDEs can find your src directories quite easily and
I am wondering if that could be a feature in Gradle. I have an open source
code generator and the generated java code needs to exist separately from
the hand written code. I have been looking at Gradle because I think
Uhm, I don't like magic behind the scenes too much. Makes it awfully
annoying to debug when something doesn't work. But I adore helpful failure
messages. So if it would fail with something like:
Gradle detected that the build file
project-dir/subproject-dir:build.gradle
references (by
On May 26, 2009, at 2:47 PM, DiedrikK wrote:
We are using an ivy.xml within Eclipse (+IvyDE plugin), and we want
Gradle to
pickup that file.
In Gradle 0.5.2 there was a simple way to load dependencies from an
existing
ivy.xml file.
dependencies {
dependencyDescriptors(
Hi Rafa,
On May 27, 2009, at 1:28 PM, Rafael Serrano wrote:
Yep,
As you said it seems that my issue was related to that of GRADLE-499
and the
latest version of gradle in the trunk (Gradle
0.7-20090527130725+0200) is
working perfectly.
many thanks for trying this out.
- Hans
Thanks
On July 29th I will give a talk on Gradle in London at Skills Matter.
It is a free event.
See: http://skillsmatter.com/event/java-jee/news-from-the-gradle-build-system
Please don't forget to register if you like to attend.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
20 matches
Mail list logo
