2008/5/8, Luis Sergio Oliveira <[EMAIL PROTECTED]>: > > 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. >
Interestingly enough both you and Tom mention two examples each of properties that are needed and they are not the same. ;-) I am still thinking that none of these are needed and my reasoning is this: build version - maintain manually in some java source file or generate/keyword from subversion. location of tools directory - junit, jdepend, easymock - used for testing. Not really solved. argo.root.dir - used only to find the location of the argo.tools.dir and argo.build.dir can be removed argo.build.dir - not needed. Use ../argouml/build instead! 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 >> ------------------------------ >> 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? > > 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. > If you look at, for example, the build.xml of the argouml-cpp project, you can see for building the code a specified set of jar files are used. For running, all jars (*.jar) are used. >> - >> >> [...] >> >> /Linus
