[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFP 702564: graphtea -- software framework to work on graphs



Hi Tony

Thanks.
No, we do not use that library,
we use this library: https://code.google.com/p/jgoogleanalyticstracker/.

Then we need only to package this library, and other ones make no problems.

Regards,
Ali


On Thu, Mar 28, 2013 at 5:50 AM, tony mancill <tmancill@debian.org> wrote:
Hello Ali,

Thank you for clarifying the question about matlab - I was wondering
whether the Matlab-related JARs would be difficult from either a
packaging or licensing perspective.

For the remaining libraries, 3 of them are already packaged and found in
Debian:

jama
Package: libjama-java
Version: 1.0.2-4

gson
Package: libgoogle-gson-java
Version: 2.1-2

bsh
Package: bsh
Version: 2.0b4-12

It appears that JGoogleAnalytics would need to be packaged.  Is that the
same package by BoxySystems [0] that links to source here [1]?  The
reason I ask is because the source available there is for version 0.4,
whereas the library listed below is version 1.2.1.

Cheers,
tony

[0] http://boxysystems.com/index.php/portfolio/jgoogleanalytics/
[1] https://code.google.com/p/jgoogleanalytics/


On 03/27/2013 02:35 AM, Mohammad Ali Rostami wrote:
> Hi Java team,
> Hi Adrian,
>
> I removed the ones which are not used any more.
>
> *jmatlink.jar*, *javabuilder.jar*, and*matlab.jar* are related to the
> connection to *Matlab *
> which was finalized just in Windows.
>
> As there are some bugs in Linux, if these jar files inclusion is not
> easy, they can be ignored for now.
>
> Then it remains the following libraries:
> - /Jama:/ Java matrix library
> - /bsh-2.0b4/ (beanshell): For Graphtea console/shell
> - /gson-2.1/: For redo and undo
> - /JGoogleAnalytics-1.2.1.jar/: For some statistics on which
> algorithm/report/construction of graphs are used the most.
>
> Regards,
> Ali
>
> On Tue, Mar 26, 2013 at 11:03 PM, Adrian Knoth
> <adi@drcomp.erfurt.thur.de <mailto:adi@drcomp.erfurt.thur.de>> wrote:
>
>     Hi Java team,
>
>     I'll simply forward the mail sent to the science team. Consensus was to
>     coordinate with you, since you're the experts on Java packaging.
>
>     To make things easier, here's a list of the currently embedded copies
>     the mail was talking about:
>
>
>     https://github.com/graphtheorysoftware/GraphTea/tree/master/src/scripts/lib
>
>
>     Some can be dropped without losing all the functionality, just in case
>     licensing issues hinder archive inclusion. (Ali, which one exactly?)
>
>
>
>     WDYT?
>
>     -------- Original Message --------
>     Subject: RFP 702564: graphtea -- software framework to work on graphs
>     Date: Fri, 08 Mar 2013 15:23:30 +0100
>     From: Adrian Knoth <adi@drcomp.erfurt.thur.de
>     <mailto:adi@drcomp.erfurt.thur.de>>
>     To: debian-science@lists.debian.org
>     <mailto:debian-science@lists.debian.org>
>     CC: rostamiev@gmail.com <mailto:rostamiev@gmail.com>
>
>     Hi Science Team,
>
>     I'm member of the Multimedia Team, so my colleague Ali (here at my
>     university) approached me how to get his software included in Debian.
>
>
>     I feel it qualifies for field::mathematics, though it has some overlap
>     with education.
>
>     He has no experience in packaging, but I can help a bit, however, I
>     think team-maintenance is the way to go for the sake of continuity.
>
>
>     I've never worked with java before, I don't know how to properly package
>     a java application in Debian.
>
>     Looks like DH7 can handle the ant-based build process. There are some
>     jar files in the "source". Is this acceptable? I feel we either need to
>     depend on other packages (bsh, libjama-java, some unpackaged) or build
>     the relevant jars while building the application, though this would make
>     them embedded source copies.
>
>     The proper approach is to package all dependencies, right?
>
>
>     The github source contains unnecessary files like an OSX app (binary) or
>     a Windows bat file. I can make this DFSG clean, also wrt the mentioned
>     dependencies.
>
>
>     Questions:
>
>        1. Is the Science Team interested in maintaining this package?
>        2. Any preference regarding DH vs. cdbs?
>        3. Java experts around who know how to handle the dependencies?
>
>
>
>
>     Cheers
>
>




Reply to: