Quoting Deepak Bhole (2012-03-26 22:28:01) >> * Developing a Java based framework for matching results for single jar >> to that of [1] >> * Work on build environment to analyse the breakage at CLASSPATH and >> other relevant levels >> * Create a comparison based large database for analyzing or suggesting >> how to proceed ahead. > >Which developers would this target? If this is within the scope of >Fedora, it may not be of much use to external developers as Fedora >packages may have patches. Since this was my idea (more or less), I'll add my voice (even if a bit late). This is aimed at packagers (not just fedora ones) and I'd even say upstream developers themselves. If the implementation ever gets to the database phase, I would want to have Maven central artifacts scanned and compared for compatibility version by version. Let's say upstream releases new version of their library. From a packager POV, what I want to know: what was added/removed/changed. So I'd want to run a tool on old jar, new jar and get a nice output pointing out things that I should be careful about. Advanced version: I give the tool code that uses the library in question and the tool will point out only thing that are being used by the "application" code. So if some class in a library was removed but the code doesn't use it it will be specified as such. I.e. generally unsafe update, in this case OK. All of this in a parseable format ready for remixing and including in other tools. The database would just be aggregation of this basic information. >If it is for Fedora packagers only, it means that the packager will have >to know everything that their package uses, which may not always be the >case. This could be additional use case for the tool (which would need additional coding obviously) >Rather than maintain a database right away, for a first step, how about >making it so that the user can provide rpm for package X, rpm version 1 >of dependency Y and rpm version 2 of the same dependency, and then find >out what X uses from version 1 of Y and make sure it is in version 2? >This can be done as a standalone tool and would also lay some of the >groundwork for AutoQA in the future. I'd rather go the unix way of KISS and wouldn't care even about RPMs at all. What we need is to compare two CLASSPATH sets. What additions/removals/modifications are there between them, what possible problems could developers moving from jars on one classpath to another encounter (overriding new fields in supertype, perhaps some function modification etc, method removal etc.) That would be just a simple wrapper away from comparing of RPMs but would still not be tied to RPMs. >Please also keep Jigsaw[1] in mind when designing this (just from a design >perspective) as it will significantly change how Java handles dependencies. > >1: http://openjdk.java.net/projects/jigsaw/ I would like to keep this simple and shooting a moving target such as jigsaw would be kinda hard. We need to have some deliverable for GSoC ~3 months from the start of the project. That is including the documentation, probably web page and community engagement. Sure, nice design is important but shooting a moving target would not help... -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
