Jason van Zyl wrote:
>
> 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.
That's cool. That's my own personal behavior anyway, to make sure there
will be no surprises. Cool if it's automated.
>
> >>
> >> 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.
Since it seems that everything is being redone right now, from code to
descriptors... was the plans for the new Gump discussed on a thread I
missed?
>
> > 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]
--
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]
