build.xml ${lib.dir}

[Adam Heath <do...@brainfood.com>]

I'm currently looking at the executioncontext branch, and noticed
something in it's api/build.xml.  It makes use of a ${lib.dir} to
include local jars into it's classpath.  The assumption being you
might want to change the value of that.

However, it then hard-codes the lib name when accessing other
components jars.  That seems quite wrong to me.

And, this same pattern is used thru all build.xml.  I'm thinking we
should remove lib.dir, build.dir, etc, and just hard-code them.

ps: this really has nothing to do with executioncontext, and is a
general-purpose observation.

Re: build.xml ${lib.dir}

[Adrian Crum <ad...@hlmksw.com>]

Adam Heath wrote:
> Adrian Crum wrote:
>> I noticed that too. If a component doesn't have a lib folder, then the
>> build fails.
> 
> Actually, not completely correct.  If a component does *not* have a
> lib folder, but *does* include a reference in it's local build.xml,
> then it fails.
> 
> When creating a new component, if it doesn't have any libs, then don't
> add a path element for the lib folder.  Just don't copy an existing
> build.xml without looking it over.  It's just not that complex.

That's good to know. I never took the time to figure out why it was a 
problem - it was easier to just create the folder.

-Adrian

Re: build.xml ${lib.dir}

[Adam Heath <do...@brainfood.com>]

Adrian Crum wrote:
> I noticed that too. If a component doesn't have a lib folder, then the
> build fails.

Actually, not completely correct.  If a component does *not* have a
lib folder, but *does* include a reference in it's local build.xml,
then it fails.

When creating a new component, if it doesn't have any libs, then don't
add a path element for the lib folder.  Just don't copy an existing
build.xml without looking it over.  It's just not that complex.

Re: build.xml ${lib.dir}

[Adrian Crum <ad...@hlmksw.com>]

I noticed that too. If a component doesn't have a lib folder, then the 
build fails.

-Adrian

Adam Heath wrote:
> I'm currently looking at the executioncontext branch, and noticed
> something in it's api/build.xml.  It makes use of a ${lib.dir} to
> include local jars into it's classpath.  The assumption being you
> might want to change the value of that.
> 
> However, it then hard-codes the lib name when accessing other
> components jars.  That seems quite wrong to me.
> 
> And, this same pattern is used thru all build.xml.  I'm thinking we
> should remove lib.dir, build.dir, etc, and just hard-code them.
> 
> ps: this really has nothing to do with executioncontext, and is a
> general-purpose observation.
>