Hello Luis!
I have now come back to commenting this...
Some comments on your comments (below).
2008/5/8, Luis Sergio Oliveira <[EMAIL PROTECTED]>:
> Hi Linus,
>
> Tom Morris wrote:
>
> On Wed, May 7, 2008 at 3:34 PM, Linus Tolke <[EMAIL PROTECTED]> wrote:
>
>> In order to attempt to straighten this out, I have written down some of
>> the results of the conversation in section 2.2 of the Cookbook. (Tomorrow
>> morning it will appear on the web site.)
>>
>
> For those who don't want to wait a day to see what it says, here's section
> 2.2. The new material begins after the large table and runs to the end of
> the section.
>
> Thanks Linus for having written these guidelines and thanks Tom for making
> them available so soon.
>
> I propose that there should be a bit more effort to make the life easier in
> all the sub-systems build files and in all the module build files by the
> core ArgoUML team. Although the documentation proposed is already a very big
> effort [thanks], I think that the cookbook should include the solution for a
> sub-set of the build.xml files that are most representative and possibly the
> ones that would have to be created and maintained by non-core ArgoUML
> developers.
>
> I propose that along with the guidelines, there should be made available a
> snippet of ANT wizardry that could be used in a copy/paste way by
> non-core-developers which would make the guidelines work. I see three
> targets:
> 1) sub-system build.xml files in core ArgoUML repository
> 2) sub-system build.xml files in a a different repository
> 3) module build.xml files in a different repository
>
> 2) and 3) would basically do the same thing and therefore their snippets
> will be the same.
>
I think this could be a good idea as long as it is kept short.
Adding targets for generating javadoc, running checkstyle, findbugs, or
something similar, will make this a nightmare of copying and pasting stuff
back and forth. That is why I have moved the running of these tools out of
each subsystems' build.xml and into the argouml-gen project. It is mostly
interesting from a static checks point of view and that is not necessary to
provide for each subsystem.
Other solutions could be thought of with each tool set-up provides a
build.xml file for inclusion but if we want to go that far I think we should
consider switching to a maven build instead.
> [...] Here ../argouml/build/*name* is only applicable in Eclipse layout,
> so it should be something like
>
>
> - For Modules that are developed in separate Tigris projects in the
> argouml-*name*/build.xml file use:
> - ../argouml/src/argouml-build/build/*name* in the repository layout
>
> - ../argouml/src/argouml-build/build/*name* in the Eclipse layout
>
> to refer to files needed to compile and run tests.
>
> No. In the repository layout I think it is a feature to provide everything
from the ../argouml/build just as every other project would provide things
from ../<project>/build. For this purpose i created the ../argouml/build.xml
file with the purpose of providing a similar behavior for the argouml
project as for all other projects. After having called the "install" target
in ../argouml/build.xml ../argouml/build/*name* is created.
In the Eclipse layout, ../argouml/src doesn't exist so this is wrong.
>
> -
>
> For the listed purposes, use the paths listed in the table, in all
> subsystems and modules.
>
>
> -
>
> *Table 2.2. Created things*
> What Where (under ./build) Result of the compilation of src/*tree*and
> build/java/
> *tree *or src_generated/*tree* classes/*tree* Result of the
> compilation of tests/*tree* tests/classes/*tree* Generated java code
> java/*tree *or ../src_generated/*tree*
>
>
I think we should decide on a single way of doing this and not have
recommendations that contains options. Using a directory under build is
borrowed from the maven setup. The benefit of this is that the clean script
is very simple. You can even do "rm -r */build" to clean out everything.
/Linus
