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 <[email protected]>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 <[email protected]> > To: [email protected] > CC: [email protected] > > 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 >
