FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 03-23-2012, 06:11 AM
Vipul Amler
 
Default Introduction prior GSOC

Hi all,


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,


* 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.

* 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] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Java_API.2FABI_change s_checker

[2] http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker


Vipul A.M.

+91-8149-204995

--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 03-26-2012, 08:28 PM
Deepak Bhole
 
Default Introduction prior GSOC

* Vipul Amler <vipulnsward@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.

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_change s_checker
> 2. http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
> 3. tel:%2B91-8149-204995

> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 03-28-2012, 02:11 PM
Vipul Amler
 
Default Introduction prior GSOC

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


* Vipul Amler <vipulnsward@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 versionex.*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 jarsA<->B<->Cand their*incompatibility5. Scanning the whole hierarchy for class base

6. Change of method signature, which implies same meaning, but has actually changedexstring 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_change s_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@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/java-devel





--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 04-03-2012, 03:19 PM
Stanislav Ochotnicky
 
Default Introduction prior GSOC

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

PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 

Thread Tools




All times are GMT. The time now is 07:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org