Projects/Modules (and source dir / home dir / base dir)

["Adam R. B. Jack" <aj...@trysybase.com>]

I'm not making a very clear request here, I realize that, I'm just throwing
this out to see if anybody can help me...

I've never truly be comfortable with the module/project separation, and I've
been less comfortable with the concept of the 'location' of a project within
a module (if such exists).

I know some are averse to 'module' 'cos of it's CVS connotations/root, but
personally I don't have too much of a problem with that (even w/ SVN added.)
I think of module as a logical grouping in some SCM, and projects within
that. I figure that if one has issue w/ module then stick only one project
within it, and the issues are lessened. That said, what do folks think,
longer term? Ought we be migrating away from this CVS concept? [Skip this if
this is too engrained for now.]

My biggest problem is directories, and perhaps the names/meaning of some.
This could be 'cos I've come from the code out, and hence names are
confusing me. Maybe this is clear to the outside (from the metadata), just
that I can't see it. For directories ... I see that <ant has the concept of
'basedir' (relative to the <module, I believe) and this is for kicking off a
build. I see that <project can override this -- but it doesn't mean "this is
the area for a project under a module", it is not where "stuff is" (per se).
I see we have 'home' dir on a project, but that is for results -- not where
"stuff is". [I also see 'source directory' (a misnomer?) for a module. Not
sure if this get played w/ much.] Basically --- I feel a project (and it's
contents) are not clearly/easily specified. This comes in to play for users
specifying metadata, and also for when I'm trying to code default values for
these things. Can we have a concept of 'this is the root of a project under
this module' -- and perhaps allow values to be set when this doesn't work,
or do projects (in Gump) just not work that simply?]

For now, I'm seeing bugs in Gumpy due to me not getting this straight. I
read this [see link below], and I'd appreciate some guidance. Does it mean '
override', or does it mean 'override default'? If one has <project basedir=X
and <and basedir=Y ... would one really want X used? If so why? I'd be
tempted for X to override the default, but Y to be the final say on this.
That said, why set it on project at all -- what is the value?

http://jakarta.apache.org/gump/metadata/project.html#project

I'm starting to wonder if we need to take a step back and see if the Gump
metadata is exactly a model we'd like to continue with, or if we'd like to
migrate to something easier. Ought a project be a unit (under a
sub-directory) in a module, and do we

Please help w/ the "how it stands today" aspects of this mail, if not the
"Gump metadata of the future" ideas.

BTW: I suspect I'll one day read a raw Maven POM, for those project who use
Maven, but I'd like to get Gump metadata as clean as possible irrespective
of that.

regards,

Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com

Re: Projects/Modules (and source dir / home dir / base dir)

[Stefan Bodewig <bo...@apache.org>]

On Mon, 9 Feb 2004, Adam R. B. Jack <aj...@trysybase.com> wrote:

> For directories ... I see that <ant has the concept of 'basedir'
> (relative to the <module, I believe) and this is for kicking off a
> build.

Yes.  I assume it is named after Ant's own basedir attribute for the
project tag in Ant build files.

> I see that <project can override this -- but it doesn't mean "this
> is the area for a project under a module", it is not where "stuff
> is" (per se).

True.  As for overrides, see below.

Sometimes projects put build files into strange locations like a build
subdirectory of where "stuff is" and expect the build to be executed
from there.

> I see we have 'home' dir on a project, but that is for results --
> not where "stuff is".

because some projects tend to place the outputs in a very different
place than where "stuff is".  Take JUnit for example, it even moves it
outside of the current source tree.

> [I also see 'source directory' (a misnomer?) for a module. Not sure
> if this get played w/ much.]

Used by <property reference="srcdir"/>, I agree, it's not too
frequently used.

> Basically --- I feel a project (and it's contents) are not
> clearly/easily specified.

Because projects are neither clear nor easy 8-)

> Can we have a concept of 'this is the root of a project under this
> module' -- and perhaps allow values to be set when this doesn't
> work, or do projects (in Gump) just not work that simply?]

Hmm, take bootstrap-ant, ant and dist-ant.  Where does each project
live?  test-ant?

> Does it mean ' override', or does it mean 'override default'?

It means override.  This is not for a straight <ant> nested into
<project> case where the override mechanism doesn't make any sense.

It becomes important when you have multiple definitions for a
<project> and they get merged.  This gives you a chance to augment the
project definition (coming from Apache's Gump for example) with some
extra pieces inside your workspace definition.

See the rubypad.xml workspace where Sam has overridden the build
targets for Cactus and Xalan's smoketest.

> I'm starting to wonder if we need to take a step back and see if the
> Gump metadata is exactly a model we'd like to continue with,

Probably not 8-)

Stefan