Jason van Zyl wrote:
>
> On 8/17/01 11:31 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> > Jason van Zyl wrote:
> >>
> >> On 8/17/01 11:04 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> >>
> >>> Jason van Zyl wrote:
> >>>>
> >>>> On 8/16/01 12:04 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Jason van Zyl wrote:
> >>>>>>
> >>>>>> The dependencies are not detected for you. Geir's little dep engine
> >>>>> handles
> >>>>>> this nicely. I started with what I thought I needed for the TDK and
> >>>>> assumed
> >>>>>> the dependencies would be detected but they're not. Not a big deal as I
> >>>>> only
> >>>>>> have to do this once, but as projects changed it would be nice for these
> >>>>> to
> >>>>>> be detected so that you don't have to edit your profile when all the
> >>>>>> projects change their definitions.
> >>>>>
> >>>>> Where can I find Geir's little dep engine? Is it something that could be
> >>>>> called by gen.java?
> >>>>
> >>>> I think he put it in the commons ... hmmm it's not there so but it is in
> >>>> the
> >>>> commons sandbox along inside jjar. But the dep engine will go into the
> >>>> commons utils, that's the plan anyway.
> >>>
> >>> Sure, if it has a general use.
> >>>
> >>>>> In prior discussions with Geir, I got the impression that this was
> >>>>> intertwined with the downloading and recursion, but if I could have a
> >>>>> shallow set of dependencies provided, that would be great!
> >>>>
> >>>> I used the little dep engine for the java version and it works great.
> >>>
> >>> This is starting to sound like duplication of what already exists in the
> >>> jjar 'stuff', and is leading to a duplication - would it be possible to
> >>> simply use jjar to get the dependencies? That way, there would only
> >>> one set of dependency descriptors that could be used both for gumping as
> >>> well as for general project build and deployment use.
> >>
> >> Gump has been around a lot longer than jjar and has comprehensive dependency
> >> info that can easily be used for a lot more projects. I don't think using
> >> jjar to get the dependencies is the way to go. Alexandria and Gump, I feel,
> >> are more appropriate places for this information and that's what I'm going
> >> to continue with this weekend. I honestly feel that jjar should have been
> >> based on the descriptors long present in Gump.
> >
> > I thought you just redid them?
>
> 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.
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.
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.
Figured I would ask...
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]
