Bug#797835: new upstream releases

[Daniel Pocock]

Given the nature of this package (phone number country, region and
network codes are volatile) we probably need to just update to the
latest upstream version but I haven't had time to get onto that while
doing other releases.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#758611: include all modules?

[Daniel Pocock]

Package: maven-debian-helper


When running mh_make I see the prompt:

This project contains modules. Include all modules?
[y]/n 


What exactly does this mean - is it about what should be built or what
should be included in the binary package?

For my own package, some of the modules need to be built and used at
build time but they do not need to be included in the binary package
that is produced.  Should I say yes or no for such modules?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#758051: upstream changing to Maven

[Daniel Pocock]

The upstream build system is currently hybrid Maven and Ant

I'm adapting it to be just Maven and the next package upload uses
maven-debian-helper exclusively, hopefully that will resolve the problem
and then this bug can be closed.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#758639: creates extra .poms file

[Daniel Pocock]

Package: maven-debian-helper

When creating the source package for libphonenumber, I notice that an
extra file is created, debian/libphonenumber6-dev.poms

The binary package libphonenumber6-dev doesn't actually contain any Java
artifacts, it is for the C/C++ headers.

debian/rules was created by merging the results of mh_make with
upstream's directives for cmake.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740554: mangles classpath in upstream manifest

[Daniel Pocock]

On 05/03/14 13:57, Emmanuel Bourg wrote:
 Le 04/03/2014 07:48, Daniel Pocock a écrit :

 When I search for Debian Java mvn packaging, Google had referred me to
 this wiki:

https://wiki.debian.org/Java/MavenRepoHelper

 which suggested using libplexus-io-java as an example. That is using
 maven-ant-helper
 Good point, the wiki is confusing. libplexus-io-java is an example
 showing how to use maven-repo-helper, but it shouldn't lead to use
 maven-ant-helper. jsch is a better example for projects without a Maven
 build.

So it looks like

a) the page I should have looked at is
https://wiki.debian.org/Java/MavenBuilder

b) that page talks about maven-debian-helper

c) however, it is using cdbs in the examples (whereas I'm trying to use dh)

d) jsch seems to be using cdbs and maven-repo-helper

I have a couple more packages I want to make this week, using
maven-debian-helper + dh - could you point out any example of a package
I should refer to?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740554: mangles classpath in upstream manifest

[Daniel Pocock]

On 23/04/14 16:51, Emmanuel Bourg wrote:
 Le 23/04/2014 16:34, Daniel Pocock a écrit :
 
 I have a couple more packages I want to make this week, using
 maven-debian-helper + dh - could you point out any example of a package
 I should refer to?
 
 maven-debian-helper isn't as well integrated with DH as it is with CDBS,
 I strongly recommend using CDBS if you want to package a simple Maven
 based project.
 
 jsch is an Ant based project. The package uses maven-repo-helper to
 deploy the Maven artifacts in /usr/share/maven-repo.
 

Ok, I'll go with CDBS for now

Can you suggest a good example of CDBS + maven-debian-helper for a Maven
project that produces multiple JARs?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740554: mangles classpath in upstream manifest

[Daniel Pocock]

On 03/03/14 01:36, Emmanuel Bourg wrote:
 Hi Daniel,
 
 maven-ant-helper was useful to build the Maven dependencies when Maven
 wasn't packaged yet (or to break circular dependencies). It's a limited
 implementation of the Maven lifecycle using only Ant, and it can't
 really aim at being on par with Maven in all areas. For jmxetric I would
 advise using maven-debian-helper instead.
 

Hi Emmanuel,

Thanks for this feedback

When I search for Debian Java mvn packaging, Google had referred me to
this wiki:

   https://wiki.debian.org/Java/MavenRepoHelper

which suggested using libplexus-io-java as an example. That is using
maven-ant-helper

I don't mind changing my packages to use the maven-debian-helper, but I
will look at that next time I update them.

Regards,

Daniel

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740441: suggest jmxetric, provide convenient way to enable it

[Daniel Pocock]

Emmanuel Bourg ebo...@apache.org wrote:

jmxetric looks interesting but I don't think tomcat7 should suggest a
monitoring tool, apache2 doesn't suggest nagios3 for example.



The difference is that jmxetric does JMX, so it is specific to Java app 
servers, of which tomcat is obviously the most well known

It also suggests that Debian has tested the things together, which reassures 
users that it will just work.

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740554: mangles classpath in upstream manifest

[Daniel Pocock]

Package: maven-ant-helper
Version: 7.7
Severity: important

In debian/build.properties (for the jmxetric package) I have

manifest=src/main/resources/META-INF/MANIFEST.MF


to copy the upstream manifest

The manifest contains:

Manifest-Version: 1.0
Premain-Class: info.ganglia.jmxetric.JMXetricAgent
Boot-Class-Path: oncrpc-${oncrpc.version}.jar
gmetric4j-${gmetric4j.version}.jar
Can-Redefine-Classes: false



The long line is messed up in the JAR produced by maven-ant-helper:

a) the long line is broken

b) the version substitution is not done

As a workaround, I can supply a modified manifest instead

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740441: suggest jmxetric, provide convenient way to enable it

[Daniel Pocock]

Package: tomcat7
Severity: wishlist


It would be useful to suggest libjmxetric-java and provide a convenient
way to enable it.

If enabled by the user, it needs to be added to the JVM boot classpath
as described here:

http://danielpocock.com/monitoring-jboss-tomcat-and-application-servers-with-jmxetric

In practice, this may just mean providing a sample, commented JAVA_OPTS
in /etc/default/tomcat7 and some comments in README.Debian

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#740441: sample /etc/default/tomcat7 entries

[Daniel Pocock]

Adding this to /etc/default/tomcat7 makes it work with the default
ganglia-monitor configuration on Debian



# for JMXetric
# - install packages ganglia-monitor and libjmxetric-java
# - cp /usr/share/doc/libjmxetric-java/jmxetric.xml \
#   /etc/ganglia/jmxetric-tomcat7.xml
# - edit jmxetric-tomcat7.xml to your requirements
#  (bare minimum: change ProcessName to tomcat7)
# - and then uncomment the variable assignments below:
#JARLIB=/usr/share/java
#GANGLIA_ETC=/etc/ganglia
#JMXETRIC_CFG=${GANGLIA_ETC}/jmxetric-tomcat7.xml
#JMXETRIC_PARAMS=host=239.2.11.71,port=8649,wireformat31x=true,mode=multicast,config=${JMXETRIC_CFG}
#JAVA_OPTS=${JAVA_OPTS} -Xbootclasspath/p:${JARLIB}/oncrpc.jar
#JAVA_OPTS=${JAVA_OPTS} -Xbootclasspath/p:${JARLIB}/gmetric4j.jar
#JAVA_OPTS=${JAVA_OPTS}
-javaagent:${JARLIB}/jmxetric.jar=${JMXETRIC_PARAMS}

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733996: Generate a ‘closure-compiler’ binary package for the compiler program

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 05/01/14 06:16, tony mancill wrote:
 On 01/04/2014 07:07 PM, Ben Finney wrote:
 
 The binary ‘closure-compiler’ package would install:
 
 * the ‘/usr/bin/closure-compiler’ command (perhaps a symlink, as
 now)
 
 * the manpage (not yet written?)
 
 * the ‘README’ file (or some subset the describes running the
 compiler from the command line)
 
 * maybe others
 
 My main point in responding to your message is: the binary 
 ‘closure-compiler’ package will not be empty. It will need to
 install files distinct from the ‘libclosure-compiler-java’
 package.
 
 Hi Ben,
 
 There isn't currently a manpage - the documentation I've seen
 regarding using it refers to invoking it as a jar file (see [0],
 and more generally [1]).  Given that all of the upstream
 documentation is focused on invoking it as a jar file, I think
 we're on our here, at least at the start.
 
 I agree that the package should have a manpage if we're going to 
 continue to provide the /usr/bin/ symlink.  Daniel added this in
 the -3 upload.  If you or Daniel can contribute a manpage, that
 would be great.

In cases where upstream doesn't supply a man page, several packages
have created their own trivial man page and it is kept in
debian/something.1 or whatever, providing the bare minimum of information.

If we make a more comprehensive man page, we should try to contribute
it upstream so they will keep it in sync

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSyQwcAAoJEOm1uwJp1aqDoEwP/2JqVy94N2RJQOKOpFQ88a+M
z08HUkQJuNnXbqqftEi0qK0T7nCMVAkf50cLCGiXyuSD2Fz2n5yh7XyKcedSMsN7
iTj8cEsLAffeBYjgIltQDaqwWvOVwMTj7KdmFssNWCOP/Ip8Bt2+D3nnHInGNglo
7Dy09a6hQ6K4HigNgdXD3Mt2sAzFhJ1qb0YXLlNHgQSSjYPICBU58Y6gFKsoGPY7
AAYlOc9lnbgnsPcb73c7WSjpD5ItWDww07QjhUSgWYC8DY59JvePr59p9EvJDvbN
bRRA7w7v8cIuxs0vY6gUJMYGYx2cwadTQRA+DdVPZA95eDHqqxx8SUTXFLZVhIdy
DAQf68zrk5cr1VduV282YxUSbsieURGYTI96f3OpR99+p6Vp66Ha/oWqZY337CMU
4D9JGxXOQW6sNdi6DNB9AyrsBPjXBJ2e0omFQzM6LbZrakOxKEr3pSPjWyYzsL3q
MIeEc3EMwAXVOEX4jmXhU6mfSnyjJ6Wm3gWLkA8uET9j8/GAXExAN4+pid63qOo7
gwSgegSZVY+YWVdE2oTHjUzgxczJImf2AUJvG6YNIi3Nl67vlJTiltV0nF/vYafS
35V0GMmjeifWEUTRk5hEfCVOr1R2i5xTOtBv5BoaEnK+6S5FOGP/uwp3gEcBm4hl
NSy2ByIPCBbmK4QJERhv
=nca8
-END PGP SIGNATURE-

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

[Daniel Pocock]

On 30/12/13 00:48, Rogério Brito wrote:
 Hi there.

 Can we have a late Christmas present (or even an New Year's present)? The
 closure compiler:

 * has already been removed from testing [1]
 * has many applications and users that depend/want it
 * already has patches in the BTS [2]

 [1]: 
 http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html
 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565

 Given this information, could we have something (even a NMU) to fix this?


Tony made some commits in Git and it appears he is working to resolve this

The rename of the binary package from libclosure-compiler-java -
closure-compiler should probably be done now as well to get this out of
the way well before the Jessie release.

I've made the changes for a rename on a branch called pkgrename and
pushed that into Git

Tony, are you making another upload shortly, would you like to merge
pkgrename perhaps?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

[Daniel Pocock]

On 30/12/13 20:35, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to resolve this

 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.

 I've made the changes for a rename on a branch called pkgrename and
 pushed that into Git

 Tony, are you making another upload shortly, would you like to merge
 pkgrename perhaps?
 
 closure compiler is also a library dependency, e.g. of gwt. It might be a 
 good 
 idea to provide two binary packages, one for the library jar and another one 
 for the manpage + executable.

That is awkward with an executable JAR, it is just a single artifact
that can be used either way

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 30/12/13 21:03, tony mancill wrote:
 On 12/30/2013 11:54 AM, Daniel Pocock wrote:
 
 
 On 30/12/13 20:35, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to
 resolve this
 
 The rename of the binary package from
 libclosure-compiler-java - closure-compiler should probably
 be done now as well to get this out of the way well before
 the Jessie release.
 
 I've made the changes for a rename on a branch called
 pkgrename and pushed that into Git
 
 Tony, are you making another upload shortly, would you like
 to merge pkgrename perhaps?
 
 closure compiler is also a library dependency, e.g. of gwt. It
 might be a good idea to provide two binary packages, one for
 the library jar and another one for the manpage + executable.
 
 That is awkward with an executable JAR, it is just a single
 artifact that can be used either way
 
 It means that the closure-compiler binary package is merely the 
 /usr/bin/ symlink and the dependency on jarwrapper.
 
 I don't know that it really matters much - the reason for the
 rename is to make the binary package easier to find, but the
 current java library package is named correctly (as per policy and
 ease of locating) as well.
 
 I'm not sure if there is a best practice for executable JARs that
 are used in both contexts, but adding an additional binary package
 doesn't seem too bad.
 

- From a useability perspective, I agree that the two packages is more
appealing

I'll change my own packages to depend on closure-compiler when it exists

I'd suggest doing the new binary package before doing the update to
the latest code, then it will be easier for the FTP masters to review

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwdJ9AAoJEOm1uwJp1aqDFocP+wV2PFBQl4/4YBc/Hn/UJEhR
wWhLJS8LlqHzqb3y+f5V/ezK55AYx/G0RWBSWxhsh9xmmOZFF4xqlF/k3wY2kjt4
YehjW8Px+Kn3VDLsb0Fyo6CSGk7N8rathGtcYbLIWDu2Qs/btlucPkdpk4Q8eoYM
tf7eMs15tESNyVNkYGSbQ4Tltj1g6W/ZWlXxRnSPVBLSqUBqlXMoUcq/sFgsa/in
OpSiszWakp99AMv6MubvM25kKKvlMzVhK9gf2OZ1I8JiX5dFiHw+/liRpRDDnFY+
mfNnvD58LNEvkVVV9xWCG3yVkj8uby8Zd3tBOn4MH2LuagUUUXdFL7neM2l+sSIi
04wua8i7nP0xyqc04Lxvkyt3Se6ro0Vsx6GKfXmR4kcoHjTmJGyWFTru4nPBd9QP
9Iqsk82Ym017nY181+NClgZZDmzxcR3xn8Lv29Adv4rYju4wOfoy6GGQUd2Iwyat
6OP3roxd03bOWXhIi83U72JWwCOxV00RVtLXfmWQFYD2Z6Yt5R4cCJXeZs8/sJZF
sOpWWqadbGlUZViN0CJEuTIOBsZQFSt+hQxhNDMD0BFqgnybSkcmEg0j4USougNB
lc5jOieLL9V3MoB/El5ht9dylzv9XK5vFG385U94YflxpVuV0MJ4cmyF4L1tRHSX
yNzQjg+CE79snZpN8usR
=BMiD
-END PGP SIGNATURE-

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: fixing closure-compiler, package rename?

[Daniel Pocock]

I've added a fix for the manifest, this should close the bug and make
the package useful as a build dependency

Can somebody please give me write permissions on pkg-java so I can push
this?

javahelper has been used to achieve this, I saw an example of this in
another package.  If there is a better way to do this with the
maven_repo_helper please feel free to improve on my fix.

It is now possible to install the package and just type

$ closure-compiler -h

and it shows help output.

Should it continue to be called libclosure-compiler-java.deb or should
it just be closure-compiler.deb now that it includes an executable?

I haven't uploaded though - please let me know if I should upload or if
somebody else has work in progress


From f3a53a7ea17f51da7c19ef976e2015a5f1cb03b3 Mon Sep 17 00:00:00 2001
From: Daniel Pocock dan...@pocock.com.au
Date: Fri, 11 Oct 2013 11:38:47 +0200
Subject: [PATCH 1/3] Add manifest entries for classpath and main class

---
 debian/control   |2 +-
 debian/libclosure-compiler-java.manifest |3 +++
 debian/rules |2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)
 create mode 100644 debian/libclosure-compiler-java.manifest

diff --git a/debian/control b/debian/control
index 475d354..3bd0169 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: Thomas Koch tho...@koch.ro
 Build-Depends: debhelper (= 9), default-jdk, maven-repo-helper (= 1.7.1), junit4,
  libandroid-json-org-java, libprotobuf-java, libargs4j-java, libguava-java, libjsr305-java,
  librhino-java (= 1.7R4), ant, libjarjar-java, protobuf-compiler,
- libmaven-ant-tasks-java
+ libmaven-ant-tasks-java, javahelper (=0.25)
 Build-Depends-Indep: default-jdk-doc, libmaven-javadoc-plugin-java
 Standards-Version: 3.9.4
 Vcs-Git: git://anonscm.debian.org/pkg-java/closure-compiler.git
diff --git a/debian/libclosure-compiler-java.manifest b/debian/libclosure-compiler-java.manifest
new file mode 100644
index 000..b0afce9
--- /dev/null
+++ b/debian/libclosure-compiler-java.manifest
@@ -0,0 +1,3 @@
+usr/share/java/closure-compiler.jar:
+ Class-Path: /usr/share/java/closure-compiler.jar/usr/share/java/args4j.jar  /usr/share/java/guava.jar/usr/share/java/json.jar
+ Main-class: com.google.javascript.jscomp.CommandLineRunner
diff --git a/debian/rules b/debian/rules
index 3df5fc2..302665a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,7 +3,7 @@
 JAVA_HOME  := /usr/lib/jvm/default-java
 
 %:
-	dh $@ --with maven_repo_helper
+	dh $@ --with maven_repo_helper,javahelper
 
 override_dh_auto_build:
 	ant -propertyfile debian/ant.properties jar-nodeps javadoc
-- 
1.7.10.4

From 04aae7ec61db1e2ed6b3bdb12d3b0bab04b823e3 Mon Sep 17 00:00:00 2001
From: Daniel Pocock dan...@pocock.com.au
Date: Fri, 11 Oct 2013 11:46:26 +0200
Subject: [PATCH 2/3] Add symlink to usr/bin

---
 debian/libclosure-compiler-java.links |1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/libclosure-compiler-java.links

diff --git a/debian/libclosure-compiler-java.links b/debian/libclosure-compiler-java.links
new file mode 100644
index 000..c8edc77
--- /dev/null
+++ b/debian/libclosure-compiler-java.links
@@ -0,0 +1 @@
+/usr/share/java/closure-compiler.jar /usr/bin/closure-compiler
-- 
1.7.10.4

From 8f1de0ac7c5f968ac0882a859db5006f2294c491 Mon Sep 17 00:00:00 2001
From: Daniel Pocock dan...@pocock.com.au
Date: Fri, 11 Oct 2013 11:48:15 +0200
Subject: [PATCH 3/3] changelog: manifest and symlink

---
 debian/changelog |4 
 1 file changed, 4 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 3da8f29..04d27e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 closure-compiler (20130227+dfsg1-3) UNRELEASED; urgency=low
 
+  [Emmanuel Bourg]
   * Team upload.
   * Backported a change replacing the deprecated LimitInputStream class
 in Guava with ByteStreams.limit()
@@ -7,6 +8,9 @@ closure-compiler (20130227+dfsg1-3) UNRELEASED; urgency=low
   * Removed the build dependency on ant1.7
   * Removed unnecessary changes from build_xml.patch
 
+  [Daniel Pocock]
+  * Add manifest and symlink for runnable JAR (Closes: #705565)
+
  -- Emmanuel Bourg ebo...@apache.org  Thu, 12 Sep 2013 12:46:47 +0200
 
 closure-compiler (20130227+dfsg1-2) unstable; urgency=low
-- 
1.7.10.4

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: more detail

[Daniel Pocock]

On 30/08/13 05:11, Rogério Brito wrote:
 Hi there.
 
 On Aug 27 2013, Daniel Pocock wrote:
 Easily fixed though
 (...)
 finally, it works with this command line:

 java -classpath
 /usr/share/java/closure-compiler.jar:/usr/share/java/args4j.jar:/usr/share/java/guava.jar:/usr/share/java/json.jar
 com.google.javascript.jscomp.CommandLineRunner

 and these dependencies:

 libargs4-java libguava-java libandroid-json-org-java
   ^
   This should be libargs4j-java (note the missing j after the number 4).
 

That was just a typo - libargs4j-java is what I used


 Just tried Daniel's recipe of installing the dependencies and it fixes the
 unusability of version 20130227+dfsg1-2 (the problem was reported with
 version 20130227+dfsg1-1 and it is still present).
 
 Can we have an update of this package? BTW, shouldn't the package provide a
 wrapper like, say, /usr/bin/closure-compiler, instead of having the user
 type such a long line?  Or, at least, a README.Debian telling the user how
 to run the compiler?

It should be a runnable JAR, that means declaring the dependencies and
main class in the manifest

Then you can just run the JAR, e.g.

ln -s /usr/share/java/closure-compiler.jar /usr/bin/closure-compiler

and then just run closure-compiler

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: more detail

[Daniel Pocock]

severity -1 grave

Not usable currently

Easily fixed though

It needs the main class declared in the manifest, from upstream, that
appears to be com.google.javascript.jscomp.CommandLineRunner


I tried running the JAR from this package manually:

java -classpath /usr/share/java/closure-compiler.jar
com.google.javascript.jscomp.CommandLineRunner

and it fails with

Exception in thread main java.lang.NoClassDefFoundError:
org/kohsuke/args4j/CmdLineException
Caused by: java.lang.ClassNotFoundException:
org.kohsuke.args4j.CmdLineException
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class:
com.google.javascript.jscomp.CommandLineRunner.  Program will exit.

Comparing the JAR with upstream's JAR, it looks like org/kohsuke has
been stripped out.  If that is in another package then it needs to be a
dependency and it also needs to be listed in the manifest of
closure-compiler.jar so that it will be found automatically

I manually installed libargs4-java and I then get

Exception in thread main java.lang.NoClassDefFoundError:
com/google/common/io/LimitInputStream
Caused by: java.lang.ClassNotFoundException:
com.google.common.io.LimitInputStream
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class:
com.google.javascript.jscomp.CommandLineRunner.  Program will exit.



and adding libguava-java I then get another exception about
org/json/JSONException





finally, it works with this command line:

java -classpath
/usr/share/java/closure-compiler.jar:/usr/share/java/args4j.jar:/usr/share/java/guava.jar:/usr/share/java/json.jar
com.google.javascript.jscomp.CommandLineRunner

and these dependencies:

libargs4-java libguava-java libandroid-json-org-java

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#719094: generates broken Class-Path in MANIFEST.MF

[Daniel Pocock]

Package: javahelper
Version: 0.43
Severity: important

I've tried listing my classpath JARs in both debian/manifest and in
debian/rules (export CLASSPATH)

Either way, the generated MANIFEST.MF is broken, because of the line
wrapping issue, e.g. I have


Class-Path: /usr/share/java/jar1.jar /usr/share/java/jar2.jar /usr/shar
 e/java/jar3.jar


Notice how it is automatically wrapped at approximately 70 characters? 
jh_manifest needs to generate an indented line for each JAR, e.g.

Class-Path: /usr/share/java/jar1.jar
 /usr/share/java/jar2.jar
 /usr/share/java/jar3.jar

As a work-around, I was able to insert spaces in the debian/manifest
file to make it wrap where I want it to, making it one very long line
with lots of spaces between each classpath entry

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#719094: generates broken Class-Path in MANIFEST.MF

[Daniel Pocock]

On 08/08/13 15:08, Emmanuel Bourg wrote:
 Manifest files support wrapped values, see:

 http://docs.oracle.com/javase/1.3/docs/guide/jar/jar.html#Notes%20on%20Manifest%20and%20Signature%20Files

 No line may be longer than 72 bytes (not characters), in its
 UTF8-encoded form. If a value would make the initial line longer than
 this, it should be continued on extra lines (each starting with a single
 SPACE).



I tried doing that in debian/manifest, but it still didn't work, they
were just joined together again

Can you give an example of how debian/manifest should be written?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#719094: generates broken Class-Path in MANIFEST.MF

[Daniel Pocock]

On 08/08/13 15:47, Niels Thykier wrote:
 On 2013-08-08 15:15, Daniel Pocock wrote:
 On 08/08/13 15:08, Emmanuel Bourg wrote:
 Manifest files support wrapped values, see:

 http://docs.oracle.com/javase/1.3/docs/guide/jar/jar.html#Notes%20on%20Manifest%20and%20Signature%20Files

 No line may be longer than 72 bytes (not characters), in its
 UTF8-encoded form. If a value would make the initial line longer than
 this, it should be continued on extra lines (each starting with a single
 SPACE).


 I tried doing that in debian/manifest, but it still didn't work, they
 were just joined together again

 Can you give an example of how debian/manifest should be written?

 [...]
 jh_manifest will wrap the lines unconditionally.  But that is not the
 issue.  The class path entry generated:

 
 Class-Path: /usr/share/java/jar1.jar /usr/share/java/jar2.jar /usr/shar
  e/java/jar3.jar
 

 is perfectly legal and to my knowledge correct (which I believe was the
 point Emmanuel was trying to make).  The above will unwrap to (the eqv. of):

 Class-Path: /usr/share/java/jar1.jar /usr/share/java/jar2.jar
  /usr/share/java/jar3.jar

Just to clarify: you are suggesting that I should manually break the
lines in debian/manifest at 72 characters and then the JVM will
concatenate them back together again at runtime?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#719094: generates broken Class-Path in MANIFEST.MF

[Daniel Pocock]

On 08/08/13 15:59, Niels Thykier wrote:
 On 2013-08-08 15:49, Daniel Pocock wrote:
 [...]

 Just to clarify: you are suggesting that I should manually break the
 lines in debian/manifest at 72 characters
 No, jh_manifest will do that for you - whether you like it or not.

 and then the JVM will concatenate them back together again at runtime?


 Yes, just like a RFC822 parser will concatenate

 
 Field: a...b
  c
 

 into a...bc.


I found that the generated Class-Path line would not work. 
ClassNotFound exceptions

After I do the hack (inserting spaces) the JAR works

It's a new package - when I upload, I'll send you the VCS link and you
can tell me if I'm doing something stupid or if it is really a bug.

Regards,

Daniel

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#719094: generates broken Class-Path in MANIFEST.MF

[Daniel Pocock]

On 08/08/13 16:43, Emmanuel Bourg wrote:
 If you just want to set the classpath I suggest using jh_classpath
 instead. The debian/package.classpath file contains one line per jar and
 you don't have to care about the length of the lines:

 usr/share/java/foo.jar jar1.jar jar2.jar jar3.jar


Here is the package:
   http://git.debian.org/?p=collab-maint/avis.git;a=summary

It is currently in the NEW queue

Could you have a look and tell me if I've used javahelper correctly or
even try to build it the way you propose?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.