Bug#705565: Getting closure compiler back in testing?

[tony mancill]

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.

tony


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20131230/628323ad/attachment-0001.sig>