Tom Morris wrote:
Apologies for the
html, but since the original was html formatted, it seems the only
reasonable way to continue the discussion...
You know what, I like violet. I'll consider
changing my tigris login and start using only html in the mailing
lists. Its a bit gay, but, wtf!?
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.
I thought yesterday on the possibility of a
"prepare" target in <xxx>/argouml-build/build.xml which would
generate a small property file (yeah ;-)) that could be found by the
external (i.e., different repository) build.xml files. This would
define the argo.root.dir and argo.build.dir properties, which are the
ones needed.
Say argouml/argo.base.build.properties. This would be found in the
repository and in the Eclipse layout in the same way at least for
external build.xml files. A similar idea comes to my mind for the
argouml/src/argouml-xxx/build.xml files.
So, generated properties might be useful after all :-)
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.
You're right. See above for a different proposal.
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 |
[...]
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
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.
Here ../argouml/build/name
is only applicable in Eclipse layout, so it should be something like
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?
Sorry, you're right.
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, what I meant was that we need to add
argouml-mdr.jar to the classpaths of those targets. Not internal
modules, but, just the built jars.
-
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
-
../../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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
