On Jun 6, 2009, at 1:06 AM, Walter Di Carlo wrote:
2009/6/5 Adam Murdoch <[email protected]>:
That problem is, the examples are structured how pretty much every
Java
project I've ever worked on have been structured. So, you're going
to have
to help us out here. We can't write about what we don't know. How
are your
Java/J2EE project different to our examples? Is it simply that the
source is
under src/ and the tests are under src/tests? Or is there something
else?
Let me add my 2 cents. I think the user guide is oriented most to
people coming from Maven way to manage a Java project. What about
people, like me, not coming from such world? In my case, for example,
I am doing the following steps to transform a big java project into a
set of decoupled multi java projects managed with Gradle:
1) Split the java project into less-coupled java components
- different jars are generated from the same project
- build and jar creation are delegated to the IDE
- use simple jar names
2) Create a project for each component
- one or more jars created by each project
- dependencies managed by IDE
- build and jar creation are delegated to the IDE
- use simple jar names
3) Add Ant scritps in each project to make them indipendent of the IDE
- build and jar creation are delegated to the Ant scripts
- dependencies managed by IDE or by hand
- use simple jar names
4) Add Gradle to manage project dependencies
- build and jar creation are delegated to the Ant scripts
- use flat local repository for the build resolver
- use simple jar names
- dependencies managed by Gradle
- use Ant wrapper to call Gradle
It might be interesting for you to know that with Gradle trunk you can
import any build.xml and the Ant targets are integrated as Gradle
tasks. That way you might be able to reverse the way things are
executed.
5) Use Gradle also to build and create jars
- use flat local repository for the build resolver
- use simple jar names
- dependencies managed by Gradle
6) Adopt multi-version repository
- use jar names with versions
- may access remote common lib repository
Currently, I am in the step 4. These steps are needed because most of
the developers are confortable with Ant. So, they want to delay/reduce
as much as possible the introduction/impact of a tool like Gradle.
Does all this make sense and help to better figure out what can be
added to the user guide?
As I understand this Ant integration need to get better coverage. This
is already work in progress. I'm not sure what in the user's guide is
missing to implement 5.) for 6.). I guess we would need more details
for this.
In any case, Gradle has proofed to be very flexible for me, but this
leaves me with the feeling to use it not in the right way.
I know you had a couple of postings a while ago and we were not very
responsive at that time. We were very busy with our 0.6 release.
Apologies for that. Please ask about any of the open issues you have
and we are happy to help.
For
example, now, I am managing the flat repository with some custom code
I have added to the compile/jar tasks. I am sure this is not the
correct way but I have not found/understood how I could do it in the
right way.
Is this about getting your jars created by Gradle into a flat
repository?
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
