On 8/18/01 8:26 AM, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
> 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.
I believe it is a tool for continuous integration, the cruisecontrol site
references some papers (cruiscontrol.sourceforge.net). So after every CVS
checkin it tries to build the project again.
>>
>> 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.
Simply more project information. This can totally go in the descriptors we
have.
> 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]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
