A person claiming to be Jeff Martin wrote: ;-)
>
> project - root element for the project definition
> --+@repository - repository to retrive project source code from
There may be need to specify additional information, so I would recommend
that this be changed from an attribute to an entity. All of my examples
are cvs specific at the moment, but I endorse the attempt to be
repository-type independent.
Examples of additional information I have needed so far are module (which
you have below), directory, and tag. Some or all of these should be
overridable at the workspace level (I see you have already implemented tag
there).
> --+@opensource - denotes that the source code should be displayed
> --+title - title of the project
> --+module - module name used to identify the project within a repository
> --+license - license under with the project is distributed
> --+--+@href - @location of the license
> --+description - description of the project
I had implemented a note entity at one point, and will get back to
re-implementing it. It simply gets output above the build logs in a box
and is intended to record some issues that have yet to be resolved.
> --+javasrc - root of java src for the project
> --+build - build definition for the project
Missing is any notion of specifying properties and their values. See
j2eeunit for a specific example.
> --+--+@file - ant build file to be used to build the project (defaults to build.xml)
Much like repository is meant to be independent of cvs, the build
definition should permit the use of other build tools.
> --+--+@target - ant target to be used to build the project (defaults to the default
>in the build file)
> --+--+@classpath - classpath to be used by ant when building the project
Can you expand on this a bit? What is it relative to? How is it combined
with the depend and optional tags? In gump, I have a work entity that
appears to fulfill a similar role. (Don't construe this as a comment on
the name of the attribute/entities - I don't tend to get excited over such
matters, besides I don't particularly care for the name "work" as used in
this instance anyway).
> --+test - test definition for a project
> --+--+@file - ant build file to be used to test the project
> --+--+@target - target to be used to test the project
> --+--+@classpath - classpath to be used by ant when testing the project
> --+depend - defines a dependency on another project in the workspace
> --+--+@project - name of the project
> --+option - defines an optional dependency on another project in the workspace
> --+--+@project - name of the project
> --+jar - defines an outputted jar from this project
What is this name relative to? Some projects create multiple jars, and
periodically change the name of the directory into which they are placed,
so factoring that information out may be helpful. In gump, this is the
"home" entity.
> --+--+@name - name of the jar
An additional "@id" would be helpful in constructing properties. See
jakarta-tomcat-40 for examples of referencing both other project's home and
specific jars.
> --+project - project can be nested within each other to define subprojects
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
