What was that the previous post? An error? More inline...
On 10/31/01 9:35 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > Geir Magnusson Jr. wrote: >> >> Sam, stay with us :) I didn't write that. I *know* GUMP ignores jars, and >> it does it's job well. I think it *should* ignore the jars. > > Count the number of ">"'s. ;-) I was quoting you quoting Stefano. You might then attribute it to him :) > >>> Once the project interdepencies problem is fixed, I expect the only >>> remaining impediment to a automatic fetcher of jars would be the Sun Binary >>> Code License. >> >> I don't see much of a project interdependency problem either. JJAR can walk >> the chain... > > OK, how do *YOU* solve the problem that Tomcat 4.0 includes a version of > Tyrex which won't work with log4j 1.2? Or that the next release of batik > won't work with the current release of fop? That's not the problem we are trying to solve with JJAR. GUMP attacks that problem through early warning, and heavy evangelism on your part. If the developer of tomcat states that tomcat:4.0 depends on tyrex:X and log4j:1.2, and they don't play together, then he/she made a mistake. I believe that the dependency chain is 'self cleaning' as it's version specific (notation A:X -> package:version ). With something simple : A:X depends on B:Y and C:Z Now, I assume that since the developer states the above as true, it was tested, and any implied dependency chains extending from B:Y and C:Z also work together, else the above statement about A, B and C isn't true. (Or it wasn't tested as such.) I know that this appears to be trivial - however, I think it isn't. Lots of problems get solved by recognizing this. Not all, but lots. > My assertion is that until we get more projects doing proper deprecation of > interfaces, the set of consistent versions of an arbitrary set of projects > will typically be the empty set except for those specific configurations > built by a human release manager (and many times these seem to include > non-release versions). First, I agree with the deprecation policy, and further offer that I have been guilty of the non-release sin, but always cleaned up the mess. However, for JJAR, we aren't talking about arbitrary sets here. For JJAR, it's just about getting specific things and their specific dependencies. How you mix projects is another problem that JJAR can't solve. I am not saying that it shouldn't be solved - but I think it's a combination of Gump and social work. >> So indeed its the licence, but Craig will fix that for us... :) > > That would be real cool. But, I wouldn't hold my breath... I'm not :) Consider the above 'social work'. > - Sam Ruby > > P.S. The quote above with ">>" prefix was by me. ;-) > Or anyone, if you quoted it... ;-> -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
