Apologies for the html, but since the original was html formatted, it seems
the only reasonable way to continue the discussion...
On Wed, May 7, 2008 at 3:34 PM, Linus Tolke <[EMAIL PROTECTED]> wrote:
What I think is the most controversial part is that I haven't
> mentioned property files. I think most of the current mess is because we use
> property files and especially include property files from other directories
> pointing out things in a third place. While writing this I was thinking that
> if we should use property files, their purpose is to list things that are
> provided by some subsystem i.e. jar files, settings, or tools. Because of
> that also the property file should be considered exported from the subsystem
> and not, as it appears now, an attempt to collect information from all over
> to reduce the amount of files. I would like to add this formulation too but
> I would like to consider more options on how to use property files first.
>
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.
> 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 might make the change in the modules and in the cookbook section as soon
> as consensus is achieved. What do you think?
>
> Please check my comments and revisions bellow. The revisions are in the
> violet color.
>
> PS: the package target in Eclipse layout isn't yet placing the results in
> argouml\build.
>
> Luis
>
>
> Tom
>
> 2.2. Source layout Prev Chapter 2. Building from source Next
> ------------------------------
> 2.2. Source layout
>
> [...]
> To handle the two layouts the following guidelines for writing ant scripts
> apply:
>
> -
>
> The same build.xml file is used, both for building from Ant in the
> repository layout and in the Eclipse layout.
> -
>
> In argouml/src/*subsystem*/build.xml use ../*subsystem*/build/*name* to
> refer to files needed to compile and run tests.
>
> Only references to subsystems depended on are allowed.
> -
>
> argouml-core-model-mdr and argouml-core-model-euml depend on
> argouml-core-infra and argouml-core-model and no other.
> -
>
> argouml-app should in the orthodox world depend only on
> argouml-core-infra and argouml-core-model. It depends also on
> argouml-core-model-mdr but only for running tests but that is because
> the
> tests are integration-level tests instead of tests for that subsystem.
> -
>
> argouml-core-diagrams-sequence2 and all other diagrams subsystems
> depend on argouml-core-infra, argouml-core-model, and argouml-app.
> -
>
> The "jar" target in argouml/src/*subsystem*/build.xml compiles the
> code, creates the directory build within *subsystem*, and copies all
> exported jars there.
>
> Since this build depends on jars in depended on subsystems, the target
> should first run the "jar" target in those subsystems.
>
> 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?
>
> -
>
> Especially generated java files, the class files as results of the
> compilation of source and tests, test results, javadoc report, and other
> generated reports shall be generated in directories to avoid being included
> in the release.
> -
>
> 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.
>
> -
>
> -
>
> 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?
>
> -
>
> 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.
>
> -
>
> The "jar" target in argouml-*name*/build.xml compiles the code, creates
> the directory argouml-*name*/build, and copies all exported jars there.
>
> -
>
> The "install" target in argouml-*name*/build.xml performs the "jar"
> target and copies all jars needed by the deployed application to
> ../argouml/build/ext.
>
> The release script includes the files from there.
> -
>
> 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*
> 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.
>
> -
>
> -
>
> Tools that reside in the tools directory are referenced using the
> property argo.tools.dir. Like this: ${argo.tools.dir}/*path to the file
> *
>
> The tools in question are the tools used for build and testing that are
> common to several subsystems.
> -
>
> Every build.xml file that uses tools from the tools directory shall set
> the argo.tools.dir property.
>
> This is done by testing for the existance of the *candidate-dir*
> /checkstyle/java.header file and the result should be set to:
> -
>
> ../../tools for subsystems in the repository layout.
> -
>
> ../argouml-core-tools for subsystems in the Eclipse layout.
> -
>
> ../../tools for argouml-build in the repository layout.
> -
>
> ../argouml-core-tools for argouml-build in the Eclipse layout.
> -
>
> ../tools for documentation in the repository layout.
> -
>
> ../argouml-core-tools for documentation in the Eclipse layout.
> -
>
> ../argouml/tools for other Tigris projects in the repository layout.
>
> -
>
> ../argouml-core-tools for other Tigris projects in the Eclipse
> layout.
>
> The reason for setting this explicitly everywhere is to reduce the
> amount of dependencies to a certain file or files and removes need to have
> that file available to calculate the paths.
>
> If the location of the tools directory will every change, there will be
> a major problem updating all projects.
>
>
