----- Original Message -----
From: Sam Ruby <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 11, 2001 1:20 PM
Subject: Re: Alexandria project defs
> A person claiming to be Jeff Martin wrote: ;-)
I maintain this claim. I am Jeff Martin and so is my wife. ;o)
> >
> > 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).
>
Hmm not quite sure I can see the need to it as an entity (I take it you mean
element not entity e.g. & )
I think you can use @tag at the project level as well, but I'm not 100%
sure. What's the directory for?
> > --+@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.
Fair enough
>
> > --+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.
Oops missed that one of the list I have an arg element which performs the
same task as the property tag, just spelt differently. Test supports arg as
well.
>
> > --+--+@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.
So far I've been avoiding that one as it's a bit of a can of worms as far as
I can see. There are definitly things which Ant provides that make life a
lot easier i.e. XML output. But I'm open to suggestions for ways to do this
though if we support other build machanisms then we'll need to support other
doumentaion tools and LXR as well as JXR. Where will it end? ;o)
>
> > --+--+@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).
Err I think it's relative to the directory you run alexandria from, to be
honest I've never thought about it as I've alwayes used absolute paths in
it.
@classpath is probably a bit of a legacy attribute as it was in before the
depend/option concepts arrived. Although it does allow you to specifiy
classes/jars without defining a project for them.
>
> > --+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.
They're relative to the root of the project, the stuff around jar needs some
more thinking through on my part as I've not really used that whole area so
I've not come across these types of isssue
>
> > --+--+@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.
Not totaly sure what's going on in there but I'll have a poke around ;o)
>
> > --+project - project can be nested within each other to define
subprojects
>
> - Sam Ruby
>
Tah
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
