Craig McClanahan wrote: > > I noticed as I was updating dependencies for one of the packages I deal > with that the dependency cross reference produced by Gump: > > http://jakarta.apache.org/builds/gump/latest/xref.html > > only lists "first order" dependencies (i.e. those explicitly declared in > the <project> element. However, if you have the following set of > dependencies: > > * A depends on B > > * B depends on C > > then there is an implicit second order dependency of A on C -- and it > would be useful to identify and report such second (and higher order) > dependencies in a report like this. The required relationships should be > derivable from the data that is already available, so its MMP (merely a > matter of programming :-). > > A common motivation for looking at cross references is to tell you all the > JARs you need on your class path, and the Nth order dependencies report > would tell you that. It would also more accurately identify the set of > other packages that could potentially be broken by backwards-incompatible > API changes. > > Has anyone thought about implementing anything like this yet?
I have *thought* about it, but I don't have a good solution just yet. The primary problem is that I don't distinguish between a runtime dependency and a compile time dependency. The most extreme example: I build xerces with crimson, and crimson with xerces. If you chase down the dependencies, you will get both. Rumor has it that some servlet engines have been known to have trouble if both are in the classpath... ;-) Other clear examples are Ant and Junit. These often are compile time dependencies only. This means that the first step is to go back and annotate which of the dependencies are runtime and which are compile time. I've recently started making progress on these lines. But this has been a sideline activity and could befit from more focus by someone on the definition of the problem to be solved. If we can capture the semantics we want (i.e., what should a project definition look like which captures this information, and what is the output we desire), then I believe that the coding will be straightforward. Working forwards: There is a lot of raw data in the form of project definitions here: http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/ . One way to start small: could you take a whack at annotating the jakarta-commons.xml file so that only the jars you really want are included and everything else is excluded? Working backwards: What output do you really want? An HTML table with project names? I think that that would be interesting to look at but cumbersome to use. An XML description of the relationships, suitable for post processing? That might be more to the point. What would the DTD for such an XML look like? Or is what you really want is for the set of jars to be automatically collected and zipped/tarred up for ready download? Note: over the last week or two I've started something like that. Go to http://gump.covalent.net/jars/ . In addition to having the jars collated by project, there is a single "alljars.zip" suitable for download. Perhaps others can be produced during the process. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
