Cleaning up Ant build.xml files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaning up Ant build.xml files

Jacopo Cappellato-4
Hi all,

in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to discuss with you some ideas to clean them up a little bit.
Some of the issues I see:
* the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
* there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)

I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets from OFBIZ_HOME/framework/build.xml.

The layout of a framework only deployment could be:

OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
OFBIZ_HOME/macro.xml
OFBIZ_HOME/runtime/*
OFBIZ_HOME/framework/component-load.xml
OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)

What do you think?

Jacopo


Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Jacques Le Roux
Administrator
+1

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> Hi all,
>
> in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to discuss with you some ideas to clean them up a little bit.
> Some of the issues I see:
> * the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
> * there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)
>
> I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets from OFBIZ_HOME/framework/build.xml.
>
> The layout of a framework only deployment could be:
>
> OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
> OFBIZ_HOME/macro.xml
> OFBIZ_HOME/runtime/*
> OFBIZ_HOME/framework/component-load.xml
> OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
> OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)
>
> What do you think?
>
> Jacopo
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Adrian Crum-3
In reply to this post by Jacopo Cappellato-4
We can put Ant parameters in a properties file.

I agree we should migrate Ant targets from lower level build.xml files
to the main one.

Adrian Crum
Sandglass Software
http://www.sandglass-software.com

On 9/5/2013 12:00 AM, Jacopo Cappellato wrote:

> Hi all,
>
> in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to discuss with you some ideas to clean them up a little bit.
> Some of the issues I see:
> * the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
> * there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)
>
> I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets from OFBIZ_HOME/framework/build.xml.
>
> The layout of a framework only deployment could be:
>
> OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
> OFBIZ_HOME/macro.xml
> OFBIZ_HOME/runtime/*
> OFBIZ_HOME/framework/component-load.xml
> OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
> OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)
>
> What do you think?
>
> Jacopo
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Jacques Le Roux
Administrator
Adrian Crum wrote:
> We can put Ant parameters in a properties file.

For the common and redundant ones (most are specific), yes why not? But since there are not much, maybe for the clarity, simply removing the redundancy and keeping common ones in build files would be enough? I hate to have to open/move from 1 file to another when it's not absolutly necessary.

Jacques
 

> I agree we should migrate Ant targets from lower level build.xml files
> to the main one.
>
> Adrian Crum
> Sandglass Software
> http://www.sandglass-software.com
>
> On 9/5/2013 12:00 AM, Jacopo Cappellato wrote:
>> Hi all,
>>
>> in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to
>> discuss with you some ideas to clean them up a little bit.
>> Some of the issues I see:
>> * the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
>> * there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also
>> declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)
>>
>> I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that
>> was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets
>> from OFBIZ_HOME/framework/build.xml.  
>>
>> The layout of a framework only deployment could be:
>>
>> OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
>> OFBIZ_HOME/macro.xml
>> OFBIZ_HOME/runtime/*
>> OFBIZ_HOME/framework/component-load.xml
>> OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we
>> move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
>> OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)
>>
>> What do you think?
>>
>> Jacopo
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Jacopo Cappellato-4
Ok, the first pass is done with rev. 1520510
Thanks for your feedback and ideas on property files etc...: I will spend some time thinking about how we could further improve the layout of build files and still maintain flexibility in the way the system can be deployed.
I think we should be able to remove:

framework/build.xml
applications/build.xml
specialpurpose/build.xml

if we declare the filelist properties:

framework-builds
test-builds
application-builds
specialpurpose-builds

somewhere else (e.g. in a property file or in the main build.xml file).

Jacopo

On Sep 5, 2013, at 8:35 PM, Jacques Le Roux <[hidden email]> wrote:

> Adrian Crum wrote:
>> We can put Ant parameters in a properties file.
>
> For the common and redundant ones (most are specific), yes why not? But since there are not much, maybe for the clarity, simply removing the redundancy and keeping common ones in build files would be enough? I hate to have to open/move from 1 file to another when it's not absolutly necessary.
>
> Jacques
>
>> I agree we should migrate Ant targets from lower level build.xml files
>> to the main one.
>>
>> Adrian Crum
>> Sandglass Software
>> http://www.sandglass-software.com
>>
>> On 9/5/2013 12:00 AM, Jacopo Cappellato wrote:
>>> Hi all,
>>>
>>> in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to
>>> discuss with you some ideas to clean them up a little bit.
>>> Some of the issues I see:
>>> * the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
>>> * there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also
>>> declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)
>>>
>>> I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that
>>> was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets
>>> from OFBIZ_HOME/framework/build.xml.  
>>>
>>> The layout of a framework only deployment could be:
>>>
>>> OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
>>> OFBIZ_HOME/macro.xml
>>> OFBIZ_HOME/runtime/*
>>> OFBIZ_HOME/framework/component-load.xml
>>> OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we
>>> move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
>>> OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)
>>>
>>> What do you think?
>>>
>>> Jacopo

Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Jacopo Cappellato-4
The refactoring is now complete in rev. 1520744

Now the files:

framework/build.xml
applications/build.xml
specialpurpose/build.xml

are only used to define the filelist properties (as before) with the list of components to be built.
The main build file simply refers to these lists to build/doc/clean OFBiz; as before, if applications' or specialpurpose's build.xml files are absent, the folders are ignored.

Please let me know if you see any issues.

Regards,

Jacopo

On Sep 6, 2013, at 10:40 AM, Jacopo Cappellato <[hidden email]> wrote:

> Ok, the first pass is done with rev. 1520510
> Thanks for your feedback and ideas on property files etc...: I will spend some time thinking about how we could further improve the layout of build files and still maintain flexibility in the way the system can be deployed.
> I think we should be able to remove:
>
> framework/build.xml
> applications/build.xml
> specialpurpose/build.xml
>
> if we declare the filelist properties:
>
> framework-builds
> test-builds
> application-builds
> specialpurpose-builds
>
> somewhere else (e.g. in a property file or in the main build.xml file).
>
> Jacopo
>
> On Sep 5, 2013, at 8:35 PM, Jacques Le Roux <[hidden email]> wrote:
>
>> Adrian Crum wrote:
>>> We can put Ant parameters in a properties file.
>>
>> For the common and redundant ones (most are specific), yes why not? But since there are not much, maybe for the clarity, simply removing the redundancy and keeping common ones in build files would be enough? I hate to have to open/move from 1 file to another when it's not absolutly necessary.
>>
>> Jacques
>>
>>> I agree we should migrate Ant targets from lower level build.xml files
>>> to the main one.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> http://www.sandglass-software.com
>>>
>>> On 9/5/2013 12:00 AM, Jacopo Cappellato wrote:
>>>> Hi all,
>>>>
>>>> in my opinion there is some mess in the Ant targets defined in the various build.xml files of the project and I would like to
>>>> discuss with you some ideas to clean them up a little bit.
>>>> Some of the issues I see:
>>>> * the parameter memory.max.param is duplicated (with different values) in OFBIZ_HOME/build.xml and OFBIZ_HOME/framework/build.xml
>>>> * there are several targets (e.g. the various clean-* targets) that are defined in OFBIZ_HOME/framework/build.xml and are also
>>>> declared in OFBIZ_HOME/build.xml (the targets here just call the targets in the framework's build.xml)
>>>>
>>>> I think that some complexity/redundancy was introduced in the attempt to have a framework folder with an Ant build.xml file that
>>>> was without dependencies; however I think that we can have a framework only deployment even if we remove most of the targets
>>>> from OFBIZ_HOME/framework/build.xml.  
>>>>
>>>> The layout of a framework only deployment could be:
>>>>
>>>> OFBIZ_HOME/build.xml (the targets to manage the runtime files etc... are defined here)
>>>> OFBIZ_HOME/macro.xml
>>>> OFBIZ_HOME/runtime/*
>>>> OFBIZ_HOME/framework/component-load.xml
>>>> OFBIZ_HOME/framework/build.xml (with minimal set of targets; we could probably get rid of this build.xml file completely, if we
>>>> move the filelist "framework-builds" to OFBIZ_HOME/build.xml)
>>>> OFBIZ_HOME/framework/* (components: each with its own build.xml file, as it is now)
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>

Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Christian Geisert
Am 07.09.2013 11:29, schrieb Jacopo Cappellato:

> The refactoring is now complete in rev. 1520744
>
> Now the files:
>
> framework/build.xml
> applications/build.xml
> specialpurpose/build.xml
>
> are only used to define the filelist properties (as before) with the list of components to be built.
> The main build file simply refers to these lists to build/doc/clean OFBiz; as before, if applications' or specialpurpose's build.xml files are absent, the folders are ignored.
>
> Please let me know if you see any issues.

I just noticed an issue with 'clean-search-indexes' (which is called by
'clean-all'):

chrisg@dysnomia:~/git/ofbiz$ ./ant clean-search-indexes
Buildfile: /home/chrisg/git/ofbiz/build.xml

clean-search-indexes:

BUILD FAILED
/home/chrisg/git/ofbiz/build.xml:169: Directory does not exist:
/home/chrisg/git/ofbiz/runtime/indexes


Adding a 'erroronmissingdir="false"' to the fileset will fix this.

I'll commit this later if no one else does it.

Christian


Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Jacopo Cappellato-4
Thank you Christian; it is a good improvement, even if the runtime/indexes folder is in svn and if you update your project you should always have it.

Jacopo

On Sep 9, 2013, at 11:05 AM, Christian Geisert <[hidden email]> wrote:

> Am 07.09.2013 11:29, schrieb Jacopo Cappellato:
>> The refactoring is now complete in rev. 1520744
>>
>> Now the files:
>>
>> framework/build.xml
>> applications/build.xml
>> specialpurpose/build.xml
>>
>> are only used to define the filelist properties (as before) with the list of components to be built.
>> The main build file simply refers to these lists to build/doc/clean OFBiz; as before, if applications' or specialpurpose's build.xml files are absent, the folders are ignored.
>>
>> Please let me know if you see any issues.
>
> I just noticed an issue with 'clean-search-indexes' (which is called by
> 'clean-all'):
>
> chrisg@dysnomia:~/git/ofbiz$ ./ant clean-search-indexes
> Buildfile: /home/chrisg/git/ofbiz/build.xml
>
> clean-search-indexes:
>
> BUILD FAILED
> /home/chrisg/git/ofbiz/build.xml:169: Directory does not exist:
> /home/chrisg/git/ofbiz/runtime/indexes
>
>
> Adding a 'erroronmissingdir="false"' to the fileset will fix this.
>
> I'll commit this later if no one else does it.
>
> Christian
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up Ant build.xml files

Christian Geisert
Am 09.09.2013 11:15, schrieb Jacopo Cappellato:
> Thank you Christian; it is a good improvement, even if the runtime/indexes folder is in svn and if you update your project you should always have it.

Ah, I'm using git-svn mirror and git doesn't support empty directories...

Christian