headers
JerodLass | 5 Aug 2008 17:21
Picon

Re: non top-level project root


Any updates on this issue? It's becoming more important to me as I am working
more with distributed projects, and it is much more convenient for version
control to see the builds as a module.  Has anyone opened a jira for this?

Thanks,
Jerod

hdockter wrote:
> 
> Hi Jerod,
> 
> On Jun 27, 2008, at 5:41 PM, JerodLass wrote:
> 
>>
>> I would like to have the following structure for my projects:
>> -D ProjectsDir
>>   -DProject1
>>   -DProject2
>>   -Dbuilds
>> The reason for this is that the projectsDir is to be my main CVS  
>> directory,
>> and this way my build logic can be a module rather than a set of  
>> files in
>> the top-level directory.  I would otherwise have to declare settings,
>> properties, and build each as modules for a CIS app to pull them  
>> for builds,
>> as well as any gradlewrapper files.  If they change names, I have  
>> to go
>> redeclare them in the continuous integration configuration.  First, I
(Continue reading)

Permalink | Reply | 1 comment |
headers
JerodLass | 5 Aug 2008 18:12
Picon

compile exclusion


What is the best way to exclude files during the compile task?  I tried
variations of:

compile{
  exclude '**/*DoNotCompile'
}

with no luck.  Compile doesn't seem to have an excludes method the way
resources does.  Some files and directories are generated by an IDE plugin
but I do not want them to be compiled.  Any thoughts would be appreciated.

Thanks,
Jerod
--

-- 
View this message in context: http://www.nabble.com/compile-exclusion-tp18834489p18834489.html
Sent from the gradle-user mailing list archive at Nabble.com.
Permalink | Reply | 1 comment |
headers
JerodLass | 6 Aug 2008 23:31
Picon

changing the project name


I am starting to build my projects on a continuous integration server (with
Hudson) and I need to be able to declare the name of my project.  All
project files are checked out into workspace, so gradle assumes the project
name is workspace.  I can fix this, but then it doesn't find any of the
source files because the path is apparently built with the project name, but
hudson/jobs/myJob/projectName doesnt exist because everything is in
hudson/jobs/myJob/workspace.

I use the property project.name a lot in my builds and I'd rather not change
all of them to another property, so how can I separate the project name to
be used appropriately when creating and locating files?

Thanks,
Jerod
--

-- 
View this message in context: http://www.nabble.com/changing-the-project-name-tp18859161p18859161.html
Sent from the gradle-user mailing list archive at Nabble.com.
Permalink | Reply | 3 comments |
headers
Hans Dockter | 7 Aug 2008 13:57

Re: compile exclusion


On Aug 5, 2008, at 6:12 PM, JerodLass wrote:

>
> What is the best way to exclude files during the compile task?  I  
> tried
> variations of:
>
> compile{
>   exclude '**/*DoNotCompile'
> }
>
> with no luck.

The patterns you can pass to the include/exclude method are Ant  
patterns.

For example:

compile {
    include('org.mypackage1/', 'org.mypackage2/')
    exclude('org.mypackage2/I*.java/')
}

This should work. You probably need to to say exclude '**/ 
DoNotCompile.java'. in your example or you may simply exclude whole  
packages.

- Hans
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hans Dockter | 7 Aug 2008 14:04

Re: non top-level project root

Hi Jerod,

On Aug 5, 2008, at 5:21 PM, JerodLass wrote:

>
> Any updates on this issue? It's becoming more important to me as I  
> am working
> more with distributed projects, and it is much more convenient for  
> version
> control to see the builds as a module.  Has anyone opened a jira  
> for this?

The Jira is: http://jira.codehaus.org/browse/GRADLE-158

No work on this has started yet, except that Adam has added  
prerequisite functionality for this (In 0.3 you can now trigger  
partial builds from the root of the multiproject hierarchy.)

We consider this a high priority issue. So hopefully it will make it  
into 0.4.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Permalink | Reply | 0 comments |
headers
Hans Dockter | 7 Aug 2008 14:14

Re: changing the project name

Hi Jerod,

On Aug 6, 2008, at 11:31 PM, JerodLass wrote:

>
> I am starting to build my projects on a continuous integration  
> server (with
> Hudson) and I need to be able to declare the name of my project.  All
> project files are checked out into workspace, so gradle assumes the  
> project
> name is workspace.  I can fix this, but then it doesn't find any of  
> the
> source files because the path is apparently built with the project  
> name, but
> hudson/jobs/myJob/projectName doesnt exist because everything is in
> hudson/jobs/myJob/workspace.
>
> I use the property project.name a lot in my builds and I'd rather  
> not change
> all of them to another property, so how can I separate the project  
> name to
> be used appropriately when creating and locating files?

Unfortunately you can't change the project name right now. There is  
the issue:

http://jira.codehaus.org/browse/GRADLE-175

I try to get this into 0.3.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hans Dockter | 7 Aug 2008 15:09

Can someone try our new JDK 1.4 compatible distribution?

We have a first snapshot of a hopefully JDK 1.4 compatible  
distribution. On my machine (Mac) it is hard to run Java with a non  
standard JDK. If would be cool if someone could check if the  
distribution:

http://snapshots.dist.codehaus.org/gradle/gradle-0.3-080807145426 
+0200-all-jdk14.zip

runs on a JDK 1.4.

Thanks

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org
Permalink | Reply | 0 comments |
headers
JerodLass | 7 Aug 2008 17:33
Picon

Re: changing the project name


Yes.  I address the $project.name jar and archive task, which are changed to
workspace.jar on Hudson.  Luckily, the top-level projects are mostly for
organization, so the real projects are in properly-named subdirectories in
more of the projects I work with.  This mainly affects independent module
projects that I would like a one-click build from cvs and publish to
repository or tag/distribute locally.

hdockter wrote:
> 
> Hi Jerod,
> 
> On Aug 6, 2008, at 11:31 PM, JerodLass wrote:
> 
>>
>> I am starting to build my projects on a continuous integration  
>> server (with
>> Hudson) and I need to be able to declare the name of my project.  All
>> project files are checked out into workspace, so gradle assumes the  
>> project
>> name is workspace.  I can fix this, but then it doesn't find any of  
>> the
>> source files because the path is apparently built with the project  
>> name, but
>> hudson/jobs/myJob/projectName doesnt exist because everything is in
>> hudson/jobs/myJob/workspace.
>>
>> I use the property project.name a lot in my builds and I'd rather  
>> not change
>> all of them to another property, so how can I separate the project
(Continue reading)

Permalink | Reply | 1 comment |
headers
Allan Lewis | 9 Aug 2008 04:44
Picon

Creating a dists task for a multi-project build


Hi,

I have a multi-project build, and at the end, I'd like to to gather up all
of the JARs and other artifacts and piece them into a release ZIP file.  How
do I create a task that will only be called once (from the root project)
after the libs task has created for the rest of my tasks?  I've tried
creating a new task in the top-level Gradle buildfile, but the problem I'm
facing is that the new task is getting called for each suproject.

Thanks
Allan
--

-- 
View this message in context: http://www.nabble.com/Creating-a-dists-task-for-a-multi-project-build-tp18901701p18901701.html
Sent from the gradle-user mailing list archive at Nabble.com.
Permalink | Reply | 6 comments |
headers
Hans Dockter | 9 Aug 2008 10:29

Re: Creating a dists task for a multi-project build

Hi Allan,

good to hear from you :)

On Aug 9, 2008, at 4:44 AM, Allan Lewis wrote:

>
> Hi,
>
> I have a multi-project build, and at the end, I'd like to to gather  
> up all
> of the JARs and other artifacts and piece them into a release ZIP  
> file.  How
> do I create a task that will only be called once (from the root  
> project)
> after the libs task has created for the rest of my tasks?  I've tried
> creating a new task in the top-level Gradle buildfile, but the  
> problem I'm
> facing is that the new task is getting called for each suproject.

Here a solution based on a sample multi-project build. You can find  
this sample build in GRADLE_HOME/samples/javaproject.

You need to replace the build.gradle file of the javaproject with  
this one:

dependsOnChildren()
project('services').dependsOnChildren() // The services project has  
no build file. To keep things simple we configure it from here.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane