I am on vacation for 3 days, so if you don't hear from me, that's why.
If you do hear from me, then be startled as I didn't think I had inet
connectivity where I am going... One thing I do want to note - we talk
about JJAR as real - it isn't yet, it's a nice little commons-sandbox
project that is coming along nicely. Something to keep in mind. More
inline.
Jason van Zyl wrote:
>
> On 8/21/01 10:05 PM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
>
> > Our discussion revolved around making JJAR work against the gump
> > information repository rather than it's own information repository.
> >
> > My personal belief is that either
> >
> > 1) Gump should use JJAR to get dependency information. Using tools is
> > good.
>
> I think that all of a projects information should be stored in a single
> location. Gump has full inter-project dependencies, but what it lacks is the
> version info to build a release with stated versions of packages, and the
> project descriptors don't currently state their latest version. A few
> additions and building a project with specific versions of packages will be
> possible. This info will also be enough for a JJAR like task to assist with
> a build.
Two things come to mind - First, if Gump has this all, it doesn't need
JJAR. Of course, if a JJAR exists, Gump should consider using it.
I think that if we are going to produce a repository of project
information, it should be such that it doesn't tie tools together. For
example, Gump has information thats specific to what gump does (whatever
gump does - seems like gump is scope-creeping :). JJAR has needs
specific to JJAR.
So imagine that gump had gump stuff, jjar had jjar stuff, and in the
center is a dependency repository, containing enough information for
both to use, but no extra tool-specific drek. Of course, if this was
the case, then gump could use jjar, which would use the same info that
gump would have referenced if it needed repository information. (Leading
back, of course, to the "Why not just use JJAR?" question)
The counterargument might be that having one comprehensive repository of
project information is a Good Thing (which it prollie is...). However,
I wonder if its possible to have that sort of beastie in a manageable
way.... projects use different build methods (we can browbeat here in
Jakarta, but what about sourceforge and others?)
>
> I am fully aware of the need for version info because I plan to use Gump to
> build distributions of the TDK in a reliable way that will let any Turbine
> developer who wants to participate managing releases do so in a consistent
> fashion. We obviously must use stated versions of tools. This would allow a
> rigourous build of a distribution that would be consistent across machines.
>
Is this consistant with Gumps 'mission' or is this something new?
> > 2) If Gump doesn't want to depend on external tools and must define its
> > own dependency information, then it should make that dependency set free
> > of any gump specific schema structure or data, so that it can be shared
> > as widely as possible and let all tools that use it (gump included)
> > evolve in their own way w/o affecting the others.
>
> Again I see it as project information as a whole, if you have a better
> layout for dependencies I think it should be added the descriptors in the
> gump repository. I don't see them as gump descriptors. I see them as project
> descriptors that gump utilizes. I think that many, many tools can use these
> descriptors JJAR among them.
I agree in theory - however, I worry about it being practical to keep a
comprehensive repository of information.
The version dependency that JJAR needs is fairly simple and
straightforward - simply a list of versions and where I can find a jar
of each version. It doesn't matter how or where the project is created
and managed - as long as I can grab jars, that's all JJAR needs. It
really is all JJAR 'customers' need. Dumb-simple.
To summarize, I am indeed willing to try and work together - I mean I
did initiate by trying to figure out what Gump needs and tailoring JJAR
to provide that.
However, I tend to be a minimalist, and wonder if Gump would be better
off depending on another dedicated tool to provide the services that it
needs wrt dependencies.
Off to Montana. Big sky. No broadband.
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]
