embedlets-developer

Re: [Embedlets-dev] Re: Ant hills

[Gregg G. W. <gr...@sk...>]

>Topic tags:[Arch][Wiring][Doc][HW][PM]
>_______________________________________________
>Gregg suggests:
>
>> ndeed!  My personal feeling is that any project that I can't load into my
>> IDE, (in different projects if command line limits are an issue), and push
>> the build button on, is not correctly designed.  Clearly, building without
>> an IDE is an advantage.  But, I would strongly suggest that the project
>> really should be buildable with some simple form of
>> 
>>  javac -d classes `find . -name '*.java' -print`
>
>Trust me on this one....we're gonna need Ant! 

And what build tasks are going to be so complicated?  Odd jar packaging? 
Building jar files with odd sets of files is about the only thing that seems 
plausible.  That is a production issue and shouldn't appear in the project 
structure.  Here's my desire...  You should always be able to unpack the 
source tree into a directory, and make it know to your IDE.  Adding your own 
source files, you should be able to compile into a single directory with 
'javac -d' command line(s).  You should be able to package this directory into 
a jar, and 'go'.  You should also be able to provide this directory in your 
classpath to JEMBuilder like tools and get a linked product.

It should not be necessary for developers to do any kind of manual steps to 
develop with the platform.  Now, they might also just put the jars in their 
classpath using the distribution jars.  But, if the want/need to customize 
classes therein, or otherwise recompile from source, that should be trivial, 
and just require unpacking the tree.

I am really against leaning against Ant for any configuration management that 
can also be done in the code itself where late binding can yield some other 
advantages.


-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-dev] Re: Ant hills

[Gregg G. W. <gr...@sk...>]

>Ant is basically an automation system, that can automate the creation of 
>dists, jars, setting classpaths, etc. It's the most common build system 
>in Java.
>
>If you have a project with source tree and libs, you need to still add 
>them to the classpath. With ant it's just "ant", and it's so in 
>Jbuilder, Eclipse, Netbeans, Jedit, Jext, etc.

Yes, it is an automation tool.  And, just like CPP is an automation tool, ant 
can be abused to do configuration management because it's possible.  The 
postgresql dist includes the use of Ant for no reason at all.  The build 
process is stricktly Linux/Make based, and Ant is not necessary when Make is 
already in place.

My IDE includes the ability to do all the things that Ant does, so I don't 
need to use Ant for my projects.  Running unit tests and other such tasks is a 
good use for running these tests portably.

The Ant task in postgresql does textual substitutions into the .java source 
files before building.  The same things can be done at runtime with 
properties. I just want to make sure that complexity is only a necessity, not 
a chain reaction.

-----
gr...@cy...  (Cyte Technologies Inc)

Re: [Embedlets-dev] Re: Ant hills

[Nicola K. B. <nic...@ap...>]

Gregg G. Wonderly wrote:
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
> 
> 
>>Topic tags:[Arch][Wiring][Doc][HW][PM]
>>_______________________________________________
>>Gregg suggests:
>>
>>
>>>ndeed!  My personal feeling is that any project that I can't load into my
>>>IDE, (in different projects if command line limits are an issue), and push
>>>the build button on, is not correctly designed.  Clearly, building without
>>>an IDE is an advantage.  But, I would strongly suggest that the project
>>>really should be buildable with some simple form of
>>>
>>> javac -d classes `find . -name '*.java' -print`
>>
>>Trust me on this one....we're gonna need Ant! 
> 
> 
> And what build tasks are going to be so complicated?  Odd jar packaging? 

docs build
unit tests
distributions (with proper signing)
webapps
anything that is not just "javac blah blah"

> Building jar files with odd sets of files is about the only thing that seems 
> plausible.  That is a production issue and shouldn't appear in the project 
> structure.  Here's my desire...  You should always be able to unpack the 
> source tree into a directory, and make it know to your IDE.  Adding your own 
> source files, you should be able to compile into a single directory with 
> 'javac -d' command line(s).  You should be able to package this directory into 
> a jar, and 'go'.  You should also be able to provide this directory in your 
> classpath to JEMBuilder like tools and get a linked product.

And does Ant make this impossible?

> It should not be necessary for developers to do any kind of manual steps to 
> develop with the platform.  Now, they might also just put the jars in their 
> classpath using the distribution jars.  But, if the want/need to customize 
> classes therein, or otherwise recompile from source, that should be trivial, 
> and just require unpacking the tree.
> 
> I am really against leaning against Ant for any configuration management that 
> can also be done in the code itself where late binding can yield some other 
> advantages.

Who ever said that with Ant based projects you cannot get the sources to 
build in an IDE?

Ant is basically an automation system, that can automate the creation of 
dists, jars, setting classpaths, etc. It's the most common build system 
in Java.

If you have a project with source tree and libs, you need to still add 
them to the classpath. With ant it's just "ant", and it's so in 
Jbuilder, Eclipse, Netbeans, Jedit, Jext, etc.

I don't see the problem, sorry.

-- 
Nicola Ken Barozzi                   nic...@ap...
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------