Some comments on your mail too Tom!
2008/5/8, Tom Morris <[EMAIL PROTECTED]>:
>
>
> Minimizing the number of properties and keeping properties which are
> specific to a module or subsystem in that module or subsystem are good
> goals, but it seems unlikely to me that there won't be at least a few
> properties which are truly global. The build version is one thing that
> comes to mind. The location of the tools directory, as long as we are
> sharing it across all the different components, is another.
>
>
> On Wed, May 7, 2008 at 7:10 PM, Luis Sergio Oliveira <[EMAIL PROTECTED]>
> wrote:
>
>> 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.
>>
>
> We really need to minimize cloned code, even if it's just "snippets." If
> possible, this should be done another way, perhaps with a centralized
> antcall or some other mechanism.
>
When originally writing the build.xml files for other Tigris projects I had
the idea that it should be possible to develop a module without building the
core argouml tool. The terse description (using argouml-ada as an example)
would be more or less:
svn co <argouml-ada> argouml-ada
mkdir argouml/build
cd argouml/build
<Download and unpack the latest release of argouml>
The last three steps would be instead of checking out the whole argouml
project and building. I don't think this has ever been used but I have
probably been stuck to this picture mentally because I am having a hard time
to figure out how the centralized build file or part of a build file would
work.
What is your solution to this? The only one I can come up with is to use
subversion externals-magic.
[...]
>
>> Also jars that are not generated but provided by the subsystem are
> copied.
>
In other words, all provided jars, both generated and library dependencies,
are copied to this directory.
>
> -
>
> -
>
> In the repository layout, the "package" target in
> argouml/src/argouml-build/build.xml compiles all subsystems, creates
> the directory build in argouml/src/argouml-build and copies all
> exported jars from all subsystems there.
>
> The copying only copies files and not directories. For that reason make
> sure everything that is exported is in files and everything that is not
> exported in directories.
>
> It isn't at all clear to me what this is trying to say. Is the restriction
that all files must be in the top level build directory or is this trying to
say something else?
Yes, probably best to reformulate this unless Dave have done so already.
>> - In the Eclipse layout, the "package" target in
>> argouml-build/build.xml (same as above) compiles all subsystems,
>> creates the directory ../argouml/build and copies all exported jars
>> from all subsystems there.
>> -
>>
>> For this reason no Eclipse project shall be name "argouml".
>>
>> We should create a dummy project named "argouml" to reserve this space if
> we're going to write into it. That will also allow us to create appropriate
> svn:ignore properties.
>
>
We could also rename the project argouml-build to argouml to avoid copying.
>> -
>>
>> For Modules that are developed in separate Tigris projects in the
>> argouml-*name*/build.xml file use ../argouml/build/*name* to refer to
>> files needed to compile and run tests.
>>
>> 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
>>
>> Shouldn't this be <workspace>/argouml-build/build/*name* in the Eclipse
> layout which will be ../argouml-build/build/*name *relative to the
> module's top level directory?
>
Since this is a long list of jars that will be referenced from several
subprojects I would very much like to avoid having differing paths for the
two layouts. The whole purpose of specifying relative paths instead of doing
magic with properties is to avoid differing paths.
to refer to files needed to compile and run tests.
>>
>>
>>
>> -
>>
>> Only references to subsystems depended on are allowed.
>>
>> Modules should probably depend on argouml-core-infra,
>> argouml-core-model, and argouml-app and not anything else.
>>
>> Hmmm, the modules will always need to depend on a argouml-core-model
>> implementation to have "run" and "test" targets. Also, with the separation
>> of argouml-app into several sub-systems which live in a different project,
>> the modules that need to reverse engineer into diagrams that are implemented
>> in a separate project will need to depend on it. Or will these be always
>> placed in argouml.jar?
>>
>
> Modules shouldn't know the internal structure of ArgoUML. They should work
> against the packaged output. I think the packaged output directory is in a
> different place for the repository layout vs the Eclipse layout though, so
> this may need to be dealt with.
>
>
Yes, it should only depend on the packaged output but that means that the
dependencies to "hidded" subsystems is not enforced. On the other hand, it
is enforced in the Eclipse set-up, by specifying the project dependencies
more explicitly.
>
>> -
>>
>>
>> - 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*
>> XML result from tests tests/reports/junit/output/*XML-files* HTML
>> result from tests tests/reports/junit/output/html/*HTML-files* Complete
>> javadoc report javadocs Javadoc report exported functions only api
>> Instrumented
>> classes from build/classes/*tree* instrumented/*tree*
>>
>> I agree that src_generated is a better name for generated sources. I made
> this change recently for some of the modules that use ANTLR.
>
>
We shall recommend only one place.
[...]
/Linus
