>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)
|
