[fedora-java] Introduction prior GSOC

[Stanislav Ochotnicky]

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 at redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com