Build Refactoring

[hdockter]

I have refactored our build a little bit.

There is now an additional subproject gradle-docs for creating  
userguide, javadoc, groovydoc and the samples.

The root project is dependent on gradle-docs in that it needs the  
whole docs for the dist zips as well as the samples for the  
integration tests. Right now the dependency between those projects is  
hand-crafted. This means the dists have direct dependencies on task of  
gradle-docs. Eventually they will turn into project dependencies.

I have removed the exploded dist stuff. The zips do now directly  
collect the files from where they are (as far as the current archives  
api allows this). One important improvement is that the prefix of the  
ZipFileSet is now lazily evaluated. Therefore we can now configure the  
zips at configuration times (which we didn't do before as the version  
property is set after configuration time) which makes things much  
easier to maintain and to read. The wrapper project is no longer part  
of the samples we ship. It is now only created in the intTestImage for  
testing the wrapper. It contains absolute paths of the machine that is  
used for the build. We don't want to ship this.

The whole thing is work in progress. There are a couple of open issues  
where I'm wondering what best practices are. Anyhow, I think the build  
is now easier to understand.

I hope we can manage soon to make our archives fully understand  
filecollections (including working with prefixes) and automatically  
add the filecollection dependencies. It should also be easy to reuse  
zipfilesets across different archives.

- Hans

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

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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Wed, 2009-09-30 at 08:57 +0200, Hans Dockter wrote:
[ . . . ]
> I have removed the exploded dist stuff. The zips do now directly  
[ . . . ]

I used the explodedDist task so as to get a tree that I could copy over
as a form of installation.  If this has gone away, I guess install works
differently.  Not a problem, but install wasn't installing the docs
previously and the explodedDist directory was the fastest way of finding
the made docs.

Thanks.

(I think having the docs as a sub-project does make everything more
consistent, so a step forward as far as I am concerned.)

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Steve Appling]

The integTest task now requires that you have the gradle_retroLibsDir property
set up, which was not required before.  Is this intentional?  I don't currently
have JDK 1.4 on my machine.  Are we really doing testing of both the normal and
1.4 distributions as part of these tests now?

Hans Dockter wrote:

> I have refactored our build a little bit.
>
> There is now an additional subproject gradle-docs for creating
> userguide, javadoc, groovydoc and the samples.
>
> The root project is dependent on gradle-docs in that it needs the whole
> docs for the dist zips as well as the samples for the integration tests.
> Right now the dependency between those projects is hand-crafted. This
> means the dists have direct dependencies on task of gradle-docs.
> Eventually they will turn into project dependencies.
>
> I have removed the exploded dist stuff. The zips do now directly collect
> the files from where they are (as far as the current archives api allows
> this). One important improvement is that the prefix of the ZipFileSet is
> now lazily evaluated. Therefore we can now configure the zips at
> configuration times (which we didn't do before as the version property
> is set after configuration time) which makes things much easier to
> maintain and to read. The wrapper project is no longer part of the
> samples we ship. It is now only created in the intTestImage for testing
> the wrapper. It contains absolute paths of the machine that is used for
> the build. We don't want to ship this.
>
> The whole thing is work in progress. There are a couple of open issues
> where I'm wondering what best practices are. Anyhow, I think the build
> is now easier to understand.
>
> I hope we can manage soon to make our archives fully understand
> filecollections (including working with prefixes) and automatically add
> the filecollection dependencies. It should also be easy to reuse
> zipfilesets across different archives.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 30, 2009, at 7:40 PM, Steve Appling wrote:

> The integTest task now requires that you have the  
> gradle_retroLibsDir property set up, which was not required before.  
> Is this intentional?  I don't currently have JDK 1.4 on my machine.  
> Are we really doing testing of both the normal and 1.4 distributions  
> as part of these tests now?

Actually we don't test the 1.4 distribution at the moment. So the  
integTest should just rely on bin, all and src zip.

- Hans

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

>
> Hans Dockter wrote:
>> I have refactored our build a little bit.
>> There is now an additional subproject gradle-docs for creating  
>> userguide, javadoc, groovydoc and the samples.
>> The root project is dependent on gradle-docs in that it needs the  
>> whole docs for the dist zips as well as the samples for the  
>> integration tests. Right now the dependency between those projects  
>> is hand-crafted. This means the dists have direct dependencies on  
>> task of gradle-docs. Eventually they will turn into project  
>> dependencies.
>> I have removed the exploded dist stuff. The zips do now directly  
>> collect the files from where they are (as far as the current  
>> archives api allows this). One important improvement is that the  
>> prefix of the ZipFileSet is now lazily evaluated. Therefore we can  
>> now configure the zips at configuration times (which we didn't do  
>> before as the version property is set after configuration time)  
>> which makes things much easier to maintain and to read. The wrapper  
>> project is no longer part of the samples we ship. It is now only  
>> created in the intTestImage for testing the wrapper. It contains  
>> absolute paths of the machine that is used for the build. We don't  
>> want to ship this.
>> The whole thing is work in progress. There are a couple of open  
>> issues where I'm wondering what best practices are. Anyhow, I think  
>> the build is now easier to understand.
>> I hope we can manage soon to make our archives fully understand  
>> filecollections (including working with prefixes) and automatically  
>> add the filecollection dependencies. It should also be easy to  
>> reuse zipfilesets across different archives.
>> - Hans
>> --
>> Hans Dockter
>> Gradle Project Manager
>> http://www.gradle.org
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>   http://xircles.codehaus.org/manage_email
>
> --
> Steve Appling
> Automated Logic Research Team
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email