How to generate mso.jar (Re: Calligra licensing and copyright bits)

Sat Jan 10 19:47:26 GMT 2015

Am Sonntag, 4. Januar 2015, 20:24:26 schrieb Jos van den Oever:
> On 01/04/2015 07:43 PM, Friedrich W. H. Kossebau wrote:
> > thanks for the quick and workloaden reaction, great :)
> 
> It was some needed work. Happy to help.
> 
> > Am Sonntag, 4. Januar 2015, 17:06:26 schrieb Jos van den Oever:
> >> On Sunday 04 January 2015 02:04:09 Friedrich W. H. Kossebau wrote:
> >>> Am Donnerstag, 23. Oktober 2014, 23:17:48 schrieb Raúl Sánchez Siles:
> >>>> Java jar files
> >>>> ==============
> >>>> jar files are binary files, as such, in Debian we need the source code
> >>>> of
> >>>> those files and generate them on package build (or removing the files
> >>>> from
> >>>> the tarball and adding dependencies on the packages that provide these
> >>>> files).
> >>>> 
> >>>> In the jar case, there are some pointers on where the jar comes from,
> >>>> but
> >>>> still bundling a generated binary is not desirable.
> >>>> 
> >>>> The fixes for that from the licensing point of view are:
> >>>> - Removing the feature
> >>>> - If the jar generates code needed at build time, adding the required
> >>>> (source) files which are generated from the jar. But not the jar. Also
> >>>> include a script or document a procedure how to get those files.
> >>>> - If the jar is required as a runtime dependency, you could either add
> >>>> a
> >>>> run time dependency on a separate package providing that jar or
> >>>> generate
> >>>> the jar at build time.
> >>>> 
> >>>> filters/libmso/generated/mso.jar
> >>>> 
> >>>>    As per README in that directory this jar generates some code that's
> >>>>    used
> >>>> 
> >>>> later.
> >>>> PROPOSAL: Describe (or script) the procedure to generate the code and
> >>>> remove the jar file.
> >>> 
> >>> The README refers to http://www.gitorious.org/msoscheme as the source of
> >>> mso.jar. Which still exists (good) and seems to be basically done by
> >>> you,
> >>> Jos, once upon a time at least. Just, there is no README there and,
> >>> worse,
> >>> also no obvious license for msoscheme.
> >>> And for recursive fun for the good Debian License checking people there
> >>> is
> >>> another binary blob inside those sources, from poi.apache.org ;)
> >> 
> >> I've added a Readme.md with license information for MSOScheme and POI to
> >> the repository of MSOscheme now.
> >> https://www.gitorious.org/msoscheme/msoscheme/
> >> 
> >> The POI code is only there for testing the generated java code. This is
> >> not
> >> used by Calligra at all.
> >> 
> >> I have updated MSOScheme: it now writes the version of MSOScheme into the
> >> generated files. The version contains the sha1. So it is always possible
> >> to
> >> find the exact version of MSOScheme to recreate the files simpleParser.h
> >> and simpleParser.cpp. This means the mso.jar does not need to be part of
> >> the Calligra source code any more.
> >> 
> >> I put up a review request to add the better documentation to calligra.
> >> 
> >>    https://git.reviewboard.kde.org/r/121837/
> >> 
> >> If the mso.jar should not be part of the Calligra repository, then it
> >> should be replaced by mso.xml.

Hm. Usually a repo contains only sources, and all tools needed for creating 
products from those sources are outside the repo. At least those shared with 
others. rng2cpp is an example where the tool is inside the Calligra repo (are 
there more like that here?).

mso.xml could be considered the real source of the generated files which are 
then used by Calligra. Just, those files (in theory) could be useful to other 
projects as well. So mso.xml is currently not really specific to Calligra (and 
thus also not a Calligra source). And the created files simpleParser.{h,cpp} 
are also not Calligra-specific.

In a perfect world there would be some package which installs simpleParser.a 
and simpleParser.h & leinputstream.h, and Calligra would require that package 
and use it during build-time.

Instead, for convenience, we have copies of the intermediate products in the 
Calligra repo.

So to make Debian happy, we possibly could add a switch to not use the 
convenience-copies in the Calligra repo, but require some msosimpleparser 
package and compile and link against that. A package which would be created 
from running msoscheme and installing those files.

Such a package might perhaps also make it more interesting to use for others, 
BTW. Would be willing to assist any needed work.

> > Have not yet looked in detail, but already impressed :)
> > 
> > One things though still bugs me: there is no released version of
> > msoscheme,
> > right? So when gitorious disappears one day (hopefully not) and you have
> > turned evil (more hopefully not), is there any other location where the
> > sources of msoscheme might be around? If there would be a release, and at
> > least Debian picks the tarball up for generating mso.jar as it seems they
> > want to instead of relying on the spyware-loaden^Wfree binary blob there
> > is in Calligra repo, chances are higher someone one day could pick up and
> > continue work on msoscheme.
> > 
> > So could you perhaps tag the version used for the current mso.jar with a
> > release version, for some more official statement? Not sure the commit id
> > is nice enough as a reference, as it binds to git as version system.
> 
> I've now tagged a new/first release: 1.0.0.
> The code can be downloaded here:
>    https://www.gitorious.org/msoscheme/msoscheme/archive/1.0.0.tar.gz
> 
> The version number that is embedded in the generated files is now:
>     1.0.0-0-g8c6d5941f11a7667b0f915b0e94ef72eb8c42938
> This is generated by git:
>     git describe --abbrev=40 --always --long --dirty --tags
> (The arguments are sorted for maximum comic effect.)

;) K, thanks, that might be really sufficient (not knowing Debian's rules, 
though :P ).

> I'm fine with mirroring this on kde. Everyone is welcome to clone the
> repo of course.

(Cloning only still has the danger of missing updates)
Given that msoscheme has not yet seen and Calligra is the only user, it might 
make sense to host it closer to Calligra. Not sure about the real benefits, 
besides only dying together with Calligra repo in case of KDE goes /dev/null. 
Any 3rd-party ever shown interest? (hm, the mso.xsd still might be interesting 
to look at for some old WIP project for the Structures tool in Okteta, you 
might remember a discussion, but unrelated to central repo location),

> In the recent past Matus Uzak and Brijesh Patel have worked on mso.xml,
> so the bus factor is > 1.

Ah, good.
/me removes bus rerouting rules based on jos' phone coordinates

Cheers
Friedrich