Re: Notes from the DebConf 17 Java BOF

[Frederic Bonnard]

Hi Tony,

> I'm still making my way through the packaging, but it looks fine so far.
> It does feel very odd to upload source packages with those large
> bootstrap dependency tarballs when some of the dependencies are already
> in the archive.

That's right.
Honestly I did all that some time ago and I don't remember of a specific
issue that would have prevented me from doing so (I still think I tried
this at some point..)
So yes we may have some redondant jars.
Actually sbt as it is delivered, consist in a single jar.
When you launch it, it fetches all its runtime dependencies online ; if
it can't, it fails.
So I consider this full set of jars as the working sbt, runnable and
usable to go further, the one that upstream may have delivered for
offline use if they had decided to do so.
That ensured me less trouble by relying on a well "tested" upstream sbt,
before going further. That also helps focusing on the missing runtime
dependencies, leaving the build dependencies for later because
bootstraping sbt in Debian will first need to have a Debian sbt running,
and thus with available runtime dependencies in Debian.

> Can you remind me of what the plan is once everything
> hits experimental/unstable?  I vaguely recall it being discussed, so a
> pointer is fine.  I just want to understand what comes next.

What we will have once we have that last package in experimental is a
runnable sbt. Which means, that doesn't fail and exit if it doesn't have
access to the online jars repositories. That's the bare minimum set of
jars I needed to have sbt start without error using the local Debian jar
repository only.

Having it start and display help without failing on some runtime
dependency missing is not enough then to make some package needing sbt
as "make" tool to build properly.
Especially sbt itself and those other core dependencies I packaged for
experimental.

So I see 2 tasks next :
- continue to package the runtime dependencies for sbt to be able to
  build packages of people interested by sbt as build tool : we have
  to keep in mind that we're working on sbt for others to package their
  software (especially my sponsor Andreas :) )
- fill the gap of the sbt build dependencies, that is get rid of those
  embedded sbt tarballs by providing all the packages for the latter, in
  Debian.
  Thus we will need to package all the missing build dependencies needed
  to build each of the core packages (and recursively..) that belong to
  that initial set (all the binary .jars embedded and listed in
  d/copyright etc)
  A big tree of dependencies will be revealed step by step and those
  will need to be packaged to be able to build sbt with sbt in Debian.
  I didn't check that deeply, but I think there are many
  packages to create given all the .jars I had to go through in
  d/copyright and that were dragged as runtime dependencies of the
  embedded sbt binary for the sbt core packages (and think of this
  recursively).

One way of doing in both tasks, could be to continue to use embedded
and ugly sbt binary tarballs for some time :
- to ease the work (expecially concerning the recursive aspect : I have
  no estimate of the depth)
- while still offering sbt usability to packagers (else I fear we'll
  need to wait too long for packaging completion of the full
  runtime/build dependency tree of sbt and its components, to deliver
  something complete : sbt and other packages that can build sbt and
  those other packages)

I hope you have a better idea of what's next (sorry, that's not easy
for me to explain)

F.

> 
> Thank you,
> tony


pgp7azyfLnGUw.pgp
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[tony mancill]

On Thu, Aug 17, 2017 at 10:10:01AM +0200, Frederic Bonnard wrote:
> On Wed, 16 Aug 2017 14:41:44 -0700, tony mancill  wrote:
> > On Wed, Aug 16, 2017 at 10:01:26AM +0200, Frederic Bonnard wrote:
> > > 
> > > and waiting for scala-tools-sbinary.
> > 
> > I can have a look at scala-tools-sbinary.  I have gone ahead and
> > uploaded sbt to unstable [1] because I wanted to incorporate Chris
> > Lamb's reproducible builds patch.
> 
> wow, thanks a lot Tony for both actions (I think I missed that
> reproducibility bug notification at some point :-° )
> 
> Well, I actually didn't know if somebody was having a look at
> scala-tools-sbinary at the moment or not, given that d/copyright may be
> huge and can take some time.
> 
> If you have spare time for this, I'd be glad you help, but nothing
> urgent on my side.

Hello Frederic,

I'm still making my way through the packaging, but it looks fine so far.
It does feel very odd to upload source packages with those large
bootstrap dependency tarballs when some of the dependencies are already
in the archive. Can you remind me of what the plan is once everything
hits experimental/unstable?  I vaguely recall it being discussed, so a
pointer is fine.  I just want to understand what comes next.

Thank you,
tony


signature.asc
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[Frederic Bonnard]

I forgot a last missing bit for that sbt stack :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853733

F.


On Wed, 16 Aug 2017 10:01:26 +0200, Frederic Bonnard 
 wrote:
> Hi Emmanuel/all,
> 
> On Sat, 12 Aug 2017 00:06:41 +0200, Emmanuel Bourg  wrote:
> > Thank you for the summary Tom. How many people attended the BOF?
> > 
> > On 08/09/2017 02:50 AM, Tom Marble wrote:
> > 
> > > 1. Making openjdk-9 the default for buster
> > >- Yes we should try to do this.
> > >- We will gain some fixes for reproducible builds
> > 
> > Do we know what has improved on the reproducibility side with OpenJDK 9?
> > 
> > 
> > >- Chris West has done some excellent work trying to rebuild the
> > >  archive with openjdk-9
> > >- FYI: the next Ubuntu LTS in April would like to ship with openjdk-9
> > 
> > As the default JRE? That would be quite optimistic.
> > 
> > 
> > > 2. Targets without HotSpot
> > >- We could maintain this with gcj (despite gcj being dropped from
> > >  upstream)
> > 
> > The number of packages runnable with GCJ is shrinking rapidly (Java 5
> > only). There is no point keeping it as an alternative for HotSpot.
> > 
> > 
> > > 3. Scala
> > >- We discussed the value of packaging sbt
> > >- Need to fix a reproducible build problem to bring it from
> > >  experimental to stable
> > 
> > What are the issues blocking SBT currently?
> 
> I've sent a list of sbt related packages (for experimental) on mentors
> some time ago that Andreas kindly sponsored them. All but one were accepted
> by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
> it's being examined :)
> https://mentors.debian.net/package/scala-tools-sbinary
> 
> So at the moment, we have in experimental :
> https://tracker.debian.org/pkg/jawn
> https://tracker.debian.org/pkg/json4s
> https://tracker.debian.org/pkg/sbt
> https://tracker.debian.org/pkg/sbt-ivy
> https://tracker.debian.org/pkg/sbt-launcher-interface
> https://tracker.debian.org/pkg/sbt-serialization
> https://tracker.debian.org/pkg/sbt-template-resolver
> https://tracker.debian.org/pkg/sbt-test-interface
> https://tracker.debian.org/pkg/scala-pickling
> https://tracker.debian.org/pkg/scopt
> 
> and waiting for scala-tools-sbinary.
> 
> Some links :
> ITP: simple-build-tool : 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910
> RFS: scala-pickling : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855941
> https://lists.debian.org/debian-java/2017/04/msg4.html
> 
> F.
> 
> > 
> > 
> > > 4. Clojure
> > >- Currently does not have JDK 9 support
> > >- The Clojure Team will look into this with upstream
> > 
> > Did you discuss if we keep the Java and Clojure teams/packages under the
> > same umbrella?
> > 
> > 
> > > 5. javadoc
> > >- Our packages that are standards 4.0.1 compliant should support
> > > "nodoc"
> > 
> > maven-debian-helper will support the "nodoc" option in the next update,
> > but some help from debhelper is still required to make it work with no
> > other modification to the existing packages (see #871822).
> > 
> > 
> > >- Some users appreciate offline access to docs
> > 
> > I would add that we spent a non negligible amount of time maintaining
> > these rarely used packages and dealing with their reproducibility
> > issues. Besides the JDK and some very popular libraries I think we
> > should drop them.
> > 
> > 
> > > 6. Autopkgtest
> > >- We should use this more
> > >- Can include built-in tests
> > >- We can (or autopkgtest already does) use 'ratt' to test reverse deps
> > 
> > My understanding of autopkgtest was that it wasn't meant to execute the
> > test suite already run at build time (i.e. mvn test). Maybe it could be
> > used to run the Maven integration tests instead?
> > 
> > Emmanuel Bourg
> > 


pgpBIbN_amn1o.pgp
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[Frederic Bonnard]

Hi Tony,

On Wed, 16 Aug 2017 14:41:44 -0700, tony mancill  wrote:
> Hi Frederic,
> 
> On Wed, Aug 16, 2017 at 10:01:26AM +0200, Frederic Bonnard wrote:
> > Hi Emmanuel/all,
> > > What are the issues blocking SBT currently?
> > 
> > I've sent a list of sbt related packages (for experimental) on mentors
> > some time ago that Andreas kindly sponsored them. All but one were accepted
> > by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
> > it's being examined :)
> > https://mentors.debian.net/package/scala-tools-sbinary
> > 
> > So at the moment, we have in experimental :
> > https://tracker.debian.org/pkg/jawn
> > https://tracker.debian.org/pkg/json4s
> > https://tracker.debian.org/pkg/sbt
> > https://tracker.debian.org/pkg/sbt-ivy
> > https://tracker.debian.org/pkg/sbt-launcher-interface
> > https://tracker.debian.org/pkg/sbt-serialization
> > https://tracker.debian.org/pkg/sbt-template-resolver
> > https://tracker.debian.org/pkg/sbt-test-interface
> > https://tracker.debian.org/pkg/scala-pickling
> > https://tracker.debian.org/pkg/scopt
> > 
> > and waiting for scala-tools-sbinary.
> 
> I can have a look at scala-tools-sbinary.  I have gone ahead and
> uploaded sbt to unstable [1] because I wanted to incorporate Chris
> Lamb's reproducible builds patch.

wow, thanks a lot Tony for both actions (I think I missed that
reproducibility bug notification at some point :-° )

Well, I actually didn't know if somebody was having a look at
scala-tools-sbinary at the moment or not, given that d/copyright may be
huge and can take some time.

If you have spare time for this, I'd be glad you help, but nothing
urgent on my side.

F.

> Thank you,
> tony
> 
> [1] https://tracker.debian.org/news/862551


pgpTTRjHSg5sD.pgp
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[Frederic Bonnard]

> > I've sent a list of sbt related packages (for experimental) on mentors
> > some time ago that Andreas kindly sponsored them. All but one were accepted
> > by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
> > it's being examined :)
> > https://mentors.debian.net/package/scala-tools-sbinary
> 
> Thank you for the update! If you need to upload more packages in the
> future I suggest cross-posting your RFS on this list, your packages are
> more likely to be picked up by the developers here.

eh, that's a good idea, all the more that some packages may follow as
the above is almost "preliminary" work to have a sbt core which is
insufficient in most real life use, because many other sbt plugins/scala
libraries are needed.
As far as I remember, once we have the above packages in experimental,
I'll help Andreas packaging some project, he's interested in, that uses sbt.
This way we (all people willing to help) should be able to see what's
next (failing/missing...).

F.


pgpRAkc0YWqtf.pgp
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[tony mancill]

Hi Frederic,

On Wed, Aug 16, 2017 at 10:01:26AM +0200, Frederic Bonnard wrote:
> Hi Emmanuel/all,
> > What are the issues blocking SBT currently?
> 
> I've sent a list of sbt related packages (for experimental) on mentors
> some time ago that Andreas kindly sponsored them. All but one were accepted
> by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
> it's being examined :)
> https://mentors.debian.net/package/scala-tools-sbinary
> 
> So at the moment, we have in experimental :
> https://tracker.debian.org/pkg/jawn
> https://tracker.debian.org/pkg/json4s
> https://tracker.debian.org/pkg/sbt
> https://tracker.debian.org/pkg/sbt-ivy
> https://tracker.debian.org/pkg/sbt-launcher-interface
> https://tracker.debian.org/pkg/sbt-serialization
> https://tracker.debian.org/pkg/sbt-template-resolver
> https://tracker.debian.org/pkg/sbt-test-interface
> https://tracker.debian.org/pkg/scala-pickling
> https://tracker.debian.org/pkg/scopt
> 
> and waiting for scala-tools-sbinary.

I can have a look at scala-tools-sbinary.  I have gone ahead and
uploaded sbt to unstable [1] because I wanted to incorporate Chris
Lamb's reproducible builds patch.

Thank you,
tony

[1] https://tracker.debian.org/news/862551


signature.asc
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[Emmanuel Bourg]

On 08/16/2017 10:01 AM, Frederic Bonnard wrote:

> I've sent a list of sbt related packages (for experimental) on mentors
> some time ago that Andreas kindly sponsored them. All but one were accepted
> by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
> it's being examined :)
> https://mentors.debian.net/package/scala-tools-sbinary

Thank you for the update! If you need to upload more packages in the
future I suggest cross-posting your RFS on this list, your packages are
more likely to be picked up by the developers here.

Emmanuel Bourg

Re: Notes from the DebConf 17 Java BOF

[Frederic Bonnard]

Hi Emmanuel/all,

On Sat, 12 Aug 2017 00:06:41 +0200, Emmanuel Bourg  wrote:
> Thank you for the summary Tom. How many people attended the BOF?
> 
> On 08/09/2017 02:50 AM, Tom Marble wrote:
> 
> > 1. Making openjdk-9 the default for buster
> >- Yes we should try to do this.
> >- We will gain some fixes for reproducible builds
> 
> Do we know what has improved on the reproducibility side with OpenJDK 9?
> 
> 
> >- Chris West has done some excellent work trying to rebuild the
> >  archive with openjdk-9
> >- FYI: the next Ubuntu LTS in April would like to ship with openjdk-9
> 
> As the default JRE? That would be quite optimistic.
> 
> 
> > 2. Targets without HotSpot
> >- We could maintain this with gcj (despite gcj being dropped from
> >  upstream)
> 
> The number of packages runnable with GCJ is shrinking rapidly (Java 5
> only). There is no point keeping it as an alternative for HotSpot.
> 
> 
> > 3. Scala
> >- We discussed the value of packaging sbt
> >- Need to fix a reproducible build problem to bring it from
> >  experimental to stable
> 
> What are the issues blocking SBT currently?

I've sent a list of sbt related packages (for experimental) on mentors
some time ago that Andreas kindly sponsored them. All but one were accepted
by ftpmasters ; there's only scala-tools-sbinary remaining : I guess
it's being examined :)
https://mentors.debian.net/package/scala-tools-sbinary

So at the moment, we have in experimental :
https://tracker.debian.org/pkg/jawn
https://tracker.debian.org/pkg/json4s
https://tracker.debian.org/pkg/sbt
https://tracker.debian.org/pkg/sbt-ivy
https://tracker.debian.org/pkg/sbt-launcher-interface
https://tracker.debian.org/pkg/sbt-serialization
https://tracker.debian.org/pkg/sbt-template-resolver
https://tracker.debian.org/pkg/sbt-test-interface
https://tracker.debian.org/pkg/scala-pickling
https://tracker.debian.org/pkg/scopt

and waiting for scala-tools-sbinary.

Some links :
ITP: simple-build-tool : 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910
RFS: scala-pickling : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855941
https://lists.debian.org/debian-java/2017/04/msg4.html

F.

> 
> 
> > 4. Clojure
> >- Currently does not have JDK 9 support
> >- The Clojure Team will look into this with upstream
> 
> Did you discuss if we keep the Java and Clojure teams/packages under the
> same umbrella?
> 
> 
> > 5. javadoc
> >- Our packages that are standards 4.0.1 compliant should support
> > "nodoc"
> 
> maven-debian-helper will support the "nodoc" option in the next update,
> but some help from debhelper is still required to make it work with no
> other modification to the existing packages (see #871822).
> 
> 
> >- Some users appreciate offline access to docs
> 
> I would add that we spent a non negligible amount of time maintaining
> these rarely used packages and dealing with their reproducibility
> issues. Besides the JDK and some very popular libraries I think we
> should drop them.
> 
> 
> > 6. Autopkgtest
> >- We should use this more
> >- Can include built-in tests
> >- We can (or autopkgtest already does) use 'ratt' to test reverse deps
> 
> My understanding of autopkgtest was that it wasn't meant to execute the
> test suite already run at build time (i.e. mvn test). Maybe it could be
> used to run the Maven integration tests instead?
> 
> Emmanuel Bourg
> 


pgp_LqEBLaVS1.pgp
Description: PGP signature

Re: Notes from the DebConf 17 Java BOF

[Markus Koschany]

Am 12.08.2017 um 00:06 schrieb Emmanuel Bourg:
> Thank you for the summary Tom. How many people attended the BOF?
> 
> On 08/09/2017 02:50 AM, Tom Marble wrote:
> 
>> 1. Making openjdk-9 the default for buster
>>- Yes we should try to do this.
>>- We will gain some fixes for reproducible builds
> 
> Do we know what has improved on the reproducibility side with OpenJDK 9?

I mentioned that you were the one who forwarded reproducibility patches
upstream. So beside from that I'm not sure.

> 
> 
>>- Chris West has done some excellent work trying to rebuild the
>>  archive with openjdk-9
>>- FYI: the next Ubuntu LTS in April would like to ship with openjdk-9
> 
> As the default JRE? That would be quite optimistic.

If I recall correctly doku intends to switch the default JRE to Java 9
for Ubuntu 18.04 but OpenJDK 8 will still be available to build packages
from source. This is like something we have done for Wheezy in the past.
We support the runtime environment but if something has to be rebuilt
from source an older version of the JDK has to be used.

>> 4. Clojure
>>- Currently does not have JDK 9 support
>>- The Clojure Team will look into this with upstream
> 
> Did you discuss if we keep the Java and Clojure teams/packages under the
> same umbrella?

We discussed this matter during the Clojure BoF. I said we would prefer
(meaning we would be happy about it) that the Clojure team maintained
their packages under the Java team umbrella. We already have all the
infrastructure in place like mailing lists and Git repositories. However
the Clojure team prefers to use a separate bug mailing list just to
avoid all the high amount of traffic we receive every day.

I suggested that both teams should grant access to each others
repositories which would simplify collaboration and it appeared to me
that everyone agreed to this proposal.

>> 5. javadoc
>>- Our packages that are standards 4.0.1 compliant should support
>> "nodoc"
> 
> maven-debian-helper will support the "nodoc" option in the next update,
> but some help from debhelper is still required to make it work with no
> other modification to the existing packages (see #871822).
> 
> 
>>- Some users appreciate offline access to docs
> 
> I would add that we spent a non negligible amount of time maintaining
> these rarely used packages and dealing with their reproducibility
> issues. Besides the JDK and some very popular libraries I think we
> should drop them.

I agree that most of the reproducibility issues are related to javadoc
packages. However in my opinion this is something which should be fixed
upstream. As you said we should provide documentation for the most
popular Java packages and the JDK but simple Java packages don't really
need it. I'm more in favor to apply this rule for future packages but I
don't think we should drop -doc packages for older packages as long as
they don't become a real burden.

> 6. Autopkgtest
>>- We should use this more
>>- Can include built-in tests
>>- We can (or autopkgtest already does) use 'ratt' to test reverse deps
> 
> My understanding of autopkgtest was that it wasn't meant to execute the
> test suite already run at build time (i.e. mvn test). Maybe it could be
> used to run the Maven integration tests instead?

I'm not sure about this. I believe it would be a good start to implement
autopkgtest for our most important packages first. Something like
checking whether r-deps break or not would be an improvement. On the
other hand I am quite impressed by the current state of bug reports from
the reproducibility team, so maybe we could focus on something else first.

Markus




signature.asc
Description: OpenPGP digital signature

Re: Notes from the DebConf 17 Java BOF

[Matthias Klose]

On 11.08.2017 20:49, Carnë Draug wrote:
> On 11 August 2017 at 23:06, Emmanuel Bourg  wrote:
>> [...]
>> On 08/09/2017 02:50 AM, Tom Marble wrote:
>>> [...]
>>> 6. Autopkgtest
>>>- We should use this more
>>>- Can include built-in tests
>>>- We can (or autopkgtest already does) use 'ratt' to test reverse deps
>>
>> My understanding of autopkgtest was that it wasn't meant to execute the
>> test suite already run at build time (i.e. mvn test). Maybe it could be
>> used to run the Maven integration tests instead?
>>
> 
> The perl team default autopkgtest reruns the test suite with the
> installed package.  The only difference is that it removes all the
> non-test units from the build tree to ensure that it uses the
> installed library.

it very much depends on the quality of the testsuite.  I'm trying to run the
testsuite for the pythonx.y packages with the installed package, however this is
some kind of fight with updating the testsuite itself to be run not in the build
tree.

> This could pick up packaging mistakes, but also picks up regressions
> caused by dependencies since the tests would be rerun when anything in
> the dependency chain is updated.

fyi, Ubuntu is doing that for migrations from the proposed to the release pocket
(Debian: unstable -> testing).  However it can be a pain ...
http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html

Matthias

Re: Notes from the DebConf 17 Java BOF

[Tom Marble]

Emmanuel Bourg  writes:
> Thank you for the summary Tom. How many people attended the BOF?

I believe we were about 8.

> On 08/09/2017 02:50 AM, Tom Marble wrote:
>> 1. Making openjdk-9 the default for buster
> Do we know what has improved on the reproducibility side with OpenJDK 9?

I don't know, but perhaps Adrian or Markus do?

>> 3. Scala
> What are the issues blocking SBT currently?

Probably just finding someone to adopt it.

>> 4. Clojure
>
> Did you discuss if we keep the Java and Clojure teams/packages under the
> same umbrella?

We didn't, but we may discuss that today at the Clojure BoF.

Regards,

--Tom

Re: Notes from the DebConf 17 Java BOF

[Felix Natter]

hello Debian-java,

thanks for the work done in the BoF!

Markus Koschany  writes:
> new ideas of packaging Java applications in general. Maybe flatpack or
> other packaging formats may be a way for us to provide some Java apps at
> all. That might be not perfect but better than nothing.

Some notes: I tried to snap/snapcraft for freeplane:
- there is a gradle plugin
- some hacking with a wrapper script is needed
- not sure if it can read config from $HOME/.config
  (maybe some more hacking is needed)
- unfortunately, the jdk _must_ be included, that's why I dropped it

Best Regards,
-- 
Felix Natter

Re: Notes from the DebConf 17 Java BOF

[Carnë Draug]

On 11 August 2017 at 23:06, Emmanuel Bourg  wrote:
> [...]
> On 08/09/2017 02:50 AM, Tom Marble wrote:
>> [...]
>> 6. Autopkgtest
>>- We should use this more
>>- Can include built-in tests
>>- We can (or autopkgtest already does) use 'ratt' to test reverse deps
>
> My understanding of autopkgtest was that it wasn't meant to execute the
> test suite already run at build time (i.e. mvn test). Maybe it could be
> used to run the Maven integration tests instead?
>

The perl team default autopkgtest reruns the test suite with the
installed package.  The only difference is that it removes all the
non-test units from the build tree to ensure that it uses the
installed library.

This could pick up packaging mistakes, but also picks up regressions
caused by dependencies since the tests would be rerun when anything in
the dependency chain is updated.

Carnë

Re: Notes from the DebConf 17 Java BOF

[Emmanuel Bourg]

Thank you for the summary Tom. How many people attended the BOF?

On 08/09/2017 02:50 AM, Tom Marble wrote:

> 1. Making openjdk-9 the default for buster
>- Yes we should try to do this.
>- We will gain some fixes for reproducible builds

Do we know what has improved on the reproducibility side with OpenJDK 9?


>- Chris West has done some excellent work trying to rebuild the
>  archive with openjdk-9
>- FYI: the next Ubuntu LTS in April would like to ship with openjdk-9

As the default JRE? That would be quite optimistic.


> 2. Targets without HotSpot
>- We could maintain this with gcj (despite gcj being dropped from
>  upstream)

The number of packages runnable with GCJ is shrinking rapidly (Java 5
only). There is no point keeping it as an alternative for HotSpot.


> 3. Scala
>- We discussed the value of packaging sbt
>- Need to fix a reproducible build problem to bring it from
>  experimental to stable

What are the issues blocking SBT currently?


> 4. Clojure
>- Currently does not have JDK 9 support
>- The Clojure Team will look into this with upstream

Did you discuss if we keep the Java and Clojure teams/packages under the
same umbrella?


> 5. javadoc
>- Our packages that are standards 4.0.1 compliant should support
> "nodoc"

maven-debian-helper will support the "nodoc" option in the next update,
but some help from debhelper is still required to make it work with no
other modification to the existing packages (see #871822).


>- Some users appreciate offline access to docs

I would add that we spent a non negligible amount of time maintaining
these rarely used packages and dealing with their reproducibility
issues. Besides the JDK and some very popular libraries I think we
should drop them.


> 6. Autopkgtest
>- We should use this more
>- Can include built-in tests
>- We can (or autopkgtest already does) use 'ratt' to test reverse deps

My understanding of autopkgtest was that it wasn't meant to execute the
test suite already run at build time (i.e. mvn test). Maybe it could be
used to run the Maven integration tests instead?

Emmanuel Bourg

Re: Notes from the DebConf 17 Java BOF

[Markus Koschany]

On 08/08/17 20:50, Tom Marble wrote:


All:

Here are my rough notes from today's BOF.. Please followup with
corrections!


Thanks Tom for taking all these notes yesterday.


5. javadoc
- Our packages that are standards 4.0.1 compliant should support
 "nodoc"
- Some users appreciate offline access to docs


I filed [1] a few minutes ago to keep track of a javadoc related issue 
in maven-debian-helper which I briefly mentioned. We also discussed to 
drop -doc packages completely because we assume a lot of Java developers 
will use the ones from Maven Central or other online resources. However 
I think a great benefit of Debian doc packages is that they are 
integrated in some cases with applications like Netbeans or Robocode and 
they "just work". Offline access to documentation might also be a valid 
use case. At the moment I add -doc only packages only to, in my opinion, 
important packages, and not for simple packages. Not sure if we should 
adjust the Java Policy in this regard.



6. Autopkgtest
- We should use this more
- Can include built-in tests
- We can (or autopkgtest already does) use 'ratt' to test reverse deps


ratt is independent from autopkgtest but one way to rebuild 
reverse-dependencies. I agree with point 1. We should use it more, at 
least for important packages. Perhaps we should find out what packages 
would benefit from autopkgtest the most and then add this to our todo 
list of things which would be nice to achieve.




7. We discussed keithp's uberjar idea
- We *could* work like the rest of the world and ship uberjars (and
  make source packages that include all source for transitive deps)
- We suspect ftp-masters may not be happy about this
- Go ahead plan is to think of even more automation to do what
  we already do now.


The issue with uberjars is that we still need to make sure they can be 
built from source and as long as this source is not in Debian 
ftp-masters will just reject such packages. I believe the general idea 
was to explore new ideas of packaging Java applications in general. 
Maybe flatpack or other packaging formats may be a way for us to provide 
some Java apps at all. That might be not perfect but better than nothing.



Currently on my todo list for Buster:

1. Improving the documentation about Java packaging. I already wrote one 
article, more will hopefully follow soon and at some point I move them 
to the Debian Wiki, so that everyone can modify and improve them. The 
whole Java wiki stuff needs a major update I guess.


2. Getting the Maven build system fixed which affects our work flow in 
general


3. OpenJDK 9: Getting Java 9 into Buster. We should just start filing 
bug reports with severity: normal now and raise the severity accordingly 
in the future. I wonder whether Chris West would be interested in this 
task because he has already done some amazing work in analyzing the key 
issues for this transition?


4. Fixing bugs as they appear and updating packages as usual. I guess I 
take a look at Eclipse again in the near future.


Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871669