[fedora-java] Introduction prior GSOC

Wed Mar 28 14:11:10 UTC 2012

On Tue, Mar 27, 2012 at 1:58 AM, Deepak Bhole <dbhole at redhat.com> wrote:

> * Vipul Amler <vipulnsward at gmail.com> [2012-03-23 03:11]:
> >    Hi all,
> >
>
> Hi Vipul,
>
> >    I am Vipul A. M. a Final Year Computer Science Student.
> >    I am interested to work on Java API/ABI changes checker proposed by
> >    Stanislav Ochotnický
> >    over here [1].
> >
> >    I have been having discussions with him for the past 1-2 weeks and
> >    getting to know more about the Java Packaging
> >    System needs on Fedora{and other, need of all platforms as he says},
> >    and the various pathways for [1]
> >
> >    Till now, I have been trying to understand more how and where the need
> >    for [1] is
> >    as also the available solutions, and pathways there could be. Me
> >    learning from Java API Compliance Checker [2] and others
> >    our discussions have come down to,
> >
>
> I think this is a great idea.
>
> >    * 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.
>
>
This aims at being platform independent, for the main features, i.e.
jar/class check. But pkgdiff would be specific to
Fedora.

> 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.
>
> Maintaining the integrity of such a database would also mean integration
> with Koji so that no one can upload some locally built package with the
> same version as in Koji and pollute the DB with bad data.
>
> 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.
>
>
Makes sense.

> 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/
>
>
There are some updates.
Some time before, Christopher O' Brein released Python-Javaclass [A] that
now has switches{for json} and
most of the functionality i previously listed.

So, my focus changes more over to feature additions to python-javaclass[A],
and addressing breakage issues

Listing a few of the breakage issues here:

1. Refactoring
2. Java-Compilation version
ex.
jar X, depends on jar Y which was compiled previously and now with some
incompatible environments
3.Java VM Versions {Code intended for}
4. Transitive Dependencies in jars
A<->B<->C
and their incompatibility
5. Scanning the whole hierarchy for class base
6. Change of method signature, which implies same meaning, but has actually
changed
ex
string arrays < - > varags

and many more.

I would now target feature additions:
* Address breakages
* Package python-java
* koji integration/ the DB for jar/rpm versions
* Create other switches{xml/html, etc}
* Provide a Web-Solution

I would like to invite any important features I should be considering.

Cheers,
> Deepak
>
> >    * Generate outputs of comparison{in different forms json,xml,etc} that
> >    could be further parsed for other purposes
> >    * Generate Web-View of the same
> >
> >    Some of the use-cases suggested for these are as below
> >
> >    Quoting Stanislav
> >
> >    "
> >    I envision following use cases:
> >    1. packagers will run this on new release of upstream jar, and old
> >    release of upstream jar, compare results and decide how to proceed
> >
> >    2. generate a big database of comparison data for a lot of different
> >    versions of various projects/jars where developers can go and see
> >    the stuff without actually running the tool themselves
> >
> >    3. [possibly in the far future] runs by automatic quality control
> >    tools such as AutoQA that would prevent an update to a package in a
> >    released version of distribution that would break compatibility.
> >    "
> >
> >    So,
> >
> >    what I would try and target more in {the very small 3 months of} GSoC
> >    ,is to first develop a base solution that does
> >    proper analysis and breakage detection at singular unit of jar/build
> >    environment.
> >    After a good base try and handle as many features suggested above, in
> >    future.
> >
> >    I would like hear your thoughts/criticisms, to help me identify any
> >    other approaches.
> >
> >    Cheers
> >
> >    [1]
> >    [1]
> https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Java_API
> >    .2FABI_changes_checker
> >    [2]
> >    [2]http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> >
> >    Vipul A.M.
> >    [3]+91-8149-204995
> >
> > References
> >
> >    1.
> https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Java_API.2FABI_changes_checker
> >    2. http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> >    3. tel:%2B91-8149-204995
>
> References:
[A] https://github.com/obriencj/python-javaclass

> > --
> > java-devel mailing list
> > java-devel at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/java-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/java-devel/attachments/20120328/ed46b365/attachment.html>