Hi java maintainers,

I have just created a package for the jaranalyzer tool [1]. This is a
tool that analyses and nicely displays dependencies between jars in a
given directory (either with graphviz as a .png image or as an xml
file). See readme.txt/man page for details.


I do not have a website where I can make the source available. But as
the package is very small I send it as an attachment.


I have tried to check everything so that any potential sponsor will
(hopefully) not have much review to do. The package:

- builds from source using free dependencies only
- builds with pbuilder
- produces no lintian messages

It builds with javahelper, cdbs, quilt and ant.

I now need a sponsor to review and (hopefully) upload the package. Is
there some DD out there who would like to sponsor the package?


Kind regards,

Florian

PS: Any idea where I could publicly upload test packages in the future?

[1] http://www.kirkk.com/main/Main/JarAnalyzer

I've had a quick look at the package and it looks ok, but I don't really
know cdbs, so I'm not that happy pronouncing it good right now.

I'll hopefully be able to have a better look in the next couple of days,
but if someone happier with cdbs wants to sponsor it in the mean time
then please go ahead.

Matt

--
Matthew Johnson

Am Sonntag, den 06.07.2008, 23:12 +0100 schrieb Matthew Johnson:
> I've had a quick look at the package and it looks ok, but I don't really
> know cdbs, so I'm not that happy pronouncing it good right now.
>
> I'll hopefully be able to have a better look in the next couple of days,
> but if someone happier with cdbs wants to sponsor it in the mean time
> then please go ahead.

The CDBS looks fine. IANADD, so I can't sponsor.

There are some things I'd like to add (but note the disclaimer above):

- I would not rewrite the upstream readme.txt. For the Debian-specific
explanations, README.Debian seems appropriate.

- There's a mistake in the readme.txt "apt-get graphviz" should be
"apt-get install graphviz".

- Cosmetics: In orig-tar.sh you could use single quotes in find instead
of double quotes to make the regex easier to read. Also, using single
quotes around {} prevents problems with spaces in filenames. (The
package does not have an of those files, but it won't hurt to use it.)

I do not have a possibility to check whether it builds at the moment.

Florian, thanks for your work on this!

Best regards
Manuel

Hi Eric, Matthew and Manuel,

thanks for your hints and for reviewing the package so quickly!

Manuel, I already made the changes you proposed. All of them were really
reasonable. I had to add -regextype ... to get rid of the backslashes in
find.. Single quotes alone wouldn't have done the job I think.


Eric wrote:

PS: Any idea where I could publicly upload test packages in the future?

this question is easy to answer :-)
Check http://mentors.debian.net/ and especially the Maintainer
Introduction.


The package is now available at [1]

Matthew wrote:

I'll hopefully be able to have a better look in the next couple of days,
but if someone happier with cdbs wants to sponsor it in the mean time
then please go ahead.


Matthew, if you find the time later, it's perfectly ok for me. I am not
in a hurry. I understand that you don't want to sponsor a package if you
have not been able to assure its quality.


The package is pbuilder- and lintian-clean on my machine so you should
hopefully be able to build from source without any changes.


Manuel wrote:

Can it be used to track changes in the method signatures or does it just
analyze inter-jar depenedencies?


No, method signatures are not checked. The tool just analyzes inter-jar
dependencies similar to java-propose-classpath within Matthew's
javahelper package. I find this very useful for packaging more
complicated java applications. The tool generates a very nice clickable
HTML-Report with all dependencies and further dependency statistics. See
the XML-part of README.Debian for an example on how to get the HTML.


As you are not able to build the package yourself I'll send you the
binary package so you might try it if you like.


Bye,

Florian

[1] http://mentors.debian.net/debian/pool/main/j/jaranalyzer/


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Florian,

Florian Grandel said:
>> Can it be used to track changes in the method signatures or does it just
>> analyze inter-jar depenedencies?
>
> No, method signatures are not checked. The tool just analyzes inter-jar
> dependencies similar to java-propose-classpath within Matthew's
> javahelper package. I find this very useful for packaging more
> complicated java applications. The tool generates a very nice clickable
> HTML-Report with all dependencies and further dependency statistics. See
> the XML-part of README.Debian for an example on how to get the HTML.
One more thought: did you check that the logic is the same between
Matthew's javahelper and your tool? Is code sharing an option?
The worse that could happen to packagers would be different results from
those two tools; I can already imagine the mess... ;-)

Thanks, Eric

--
Eric de France, d'Allemagne et de Navarre


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Tue Jul 08 10:12, Eric Lavarde - Debian wrote:
> Hi Florian,
>
> Florian Grandel said:
> >> Can it be used to track changes in the method signatures or does it just
> >> analyze inter-jar depenedencies?
> >
> > No, method signatures are not checked. The tool just analyzes inter-jar
> > dependencies similar to java-propose-classpath within Matthew's
> > javahelper package. I find this very useful for packaging more
> > complicated java applications. The tool generates a very nice clickable
> > HTML-Report with all dependencies and further dependency statistics. See
> > the XML-part of README.Debian for an example on how to get the HTML.
> One more thought: did you check that the logic is the same between
> Matthew's javahelper and your tool? Is code sharing an option?
> The worse that could happen to packagers would be different results from
> those two tools; I can already imagine the mess... ;-)
>
Well, neither of them can be used in an automated fashion due to
possible clashes in jars, so they are both just hints to the maintainer
when originally packaging the software and figuring out the
dependencies.

I don't think there's a big problem with the two existing together and
possibly giving different results.

Matt

--
Matthew Johnson

Hi Eric,


One more thought: did you check that the logic is the same between
Matthew's javahelper and your tool? Is code sharing an option?
The worse that could happen to packagers would be different results from
those two tools; I can already imagine the mess... ;-)


No. I have not compared the logic of both tools in a systematic way.

I however tried out the new tool on a jar that has a build dependency
not discovered by java-propose-classpath. (Compare last paragraph of
[1]) Both tools didn't show the dependency. So at least they are
consistent in that respect. ;-)


As I am using both tools just to facilitate my own packaging work I
won't be able to dive in now to find out why the dependency is not
discovered. Probably I'll find out sooner or later anyway.


I think both tools have their respective uses in different contexts (one
to do broad impact/dependency analysis and one to get a readily usable
classpath proposition). If one of the packagers finds different results
then I'll certainly help to analyze and interpret the difference.


Florian

[1] http://lists.debian.org/debian-java/2008/06/msg00042.html


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org