* Vipul Amler <vipulnsward@xxxxxxxxx> [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.
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.
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/
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
> --
> java-devel mailing list
> java-devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
