Re: svn commit: r585267 - in /ofbiz/trunk/framework: base/build.xml build.xml

[David E Jones-2]

Not sure if I like this... My preference would be that each build  
file only owns its directory and below. This change makes a lower  
level build file manage something higher level.

What if the framework or base directories move, or we want more build  
flexibility?

I can see how if you build just the base component or just the  
framework directory that the ofbiz.jar file won't get updated. In a  
way that would be expected though...

If anyone else has an opinion on this please chime in. It's not a big  
deal, but is one of those things that could make life difficult in  
the future and just need to be changed back.

-David


On Oct 16, 2007, at 3:31 PM, [hidden email] wrote:

> Author: doogie
> Date: Tue Oct 16 14:31:21 2007
> New Revision: 585267
>
> URL: http://svn.apache.org/viewvc?rev=585267&view=rev
> Log:
> Update ofbiz.jar at the top-level whenever framework/base is built.
> Also, clean said file at the same time.  Based on patch from
> https://issues.apache.org/jira/browse/OFBIZ-1283.
>
> Modified:
>     ofbiz/trunk/framework/base/build.xml
>     ofbiz/trunk/framework/build.xml
>
> Modified: ofbiz/trunk/framework/base/build.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/ 
> build.xml?rev=585267&r1=585266&r2=585267&view=diff
> ======================================================================
> ========
> --- ofbiz/trunk/framework/base/build.xml (original)
> +++ ofbiz/trunk/framework/base/build.xml Tue Oct 16 14:31:21 2007
> @@ -49,6 +49,7 @@
>
>      <target name="clean" depends="clean-lib">
>          <delete dir="${build.dir}"/>
> +        <delete file="../../ofbiz.jar"/>
>      </target>
>
>      <target name="clean-lib" depends="init">
> @@ -117,6 +118,10 @@
>
>      <target name="jar" depends="classes">
>          <jar jarfile="${build.dir}/lib/ofbiz.jar" basedir="$
> {build.dir}/classes/start" manifest="${src.dir}/start/org/ofbiz/
> base/start/Start.mf"/>
> +        <!-- copy the ofbiz.jar file -->
> +        <copy todir="${basedir}/../..">
> +            <fileset dir="${build.dir}/lib" includes="ofbiz.jar"/>
> +        </copy>
>          <jar jarfile="${build.dir}/lib/ofbiz-base.jar" basedir="$
> {build.dir}/classes/base"/>
>      </target>
>
>
> Modified: ofbiz/trunk/framework/build.xml
> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/build.xml?
> rev=585267&r1=585266&r2=585267&view=diff
> ======================================================================
> ========
> --- ofbiz/trunk/framework/build.xml (original)
> +++ ofbiz/trunk/framework/build.xml Tue Oct 16 14:31:21 2007
> @@ -115,7 +115,6 @@
>          <subant target="clean">
>              <filelist refid="framework-builds"/>
>          </subant>
> -        <delete file="ofbiz.jar"/>
>          <echo message="[clean] ========== Done Cleaning Framework  
> =========="/>
>      </target>
>
> @@ -133,11 +132,6 @@
>          <subant inheritall="false">
>              <filelist refid="framework-builds"/>
>          </subant>
> -
> -        <!-- copy the ofbiz.jar file -->
> -        <copy todir="${basedir}/..">
> -            <fileset dir="base/build/lib" includes="ofbiz.jar"/>
> -        </copy>
>
>          <echo message="[build] ========== Done Building Framework  
> (Compile) =========="/>
>      </target>
>
>

[Jacopo Cappellato]

I agree that it is not a big deal, but I too would prefer to see this
change reverted.
I think it is somewhat 'natural' that if I rebuild a component, this
doesn't affect the lower level file.
Maybe a better approach is to add a "build-base" ant task to the
framework/build.cml file.

Jacopo

David E Jones wrote:

>
> Not sure if I like this... My preference would be that each build file
> only owns its directory and below. This change makes a lower level build
> file manage something higher level.
>
> What if the framework or base directories move, or we want more build
> flexibility?
>
> I can see how if you build just the base component or just the framework
> directory that the ofbiz.jar file won't get updated. In a way that would
> be expected though...
>
> If anyone else has an opinion on this please chime in. It's not a big
> deal, but is one of those things that could make life difficult in the
> future and just need to be changed back.
>
> -David
>
>
> On Oct 16, 2007, at 3:31 PM, [hidden email] wrote:
>
>> Author: doogie
>> Date: Tue Oct 16 14:31:21 2007
>> New Revision: 585267
>>
>> URL: http://svn.apache.org/viewvc?rev=585267&view=rev
>> Log:
>> Update ofbiz.jar at the top-level whenever framework/base is built.
>> Also, clean said file at the same time.  Based on patch from
>> https://issues.apache.org/jira/browse/OFBIZ-1283.
>>
>> Modified:
>>     ofbiz/trunk/framework/base/build.xml
>>     ofbiz/trunk/framework/build.xml
>>
>> Modified: ofbiz/trunk/framework/base/build.xml
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/base/build.xml?rev=585267&r1=585266&r2=585267&view=diff 
>>
>> ==============================================================================
>>
>> --- ofbiz/trunk/framework/base/build.xml (original)
>> +++ ofbiz/trunk/framework/base/build.xml Tue Oct 16 14:31:21 2007
>> @@ -49,6 +49,7 @@
>>
>>      <target name="clean" depends="clean-lib">
>>          <delete dir="${build.dir}"/>
>> +        <delete file="../../ofbiz.jar"/>
>>      </target>
>>
>>      <target name="clean-lib" depends="init">
>> @@ -117,6 +118,10 @@
>>
>>      <target name="jar" depends="classes">
>>          <jar jarfile="${build.dir}/lib/ofbiz.jar"
>> basedir="${build.dir}/classes/start"
>> manifest="${src.dir}/start/org/ofbiz/base/start/Start.mf"/>
>> +        <!-- copy the ofbiz.jar file -->
>> +        <copy todir="${basedir}/../..">
>> +            <fileset dir="${build.dir}/lib" includes="ofbiz.jar"/>
>> +        </copy>
>>          <jar jarfile="${build.dir}/lib/ofbiz-base.jar"
>> basedir="${build.dir}/classes/base"/>
>>      </target>
>>
>>
>> Modified: ofbiz/trunk/framework/build.xml
>> URL:
>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/build.xml?rev=585267&r1=585266&r2=585267&view=diff 
>>
>> ==============================================================================
>>
>> --- ofbiz/trunk/framework/build.xml (original)
>> +++ ofbiz/trunk/framework/build.xml Tue Oct 16 14:31:21 2007
>> @@ -115,7 +115,6 @@
>>          <subant target="clean">
>>              <filelist refid="framework-builds"/>
>>          </subant>
>> -        <delete file="ofbiz.jar"/>
>>          <echo message="[clean] ========== Done Cleaning Framework
>> =========="/>
>>      </target>
>>
>> @@ -133,11 +132,6 @@
>>          <subant inheritall="false">
>>              <filelist refid="framework-builds"/>
>>          </subant>
>> -
>> -        <!-- copy the ofbiz.jar file -->
>> -        <copy todir="${basedir}/..">
>> -            <fileset dir="base/build/lib" includes="ofbiz.jar"/>
>> -        </copy>
>>
>>          <echo message="[build] ========== Done Building Framework
>> (Compile) =========="/>
>>      </target>
>>
>>

[Jacopo Cappellato]

Jacopo Cappellato wrote:
> I agree that it is not a big deal, but I too would prefer to see this
> change reverted.
> I think it is somewhat 'natural' that if I rebuild a component, this
> doesn't affect the lower level file.
> Maybe a better approach is to add a "build-base" ant task to the
> framework/build.cml file.
>

Sorry,

I meant the OFBIZ_HOME/build.xml file (not the framework one).

[Adam Heath-2]

David E Jones wrote:

>
> Not sure if I like this... My preference would be that each build file
> only owns its directory and below. This change makes a lower level build
> file manage something higher level.
>
> What if the framework or base directories move, or we want more build
> flexibility?
>
> I can see how if you build just the base component or just the framework
> directory that the ofbiz.jar file won't get updated. In a way that would
> be expected though...
>
> If anyone else has an opinion on this please chime in. It's not a big
> deal, but is one of those things that could make life difficult in the
> future and just need to be changed back.

In that argument, framework/build.xml should not update it either, and
only the top-level.

The reason why I did this, is quite often I'd cd into framework/base,
and just run ant there.  Then I'd wonder why my changes hadn't taken
place, because the ofbiz.jar at the top-level hadn't been updated.

Maybe a better change would to not copy the file at all, and just modify
the startup to pull from framework/base.

[Adam Heath-2]

Adam Heath wrote:

> David E Jones wrote:
>> Not sure if I like this... My preference would be that each build file
>> only owns its directory and below. This change makes a lower level build
>> file manage something higher level.
>>
>> What if the framework or base directories move, or we want more build
>> flexibility?
>>
>> I can see how if you build just the base component or just the framework
>> directory that the ofbiz.jar file won't get updated. In a way that would
>> be expected though...
>>
>> If anyone else has an opinion on this please chime in. It's not a big
>> deal, but is one of those things that could make life difficult in the
>> future and just need to be changed back.
>
> In that argument, framework/build.xml should not update it either, and
> only the top-level.
>
> The reason why I did this, is quite often I'd cd into framework/base,
> and just run ant there.  Then I'd wonder why my changes hadn't taken
> place, because the ofbiz.jar at the top-level hadn't been updated.
>
> Maybe a better change would to not copy the file at all, and just modify
> the startup to pull from framework/base.

I'm not wedded to this change, btw; if enough others don't think it's
wise, I'll undo it.

I looked into altering things to pull from framework/base, so that no
top-level ofbiz.jar would be nescessary.  While modifying the
scripts/code is simple enough, there is plenty of documentation and best
practices that point to the ofbiz.jar in the top-level. Changing humans
is hard, so having it automatically updated is the correct approach.
Whether that's done in framework/base, or some place else, is what is
being discussed.

Another idea, that doesn't sit well with me.  Shouldn't
framework/base/src/start be split into it's own component?  Maybe
framework/start, or just move that code to the top-level.  After all,
it's just the start code that goes into ofbiz.jar.  If it were moved to
the top-level, then this argument would become moot.

[Jacques Le Roux]

From David's arguments about flexiblity I prefer to have this patch reverted and a new solution adopted

At this stage, I see 2 interesting suggestions :

Jacopo's : add a "build-base" ant task to the OFBIZ_HOME/build.xml file
Adam's :  not copy the file at all, and just modify the startup to pull from framework/base.

Maybe they could be merged in a "build-base" ant task as suggested by Jacopo (though I'm not quite sure of what Adam meant by "just
modify the startup to pull from framework/base"). Just an habit to change Adam...

WDYT ?

Jacques

[Adam Heath-2]

Jacques Le Roux wrote:

> From David's arguments about flexiblity I prefer to have this patch reverted and a new solution adopted
>
> At this stage, I see 2 interesting suggestions :
>
> Jacopo's : add a "build-base" ant task to the OFBIZ_HOME/build.xml file
> Adam's :  not copy the file at all, and just modify the startup to pull from framework/base.
>
> Maybe they could be merged in a "build-base" ant task as suggested by Jacopo (though I'm not quite sure of what Adam meant by "just
> modify the startup to pull from framework/base"). Just an habit to change Adam...
>
> WDYT ?

-exec "$JAVA" $VMARGS -jar ofbiz.jar "$@"
+exec "$JAVA" $VMARGS -jar framework/base/build/lib/ofbiz.jar "$@"

But, as I said, documentation has said to use the ofbiz.jar at the
top-level, so this solution is not the best either.

One other suggestion I had was to move framework/base/src/start into
$top/src, and build $top/build/lib/ofbiz.jar.  That code has no ofbiz
dependencies, so shouldn't be a big change.  Additionally, some libs in
base would need to be moved to the top-level, but that might make more
sense to do anyways.

[David E Jones]

On Oct 17, 2007, at 3:44 PM, Adam Heath wrote:

>
> -exec "$JAVA" $VMARGS -jar ofbiz.jar "$@"
> +exec "$JAVA" $VMARGS -jar framework/base/build/lib/ofbiz.jar "$@"

My vote on this would be no. I'm not sure what others do, but  
especially for development I run the executable jar all the time and  
the extra path would be a pain...

-David

[Tim Ruppert]

Not everyone uses the script either, so moving the jar would be a bit of a pain to train people on.  Just my two cents

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Oct 17, 2007, at 3:44 PM, Adam Heath wrote:

Jacques Le Roux wrote:

From David's arguments about flexiblity I prefer to have this patch reverted and a new solution adopted

At this stage, I see 2 interesting suggestions :

Jacopo's : add a "build-base" ant task to the OFBIZ_HOME/build.xml file

Adam's :  not copy the file at all, and just modify the startup to pull from framework/base.

Maybe they could be merged in a "build-base" ant task as suggested by Jacopo (though I'm not quite sure of what Adam meant by "just

modify the startup to pull from framework/base"). Just an habit to change Adam...

WDYT ?

-exec "$JAVA" $VMARGS -jar ofbiz.jar "$@"

+exec "$JAVA" $VMARGS -jar framework/base/build/lib/ofbiz.jar "$@"

But, as I said, documentation has said to use the ofbiz.jar at the

top-level, so this solution is not the best either.

One other suggestion I had was to move framework/base/src/start into

$top/src, and build $top/build/lib/ofbiz.jar.  That code has no ofbiz

dependencies, so shouldn't be a big change.  Additionally, some libs in

base would need to be moved to the top-level, but that might make more

sense to do anyways.

[David E Jones]

Why are we even having this discussion? It seems like the original  
change was trying to fix stuff that isn't broken... and now we're  
going on and on about it, even though it wasn't broken in the first  
place.

If anyone wants to discuss it further, I recommend writing things in  
the form of:

1. this is the problem and why
2. this is what we should do about it

Without a problem to attack it seems like we're just running in  
circles. That it's not fun, but some of us have other things we'd  
rather be doing. ;)

-David


On Oct 17, 2007, at 11:07 AM, Adam Heath wrote:

> Adam Heath wrote:
>> David E Jones wrote:
>>> Not sure if I like this... My preference would be that each build  
>>> file
>>> only owns its directory and below. This change makes a lower  
>>> level build
>>> file manage something higher level.
>>>
>>> What if the framework or base directories move, or we want more  
>>> build
>>> flexibility?
>>>
>>> I can see how if you build just the base component or just the  
>>> framework
>>> directory that the ofbiz.jar file won't get updated. In a way  
>>> that would
>>> be expected though...
>>>
>>> If anyone else has an opinion on this please chime in. It's not a  
>>> big
>>> deal, but is one of those things that could make life difficult  
>>> in the
>>> future and just need to be changed back.
>>
>> In that argument, framework/build.xml should not update it either,  
>> and
>> only the top-level.
>>
>> The reason why I did this, is quite often I'd cd into framework/base,
>> and just run ant there.  Then I'd wonder why my changes hadn't taken
>> place, because the ofbiz.jar at the top-level hadn't been updated.
>>
>> Maybe a better change would to not copy the file at all, and just  
>> modify
>> the startup to pull from framework/base.
>
> I'm not wedded to this change, btw; if enough others don't think it's
> wise, I'll undo it.
>
> I looked into altering things to pull from framework/base, so that no
> top-level ofbiz.jar would be nescessary.  While modifying the
> scripts/code is simple enough, there is plenty of documentation and  
> best
> practices that point to the ofbiz.jar in the top-level. Changing  
> humans
> is hard, so having it automatically updated is the correct approach.
> Whether that's done in framework/base, or some place else, is what is
> being discussed.
>
> Another idea, that doesn't sit well with me.  Shouldn't
> framework/base/src/start be split into it's own component?  Maybe
> framework/start, or just move that code to the top-level.  After all,
> it's just the start code that goes into ofbiz.jar.  If it were  
> moved to
> the top-level, then this argument would become moot.

[Adam Heath-2]

David E Jones wrote:
>
> Why are we even having this discussion? It seems like the original
> change was trying to fix stuff that isn't broken... and now we're going
> on and on about it, even though it wasn't broken in the first place.

Did you miss my reason as to why I did this?  I was in framework/base,
running ant directly in that directory, then in another terminal was
running startofbiz.sh.

This problem is exactly the same as the standard make issue, where you
need to run make at the top-level no matter what.  It's a pain in the
ass(hint: search for nested-make considered harmful)

> If anyone wants to discuss it further, I recommend writing things in the
> form of:
>
> 1. this is the problem and why
> 2. this is what we should do about it
>
> Without a problem to attack it seems like we're just running in circles.
> That it's not fun, but some of us have other things we'd rather be
> doing. ;)

1: Running ant in framework/base, to compile src/start, does not update
   ofbiz in $ofbiz.home.
2: move framework/base/src/start to $ofbiz.home/src, so that one
   'component' doesn't actually really contain two.

[David E Jones]

On Oct 17, 2007, at 4:07 PM, Adam Heath wrote:

> David E Jones wrote:
>>
>> Why are we even having this discussion? It seems like the original
>> change was trying to fix stuff that isn't broken... and now we're  
>> going
>> on and on about it, even though it wasn't broken in the first place.
>
> Did you miss my reason as to why I did this?  I was in framework/base,
> running ant directly in that directory, then in another terminal was
> running startofbiz.sh.

Yeah, I'm in a bad mood right now, but... boo @#$%ing hoo.

Seems like this is a reasonable requirement... and isn't it EXACTLY  
what you would expect?

-David

[Adam Heath-2]

Adam Heath wrote:

> David E Jones wrote:
>> Why are we even having this discussion? It seems like the original
>> change was trying to fix stuff that isn't broken... and now we're going
>> on and on about it, even though it wasn't broken in the first place.
>
> Did you miss my reason as to why I did this?  I was in framework/base,
> running ant directly in that directory, then in another terminal was
> running startofbiz.sh.
>
> This problem is exactly the same as the standard make issue, where you
> need to run make at the top-level no matter what.  It's a pain in the
> ass(hint: search for nested-make considered harmful)
>
>> If anyone wants to discuss it further, I recommend writing things in the
>> form of:
>>
>> 1. this is the problem and why
>> 2. this is what we should do about it
>>
>> Without a problem to attack it seems like we're just running in circles.
>> That it's not fun, but some of us have other things we'd rather be
>> doing. ;)
>
> 1: Running ant in framework/base, to compile src/start, does not update
>    ofbiz in $ofbiz.home.
> 2: move framework/base/src/start to $ofbiz.home/src, so that one
>    'component' doesn't actually really contain two.

ps: I will back this change out, as soon as I finish getting
framework/base uptodate with generics; almost done with that.

[Adam Heath-2]

David E Jones wrote:
>
> On Oct 17, 2007, at 4:07 PM, Adam Heath wrote:
>
>> Did you miss my reason as to why I did this?  I was in framework/base,
>> running ant directly in that directory, then in another terminal was
>> running startofbiz.sh.
>
> Yeah, I'm in a bad mood right now, but... boo @#$%ing hoo.

Sorry to hear that.  Maybe you should go read some www.thedailywtf.com.
 Always good for a pick-me-up.

> Seems like this is a reasonable requirement... and isn't it EXACTLY what
> you would expect?

So, you understand how I'd expect that running ant in framework/base
would make running ofbiz see whatever changes I had done?

[jonwimp]

 > Another idea, that doesn't sit well with me.  Shouldn't
 > framework/base/src/start be split into it's own component?  Maybe
 > framework/start, or just move that code to the top-level.

There are certainly a lot of areas that could use re-organization. I myself have been vocal about
how SVN shouldn't contain binaries (compiled codes); there's no meaningful way for SVN to
version-control binaries, and the bloat it causes is > 50% of the size of OFBiz download (over 35MB).

But IMHO, there will always be a perceived need to re-org.

If things works now, and they are not terribly out-of-place (say having PartyMgr codes residing in
/framework), then I'd say we leave it as is for now.

Jonathon

Adam Heath wrote:

> Adam Heath wrote:
>> David E Jones wrote:
>>> Not sure if I like this... My preference would be that each build file
>>> only owns its directory and below. This change makes a lower level build
>>> file manage something higher level.
>>>
>>> What if the framework or base directories move, or we want more build
>>> flexibility?
>>>
>>> I can see how if you build just the base component or just the framework
>>> directory that the ofbiz.jar file won't get updated. In a way that would
>>> be expected though...
>>>
>>> If anyone else has an opinion on this please chime in. It's not a big
>>> deal, but is one of those things that could make life difficult in the
>>> future and just need to be changed back.
>> In that argument, framework/build.xml should not update it either, and
>> only the top-level.
>>
>> The reason why I did this, is quite often I'd cd into framework/base,
>> and just run ant there.  Then I'd wonder why my changes hadn't taken
>> place, because the ofbiz.jar at the top-level hadn't been updated.
>>
>> Maybe a better change would to not copy the file at all, and just modify
>> the startup to pull from framework/base.
>
> I'm not wedded to this change, btw; if enough others don't think it's
> wise, I'll undo it.
>
> I looked into altering things to pull from framework/base, so that no
> top-level ofbiz.jar would be nescessary.  While modifying the
> scripts/code is simple enough, there is plenty of documentation and best
> practices that point to the ofbiz.jar in the top-level. Changing humans
> is hard, so having it automatically updated is the correct approach.
> Whether that's done in framework/base, or some place else, is what is
> being discussed.
>
> Another idea, that doesn't sit well with me.  Shouldn't
> framework/base/src/start be split into it's own component?  Maybe
> framework/start, or just move that code to the top-level.  After all,
> it's just the start code that goes into ofbiz.jar.  If it were moved to
> the top-level, then this argument would become moot.
>
>

[jonwimp]

Adam,

Ah, very clear and concise. :) I understand now.

I didn't hit the problem you encountered because I seldom (if ever) change /framework/base .

I would like to suggest that it is not much of a hassle to do a top-level ant when trying to
recompile /framework/base. Why? Because if the other modules have no changed source codes, ant
will just walk over them quickly. When ant hits /framework/base, sees some changed source codes,
those codes will be recompiled.

Eventually, I do agree that this re-org would be nice. Simply for the sake of rapid development.

Jonathon

Adam Heath wrote:

> David E Jones wrote:
>> Why are we even having this discussion? It seems like the original
>> change was trying to fix stuff that isn't broken... and now we're going
>> on and on about it, even though it wasn't broken in the first place.
>
> Did you miss my reason as to why I did this?  I was in framework/base,
> running ant directly in that directory, then in another terminal was
> running startofbiz.sh.
>
> This problem is exactly the same as the standard make issue, where you
> need to run make at the top-level no matter what.  It's a pain in the
> ass(hint: search for nested-make considered harmful)
>
>> If anyone wants to discuss it further, I recommend writing things in the
>> form of:
>>
>> 1. this is the problem and why
>> 2. this is what we should do about it
>>
>> Without a problem to attack it seems like we're just running in circles.
>> That it's not fun, but some of us have other things we'd rather be
>> doing. ;)
>
> 1: Running ant in framework/base, to compile src/start, does not update
>    ofbiz in $ofbiz.home.
> 2: move framework/base/src/start to $ofbiz.home/src, so that one
>    'component' doesn't actually really contain two.
>
>