Sam Ruby wrote:
>
> Interesting thread!
>
> 1) I believe the eco-system is big enough for jjar, gump, and
> cruisecontrol.
Maybe. :) If jjar is pointless, then we can shoot it... It isn't
though, at the moment. Gump clearly isn't pointless, and I have no clue
about cruisecontrol - if it is what I remember, it's someone close to
both, more on the Gumpy side was my impression.
>
> 2) I don't honestly know where the right ultimate home for dependency
> information is. But as Jason has pointed out, that's why I put in href.
> However, I don't believe that the right next step is to completely jump
> completely to a decentralized system.
I don't think a totally decentralized system is right for a bunch of
reasons too - however, a totally centralized system won't be the final
solution either, (we are getting into Laffer curve land here :), so
there will be something in between.
>
> 3) Gump is not version blind. It just has a different opinion on who gets
> the final say on what version of JDBC or Xerces I get to run. I'd like the
> people maintaining a project to have some say. But I would also like the
> person who is building a profile like the TDK to be able to override and
> unify these choices. Finally, I would like the actual developer to be able
> to have the final word.
Of course. Some of the thinking bethind JJAR is that
1) Versions are specified carefully to allow the gathering of a complete
set of jars for the 'casual' developer or user to build or use a
project. That way, that casual developer or user doesn't have to a)
think about it or b) worry about debugging because some later version of
a dependency has bugs or isn't backwards compatible.
2) In the wildly unlikely chance that Gump would get dependency
information from JJAR, it can ignore the versions at it's choice - JJAR
doesn't force a version on you. It will tell you about versions if you
ask, you can ask specify the fetch a specific version of a project, or
ask for the 'latest' version if you don't care, or we can add a special
mechanism or convention to support the notion of 'latest development
version' that Gump tends to use (either the latest CVS snapshot, the URL
to the CVS itself, etc. In fact, the version could simply be 0.0-gump
or something, which would require no changes whatsoever.
3) For developers, again JJAR doesn't force a version. For convenience,
it will give you the proper specified versions of the dependencies in
the 'auto fetch' mode, but you can get the list of dependencies and
override the version information as you so choose. This is the last
part I am working on in the Veltag example, working out that little bit
- so I as a Velocity developer would override the specified 'release'
dependency for Velocity and use my own.
The emphasis is that JJAR isn't going to force anyone to do anything.
It's a convenience tool to save the time and aggravation of futzing
around finding the correct versions of that jars needed for a project.
>
> = = =
>
> It is going to be a fun next couple of weeks!
Indeed.
geir
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
