Jason van Zyl wrote:
>
> On 8/18/01 12:32 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> >> I did originally when I did the first version of maven, but as they changed
> >> so much all the time I started working with the descriptors in gump and
> >> that's turned out to be the better route. Sam keeps them up-to-date and now
> >> I try to do the same.
> >>
> >> I gave up on the idea of redoing them and am working with what sam started.
> >
> > I meant 'you' in the collective sense, not personally - I have been in
> > and out of things and saw a long thread between you and sam discussing
> > changing and normalizing the descriptors.
> >
> > To get back to the issue, I don't think that gump is the right place for
> > them - I think that the right place for them is in the projects
> > themselves. I mean, each project is the best authority on what their
> > dependencies are.
>
> If you actually looked at the descriptors, you'll 'href' for the project
> descriptor. Sam kept this notion in mind, and I agree that it would be best
> for a project to maintain its own project information but having them stored
> all over the place might not be practical. I would definitely like to try it
> with gump.
I am guessing you won't be able to (or want to) get full distribution,
but having the major ones participate this way would be a good thing.
I'll let y'all know how it goes and maybe we can work something out
together.
>
> > Further, JJAR isn't intended to be in any way a competitor or
> > replacement of Gump - Gump fills a unique role in what it does, the
> > cross-building of projects against each other, and there is no need to
> > replace it.
>
> No but you are duplicating the project descriptors. Gump has started this
> and, whether they are distributed or not eventually, has the most
> comprehensive set of project descriptors so far.
Yes, they are getting pretty nice. You will need to get version
information in there,though.
>
> > JJAR is meant to be something entirely different - primarily a
> > 'CPAN'-ish system for Java, to make getting jars easy and painless.
> > No
> > more jars in CVS, and automatic fetching of dependencies. Recently I
> > added the notion of 'project repository kept by the project' and want to
> > see how it works. So far, pretty good in the toy example, namely the
> > Veltag JSP taglib in Velocity uses it's own repository descriptor for
> > it's build process, fetching the jars it needs (servletAPI and Velocity)
> > from the central repository. Dom4j is (hopefully) working on theirs, so
> > we can test this out with something more substantial (no one cares about
> > Veltag...). I will ask Jason Hunter if he can (or I can for him ) do
> > the same for JDOM.
> >
> > The point of sharing this information with Gump is that it solves the
> > problem for both tools, and further does it in a way that allows the
> > projects both within and outside of Jakarta to be involved by
> > maintaining their own projects' repository descriptor as well as their
> > released jars.
>
> So it hasn't occurred to you to use the descriptors in Gump, or help with
> the ones that are in Gump already? I asked to have information added that
> would allow Gump to work and provide the information for project
> dependencies for building. I guess you missed that message. I started down
> the same path, redoing the descriptors, and decided it was best to work with
> Gump in the context of Alexandria. They have been working on the idea of a
> project descriptor and a DTD for one for quite a long time.
Like I said - I only got into and out of the conversation. And Gump and
JJAR do not have the same functionality. Since JJAR needs richer
version/dependency information, I thought that JJAR could be integrated
with Gump to provide that info, removing Gump's need to maintain it. I
had Sam's attention for a little while on this issue :)
Gumps descriptors as I see them now still have no information about
version, and specific version dependencies, which are important to JJAR.
This I think reflects gump's purpose, which is version-blind
cross-project build testing.
JJAR and Gump will have some intersecting needs (dependency) and some
orthogonal needs such as tool specific information (for each) and JJAR
needs version by version dependency information.
>
> And you've already asked other projects to make descriptors completely
> ingoring what's in Gump?
Why would/could I do that? JJAR is just a sandbox experiment - we are
trying to see if it's worthwile doing this, and people are interested in
participating.
What's in gump doesn't seem to do the trick.
> Putting aside the fact that Sam and Jeff have been
> trying to get a DTD going?
A DTD for gump?
> Use what's already in place, in the context of
> the project that has been trying to deal with these issues?
I think it was pretty clear what I said. Gumps purpose was different
than JJAR. Since JJAR would need a richer dependency/version map, I
thought it cool to try to work with Gump and provide that info...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
