Dear Java Team,

Please consider updating closure-compiler to a newer upstream version.  The
most recent tagged release is v20131118.

Thank you,
tony (filing a reminder bug)

Gentle ping? The latest upstream release is 20151015 as far as I can
see. There have been some changes so the present Debianisation cannot
simply be forwarded. My skills in Java packaging are however somewhat
limited.

    Christoph, on behalf of another person who is interested in using closure-compiler

Hi Christoph,

Thank you for the reminder on this.

I took a look at the 20151015 release and so far it appears that we only
need to package one additional reverse dependency - "truth"
(http://google.github.io/truth).  We may also take advantage of this
opportunity to switch from ant to the maven-based build system.  I'll
try to get the new r-dep packaged this weekend and then see how quickly
we can get the rest of it ready to go.

Cheers,
tony

Hi Tony,

[snip]

I was wondering if there has been any progress? I myself am also looking into packaging closure-library, which would also profit from a newer closure-compiler (and in fact calls new style parameters in its build script).

Cheers
Sascha

On Wed, Dec 28, 2016 at 10:33:06PM +0100, Sascha Steinbiss wrote:

Hello Sascha and other interested parties:

I have been looking into packaging 20161201, but haven't made any
significant progress on it.  Here are some notes regarding what
I have looked into so far:

1) It's not going to be feasible to get an updated libtruth-java into
stretch before the freeze, as truth depends upon another library
com.google.errorprone:error_prone_annotations

2) According to the POM, the dependency on libtruth-java is only needed
for testCompile, so we could just skip the tests, but I found a few
references to packages in com.google.common.truth sprinkled around the
src/ tree as well, so we'll need to patch those out.

3) The build system is now maven-based, which should be a step forward,
but mh_make doesn't get very far with it, and I haven't had enough
cycles to look into sequencing the individual poms.

4) There is a note in the upstream README.md:

   Running `mvn -DskipTests -pl externs/pom.xml,pom-main.xml,pom-main-shaded.xml`
   will skip building the GWT version of the compiler. This can speed
   up the build process significantly.

I'm unsure as to what the differences between the GWT-version and the
non-GWT-version would be with respect to the Debian package.

So, in summary, I haven't been much progress on an new version (despite
a number of failed starts).  I'm happy to work together with someone,
or to help with sponsoring and/or reviewing.

Cheers,
tony

On Thu, 29 Dec 2016 08:36:00 -0800 tony mancill <tmancill@debian.org>
wrote:> So, in summary, I haven't been much progress on an new version
(despite

I'm packaging reactjs and it needs google-closure-compiler-js. But I was
wondering if I could use closure-compiler java instead. But got many
test failures (10 passing, 20 failing) with node-google-closure-compile
20180101.0.0 because closure-compiler.jar is very old.

Being more familiar with nodejs packaging, I prefer to go back to
google-closure-compiler-js. But if there is a newer closure-compiler,
it'd make my work a lot easier.

On Sat, 20 Jan 2018 20:38:02 +0530 Pirate Praveen <praveen@debian.org>
wrote:> Being more familiar with nodejs packaging, I prefer to go back to

Hi Tony,

Digging deeper, I found out even the javascript version is built using
java sources (using gwt). So I have to update the java sources even for
javascript version.  Hope you are still interested in updating
closure-compiler and we can collaborate.

Hi Tony and Thomas,

This package came to my attention via #975505, where it was noted that
MathJax2 has had to disable functionality because of too ancient of a
closure-compiler, and at this time it appears that MathJax3 will have to
do the same.

Closure-compiler is a candidate for salvaging:

https://wiki.debian.org/PackageSalvaging
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging

The ideal resolution would be for one of the listed Uploaders to resume
maintenance of the package, but orphaning is of course also an option :-)

Pirate Praveen <praveen@debian.org> writes:

I noticed that you were able to complete #886411 ITP: node-react using
some other method (perhaps google-closure-compiler-js, or perhaps
disabling functionality?), so I've unset the block relation.  It seemed
worthwhile keep you in the CC list in case you wanted to create a
"switch to closure-compiler" bug, and block it with this one (#733586).


Kind regards,
Nicholas

Hello Nicholas,

The closure-compiler package is officially a team-maintained package by
the Java Team, so you or anyone else who is interested in joining Java
Team and maintaining the package is welcome to do so.  That is, please
feel free to add yourself to Uploaders.

That said, it's more of a JavaScript tool than a Java package, and so
the package could also be moved to another team if that's preferable.

I will gladly help with either of those options, or with reviewing and
sponsoring an upload of a newer version if one is made available.

Finally, I have never been a user of closure-compiler - my packaging
work on it has been under the Java Team umbrella - and I have
(obviously) been unable to devote sufficient time to it.  I will remove
myself from Uploaders to avoid any future confusion.

Cheers,
tony

Hello,

sorry, I was under the wrong impression that closure-compiler would be abandoned upstream and that it would eventually die of age and be removed.
I packaged closure-compiler as a dependency of the code review system Gerrit which however couldn't be packaged at the time due to GWT.

Whoever does another upload to closure-compiler please also remove me from uploaders.

Thank you!

Hello Thomas and Tony,

CCing Javascript team (JS Team, please see below for why), and fixing
threading, since top-posting is confusing.  Reply follows inline:

Thomas Koch <thomas@koch.ro> writes:
much appreciated :-)  While closure-compiler is currently under the Java
Team umbrella, removing both human uploaders will create a Policy §3.3
violation (the need for a human Maintainer/Uploader is unfulfilled):

https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer

Closure-compiler must be formally orphaned for this reason.

There is additionally a practical reason to orphan it: The maintainers
of all packages that depend on it will receive a Package Tracker
notification that it is unmaintained; This includes transitive
dependencies via MathJax2 (sigil, pandoc, etc).  Furthermore, it will
show up on the list of packages that prospective DMs and DDs investigate
as part of their process.  If I remember correctly the orphan bug will
also appear for developers who have the "how-can-i-help" package
installed.

Thus, please file the wnpp Orphan bug, because it's clearly the correct
avenue forward, and because it maximises the chance of finding a new
maintainer.

Cheers!
Nicholas