Advice on multi-project/build source setup

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Advice on multi-project/build source setup

Allan Lewis
I have a project setup as below:

root
+project1
+project2
+unit-test

2 sub-projects, along with another unit/integration test project which depends on both of the other projects.  In addition, project1 is a code generator, which the unit-test project needs to execute to generate some of the sources to be tested.  So, in other words, what is the best way for me to structure things so that I can both build project1 and incorporate it into my build for later projects?  I playes around a bit with adding some plugins/tasks to buildSrc, but wasn't able to get things working.

Thanks for any help, and congrats on a great new tool.  I'm currently looking at migrating an existing Maven build over to Gradle.
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On Apr 29, 2008, at 3:50 PM, Allan Lewis wrote:

I have a project setup as below:

root
+project1
+project2
+unit-test

2 sub-projects, along with another unit/integration test project which
depends on both of the other projects.  In addition, project1 is a code
generator, which the unit-test project needs to execute to generate some of
the sources to be tested.  So, in other words, what is the best way for me
to structure things so that I can both build project1 and incorporate it
into my build for later projects?  I playes around a bit with adding some
plugins/tasks to buildSrc, but wasn't able to get things working.

buildSrc is the way to go. I have forgotten to mention in the user's guide that buildSrc has to be in the root project. The binaries of buildSrc are available to all subproject build scripts. If we encounter use cases were it would be much better that each subproject can have its own buildSrc we might modify this.

root/settings.xml:
include 'project2', 'unit-test'

root/buildSrc/src/main/java ...sources of your former project1
root/buildSrc/src/test/java ...if there are tests 

root/unit-test/gradlefile;
dependencies {
   compile project(':project2')
}

I'm delighted that people start using the multi-project functionality of Gradle.

Please don't hesitate to ask as many questions as necessary to get your stuff running.

- Hans



Thanks for any help, and congrats on a great new tool.  I'm currently
looking at migrating an existing Maven build over to Gradle.
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis
Thanks for the quick reply, Hans.

My situation is a little more complex, in that I'd like to have the code from project1/buildSrc available as an artifact at the end of the day.  Here is my actual situation:

root
+buildSrc
+generator
+modeling
+tests

The structure above should produce 2 components, a code generator, and some classes useful for working with UML models.  Both generator and modeling will wind up being released as artifacts when I do a release.  The tests project is really testing the integration of these components, which is why I have it broken out into its own project.

It seems that what I want is a plugin under buildSrc that references some of the classes in both 'generator' and 'modeling'.  The 'tests' project would then use this plugin to generate the artifacts to be used in testing.  

Here is my current Maven structure:

-generator
-modeling
-maven-plugin (depends on both of the above)
-tests (uses maven-plugin)

Is that clearer?  Any further advice?

hdockter wrote
Hi Allan,

On Apr 29, 2008, at 3:50 PM, Allan Lewis wrote:

>
> I have a project setup as below:
>
> root
> +project1
> +project2
> +unit-test
>
> 2 sub-projects, along with another unit/integration test project which
> depends on both of the other projects.  In addition, project1 is a  
> code
> generator, which the unit-test project needs to execute to generate  
> some of
> the sources to be tested.  So, in other words, what is the best way  
> for me
> to structure things so that I can both build project1 and  
> incorporate it
> into my build for later projects?  I playes around a bit with  
> adding some
> plugins/tasks to buildSrc, but wasn't able to get things working.

buildSrc is the way to go. I have forgotten to mention in the user's  
guide that buildSrc has to be in the root project. The binaries of  
buildSrc are available to all subproject build scripts. If we  
encounter use cases were it would be much better that each subproject  
can have its own buildSrc we might modify this.

root/settings.xml:
include 'project2', 'unit-test'

root/buildSrc/src/main/java ...sources of your former project1
root/buildSrc/src/test/java ...if there are tests

root/unit-test/gradlefile;
dependencies {
    compile project(':project2')
}

I'm delighted that people start using the multi-project functionality  
of Gradle.

Please don't hesitate to ask as many questions as necessary to get  
your stuff running.

- Hans


>
> Thanks for any help, and congrats on a great new tool.  I'm currently
> looking at migrating an existing Maven build over to Gradle.
> --
> View this message in context: http://www.nabble.com/Advice-on-multi- 
> project-build-source-setup-tp16960881p16960881.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
>
>

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



Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On Apr 29, 2008, at 4:52 PM, Allan Lewis wrote:

Thanks for the quick reply, Hans.

My situation is a little more complex, in that I'd like to have the code
from project1/buildSrc available as an artifact at the end of the day.  Here
is my actual situation:

root
+buildSrc
+generator
+modeling
+tests

The structure above should produce 2 components, a code generator, and some
classes useful for working with UML models.  Both generator and modeling
will wind up being released as artifacts when I do a release.  The tests
project is really testing the integration of these components, which is why
I have it broken out into its own project.

It seems that what I want is a plugin under buildSrc that references some of
the classes in both 'generator' and 'modeling'.  The 'tests' project would
then use this plugin to generate the artifacts to be used in testing.  

Here is my current Maven structure:

-generator
-modeling
-maven-plugin (depends on both of the above)
-tests (uses maven-plugin)

Is that clearer?  Any further advice?

Here is how I understand your dependencies.

The maven-plugin has a compile dependency on generator and modeling. The maven-plugin contains the actuals tests. The tests project just triggers those tests. The generator and modeling project are independent.

Is this right?

Are the tests in the Maven plugin JUnit or TestNG tests?

I just want to be sure before I get into any details.

- Hans



hdockter wrote:

Hi Allan,

On Apr 29, 2008, at 3:50 PM, Allan Lewis wrote:


I have a project setup as below:

root
+project1
+project2
+unit-test

2 sub-projects, along with another unit/integration test project which
depends on both of the other projects.  In addition, project1 is a  
code
generator, which the unit-test project needs to execute to generate  
some of
the sources to be tested.  So, in other words, what is the best way  
for me
to structure things so that I can both build project1 and  
incorporate it
into my build for later projects?  I playes around a bit with  
adding some
plugins/tasks to buildSrc, but wasn't able to get things working.

buildSrc is the way to go. I have forgotten to mention in the user's  
guide that buildSrc has to be in the root project. The binaries of  
buildSrc are available to all subproject build scripts. If we  
encounter use cases were it would be much better that each subproject  
can have its own buildSrc we might modify this.

root/settings.xml:
include 'project2', 'unit-test'

root/buildSrc/src/main/java ...sources of your former project1
root/buildSrc/src/test/java ...if there are tests

root/unit-test/gradlefile;
dependencies {
    compile project(':project2')
}

I'm delighted that people start using the multi-project functionality  
of Gradle.

Please don't hesitate to ask as many questions as necessary to get  
your stuff running.

- Hans



Thanks for any help, and congrats on a great new tool.  I'm currently
looking at migrating an existing Maven build over to Gradle.
-- 
View this message in context: http://www.nabble.com/Advice-on-multi- 
project-build-source-setup-tp16960881p16960881.html
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead







-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis

hdockter wrote
Here is how I understand your dependencies.

The maven-plugin has a compile dependency on generator and modeling.  
The maven-plugin contains the actuals tests. The tests project just  
triggers those tests. The generator and modeling project are  
independent.

Is this right?

Are the tests in the Maven plugin JUnit or TestNG tests?

I just want to be sure before I get into any details.

- Hans
Just about.  Here is some more detail:

- generator and modeling have no dependencies (aside from commons, etc).  They are independent of each other
- maven-plugin has a compile dependency on both generator and modeling.  there are no tests in the maven-plugin project
- the tests project contains a number of JUnit tests, along with the config files needed to configure and use the generator and modeling components.  The tests POM configures execution(s) of maven-plugin within its build section by pointing maven-plugin at the needed config files.  The execution(s) of maven-plugin happen before compilation in the generate-sources phase of the tests project to generate the sources which are tested by my JUnits.
 
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On Apr 29, 2008, at 9:01 PM, Allan Lewis wrote:



hdockter wrote:


Here is how I understand your dependencies.

The maven-plugin has a compile dependency on generator and modeling.  
The maven-plugin contains the actuals tests. The tests project just  
triggers those tests. The generator and modeling project are  
independent.

Is this right?

Are the tests in the Maven plugin JUnit or TestNG tests?

I just want to be sure before I get into any details.

- Hans



Just about.  Here is some more detail:

- generator and modeling have no dependencies (aside from commons, etc). 
They are independent of each other
- maven-plugin has a compile dependency on both generator and modeling. 
there are no tests in the maven-plugin project
- the tests project contains a number of JUnit tests, along with the config
files needed to configure and use the generator and modeling components. 
The tests POM configures execution(s) of maven-plugin within its build
section by pointing maven-plugin at the needed config files.  The
execution(s) of maven-plugin happen before compilation in the
generate-sources phase of the tests project to generate the sources which
are tested by my JUnits.


Thanks for the info. Now I understand your layout. I have a solution in mind which would work with the current Gradle release. Unfortunately I'm busy for the next 5 hours. I gonna give this a try late.

You definitely have a use case which was not taken into consideration in the design of Gradle. I'd like to discuss this later on.

- Hans


-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis

Sounds great - keep me posted.  Feel free to send an email if you'd prefer to discuss this further offline.

Allan

hdockter wrote
Thanks for the info. Now I understand your layout. I have a solution  
in mind which would work with the current Gradle release.  
Unfortunately I'm busy for the next 5 hours. I gonna give this a try  
late.

You definitely have a use case which was not taken into consideration  
in the design of Gradle. I'd like to discuss this later on.

- Hans
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

my approach seems to work. I'm just so tired that I have to finish it tomorrow.

One thing I've recognized is, that Gradle assumes all source dirs to be under 'src'. I guess this is not what you want when doing code generation. I suppose you would want to have the generated src dirs in the build dir, right?

This is easy to change.

- Hans

On Apr 30, 2008, at 6:14 PM, Allan Lewis wrote:


Sounds great - keep me posted.  Feel free to send an email if you'd prefer
to discuss this further offline.

Allan


hdockter wrote:


Thanks for the info. Now I understand your layout. I have a solution  
in mind which would work with the current Gradle release.  
Unfortunately I'm busy for the next 5 hours. I gonna give this a try  
late.

You definitely have a use case which was not taken into consideration  
in the design of Gradle. I'd like to discuss this later on.

- Hans



-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis
Yes, I'd most likely generate sources to 'build\src\' or something similar, although another option would be to generate to 'src\generated\java' or the like.  I've done things both ways, and the generator tool I'm working on will support either (user tells it where to dump code).

The Compile task has a srcDirs attribute, correct?  Modifying that in my build script to include any generated source directories seems easy enough (and FAR easier than in Maven).  Let me know if you think that this approach wouldn't work.  Or are you saying that Gradle assumes any values specified for 'srcDirs' are assumed to be under 'src'?  If the latter, that is something that I'd hope could be changed.  

hdockter wrote
Hi Allan,

my approach seems to work. I'm just so tired that I have to finish it  
tomorrow.

One thing I've recognized is, that Gradle assumes all source dirs to  
be under 'src'. I guess this is not what you want when doing code  
generation. I suppose you would want to have the generated src dirs  
in the build dir, right?

This is easy to change.

- Hans
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On Apr 30, 2008, at 11:45 PM, Allan Lewis wrote:

Yes, I'd most likely generate sources to 'build\src\' or something similar,
although another option would be to generate to 'src\generated\java' or the
like.  I've done things both ways, and the generator tool I'm working on
will support either (user tells it where to dump code).

The Compile task has a srcDirs attribute, correct?  Modifying that in my
build script to include any generated source directories seems easy enough
(and FAR easier than in Maven).  Let me know if you think that this approach
wouldn't work.  Or are you saying that Gradle assumes any values specified
for 'srcDirs' are assumed to be under 'src'?  If the latter, that is
something that I'd hope could be changed.  

I have changed this in trunk and this change will be part of the 0.1.4 release which I want to do in the next days. 

There are two use cases for directories. If someone says I want the top level source dir to be called sources instead of src, I wanted to make it possible to do in single line without having to change the name of all source dir children. This has introduced an inflexibility. Now there are two kind of dirs. One where you just specify the name of the directory and which is part of the convention filesystem hierarchy. And there are floating dirs which can be anywhere. I haven't updated the user's guide yet. 

I have attached an example zip which shows hopefully a way to solve your original problem. First of all, so far Gradle does not have the notion of a build script dependency within a multi-project build. A good solution for your problem were, if you could declare a build script dependency from tests on generator and model. This means the jars of the generator and model would be in the classpath of the tests buildscript. In Groovy you would have to add those jars to the classpath of the Script Evaluator, before the tests project build script gets evaluated. But such a functionality would collide with other behavior of Gradle, because you would need to execute the tasks of one project before another projects build script is even evaluated. Gradle offers Cross-Project configuration, which means every project can manipulate another project, Gradle evaluates every project before it executes any task. 

Dynamic language is a general term. Dynamic languages are more or less dynamic. This points out a case where Groovy is less dynamic, as you can't add to the classpath during the execution of a script. There is some discussion about this, and people came up with or working on certain solutions. I have to have a closer look at this debate. Having said all this, here is how I would solve your problem. I have created a simpler scenario for demonstrating this. There is just a generator and a tests project.

gradlefile of tests:
dependencies {    addMavenRepo()    addConfiguration('generate')    addConf2Tasks('generate', 'init')    generate project(':generator')    testCompile "junit:junit:4.4"

Here we add a new generate configuration where we add all the jars needed for generating the stuff which should get compiled and tested in a later phase. 

In init we say:

init.doFirst {    URL[] classpath = dependencies.resolveClasspath('generate').collect {File file ->            Locator.fileToURL(file)        }    new GroovyShell(new URLClassLoader(classpath, Thread.currentThread().contextClassLoader),            new Binding(project: project)).evaluate(file('generatefile'))}
What we do here is to execute another groovy script with the generate classpath:
This is how the script looks like:
String text = new generator.Generator().generate()File generatedFileDir = new File(project.buildDir, 'generatedSrc')generatedFileDir.mkdirs()project.floatingGroovySrcDirs << generatedFileDirnew File(generatedFileDir, 'GeneratedClass.java').write(text)

I'd like to integrate such a scenario into our build-by-convention functionality. Then all the boilerplate stuff you do here wouldn't be necessary. 
I'm not saying that this is a fantastic solution, neither is it awful I think. Looking at this from a domain driven design perspective there is the idea of a build script dependency (or however we call such a dependency). I'm not sure if the solution above is too much of an algorithmic solution to the problem and does not reflect this new concept appropriately in the domain model. 
What do you think?
There is a gradle-0.1.4-080501102646+0200.zip distribution in http://snapshots.dist.codehaus.org/gradle which contains all the changes to make the attached example work.  
- Hans




hdockter wrote:


Hi Allan,

my approach seems to work. I'm just so tired that I have to finish it  
tomorrow.

One thing I've recognized is, that Gradle assumes all source dirs to  
be under 'src'. I guess this is not what you want when doing code  
generation. I suppose you would want to have the generated src dirs  
in the build dir, right?

This is easy to change.

- Hans



-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead





buildScriptDep.zip (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis
Hans,

This is great, thanks!  I need to play with things a bit more to get things fully functional in my real-world case, but what you laid out definitely works.  Would be great if doing things like this could become a little more seamless and tied into the build to reduce some of the boilerplate stuff (as you mentioned earlier).

Allan
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On May 2, 2008, at 1:58 PM, Allan Lewis wrote:

Hans,

This is great, thanks!  I need to play with things a bit more to get things
fully functional in my real-world case, but what you laid out definitely
works.  Would be great if doing things like this could become a little more
seamless and tied into the build to reduce some of the boilerplate stuff (as
you mentioned earlier).

Definitely. I gonna wait with this on your feedback. You might have further requirement which are also relevant for the generic use case.

- Hans


Allan
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
In reply to this post by Allan Lewis
Hi Allan,

with the new 0.1.4 release a couple of things have changed.

I have attached a modified example zip for your use case.

- Hans
 
On May 2, 2008, at 1:58 PM, Allan Lewis wrote:

Hans,

This is great, thanks!  I need to play with things a bit more to get things
fully functional in my real-world case, but what you laid out definitely
works.  Would be great if doing things like this could become a little more
seamless and tied into the build to reduce some of the boilerplate stuff (as
you mentioned earlier).

Allan
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead







buildScriptDep.zip (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Advice on multi-project/build source setup

Allan Lewis

Hans,

 

I downloaded the 0.1.4 release and tried your example, but get the following.  Thoughts?

 

Build aborted anormally.  Run with -s option to get stacktrace. Run with -d option to get all debug info including stack

trace. Run (additionally) with -f option to get the full (very verbose) stacktrace

Exception: org.gradle.api.GradleScriptException: java.lang.ClassNotFoundException: groovy.lang.GroovyShell Buildscript=g

radlefile No line info available from stacktrace.

 


From: Hans Dockter [mailto:[hidden email]]
Sent: Monday, May 05, 2008 7:05 PM
To: [hidden email]
Subject: Re: [gradle-user] Advice on multi-project/build source setup

 

Hi Allan,

 

with the new 0.1.4 release a couple of things have changed.

 

I have attached a modified example zip for your use case.

 

- Hans

 

On May 2, 2008, at 1:58 PM, Allan Lewis wrote:



 

Hans,

 

This is great, thanks! I need to play with things a bit more to get things

fully functional in my real-world case, but what you laid out definitely

works. Would be great if doing things like this could become a little more

seamless and tied into the build to reduce some of the boilerplate stuff (as

you mentioned earlier).

 

Allan

--

Sent from the gradle-user mailing list archive at Nabble.com.

 

 

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

 

 

 

 

--

Hans Dockter

Gradle Project lead

 

Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On May 6, 2008, at 4:03 AM, Allan Lewis wrote:
Hans,
 
I downloaded the 0.1.4 release and tried your example, but get the following.  Thoughts?
 
Build aborted anormally.  Run with -s option to get stacktrace. Run with -d option to get all debug info including stack
trace. Run (additionally) with -f option to get the full (very verbose) stacktrace
Exception: org.gradle.api.GradleScriptException: java.lang.ClassNotFoundException: groovy.lang.GroovyShell Buildscript=g
radlefile No line info available from stacktrace.

This is a bug. It works on my Mac but not on Windows (and probably not on Linux). I have to check when I have time.

Sorry for this

- Hans

 

From: Hans Dockter [[hidden email]] 
Sent: Monday, May 05, 2008 7:05 PM
To: [hidden email]
Subject: Re: [gradle-user] Advice on multi-project/build source setup
 
Hi Allan,
 
with the new 0.1.4 release a couple of things have changed.
 
I have attached a modified example zip for your use case.
 
- Hans
 
On May 2, 2008, at 1:58 PM, Allan Lewis wrote:


 
Hans,
 
This is great, thanks! I need to play with things a bit more to get things
fully functional in my real-world case, but what you laid out definitely
works. Would be great if doing things like this could become a little more
seamless and tied into the build to reduce some of the boilerplate stuff (as
you mentioned earlier).
 
Allan
--
Sent from the gradle-user mailing list archive at Nabble.com.
 
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
 
 
 
--
Hans Dockter
Gradle Project lead
 

--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

On May 6, 2008, at 11:25 AM, Hans Dockter wrote:
Hi Allan,

On May 6, 2008, at 4:03 AM, Allan Lewis wrote:
Hans,
 
I downloaded the 0.1.4 release and tried your example, but get the following.  Thoughts?
 
Build aborted anormally.  Run with -s option to get stacktrace. Run with -d option to get all debug info including stack
trace. Run (additionally) with -f option to get the full (very verbose) stacktrace
Exception: org.gradle.api.GradleScriptException: java.lang.ClassNotFoundException: groovy.lang.GroovyShell Buildscript=g
radlefile No line info available from stacktrace.

This is a bug. It works on my Mac but not on Windows (and probably not on Linux). I have to check when I have time.

Fortunately this is just a bug in the example. I thought the zip was up to date, but it wasn't. Here the new one.

- Hans


Sorry for this

- Hans

 

From: Hans Dockter [[hidden email]] 
Sent: Monday, May 05, 2008 7:05 PM
To: [hidden email]
Subject: Re: [gradle-user] Advice on multi-project/build source setup
 
Hi Allan,
 
with the new 0.1.4 release a couple of things have changed.
 
I have attached a modified example zip for your use case.
 
- Hans
 
On May 2, 2008, at 1:58 PM, Allan Lewis wrote:


 
Hans,
 
This is great, thanks! I need to play with things a bit more to get things
fully functional in my real-world case, but what you laid out definitely
works. Would be great if doing things like this could become a little more
seamless and tied into the build to reduce some of the boilerplate stuff (as
you mentioned earlier).
 
Allan
--
Sent from the gradle-user mailing list archive at Nabble.com.
 
 
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
 
 
 
 
--
Hans Dockter
Gradle Project lead
 

--
Hans Dockter
Gradle Project lead





--
Hans Dockter
Gradle Project lead






buildScriptDep.zip (25K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

Allan Lewis
In reply to this post by hans_d
Hans,

I think that this solution works, and gives me what I need for now.  Longer-term, I think it would be ideal if Gradle supported something along the lines of what I can do in Maven:

+ Build project libraries
+ Build custom Gradle tasks/plugins that reference these libraries
+ Use the custom Gradle tasks/plugins above at build time in other projects (within the same multi-project build)
+ Expose the tasks/plugins to the outside world to be consumed by other projects' builds

Again, what you have provided is great, and gives me what I need, but as I move beyond a unit test project to having multiple projects which need to use the Generator at build time, having to replicate this solution in each project is less than ideal.
Reply | Threaded
Open this post in threaded view
|

Re: Advice on multi-project/build source setup

hans_d
Administrator
Hi Allan,

the current plugin system in Gradle is very basic. We are well aware of this and it is clear that is has to evolve. 

On May 7, 2008, at 3:54 PM, Allan Lewis wrote:

Hans,

I think that this solution works, and gives me what I need for now. 
Longer-term, I think it would be ideal if Gradle supported something along
the lines of what I can do in Maven:

+ Build project libraries
+ Build custom Gradle tasks/plugins that reference these libraries
+ Use the custom Gradle tasks/plugins above at build time in other projects
(within the same multi-project build)
+ Expose the tasks/plugins to the outside world to be consumed by other
projects' builds

Again, what you have provided is great, and gives me what I need, but as I
move beyond a unit test project to having multiple projects which need to
use the Generator at build time, having to replicate this solution in each
project is less than ideal.

No question about this. 

Hopefully there will be a 0.2 release in June which will accommodate the features you have proposed above.

I will also contact you during the implementation phase of those features, to ask for feedback, if this is OK.

- Hans

-- 
Sent from the gradle-user mailing list archive at Nabble.com.


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




--
Hans Dockter
Gradle Project lead