Re: Fwd: FOSDEM 19 Debian Java talk

[Markus Koschany]

Hi Robert,

Am 12.02.19 um 20:09 schrieb Robert Scholte:
[...]
> Hi Markus,
> 
> first of all thanks for the insights, it is important for us to know how
> Maven is used and in which way we can improve that way-of-work. Hervé is
> already working hard on the reproducible builds specs with your team in
> order to find out how we can improve our maven-plugins to get
> reproducible artifacts.
> 
> Maven itself is not 100% reproducible. We've learned that some Linux
> vendors rebuild Maven and the presentation confirmed that Debian is one
> of those vendors. What we've seen in the past is that sometimes people
> are having issues with Maven and after a while we discovered that they
> were not using the official Apache Maven distribution[1]. For us it is
> quite easy to say: sorry, not our official distribution, please contact
> your Linux distributor.
> In such case we have 3 losers: the user, the Apache Maven project and
> the Linux Distributor. If only the official Maven distribution was used,
> then we would have had 3 winners.
> 
> When you decide to rebuild Maven, you're also taking all related
> responsibilities.

We hear this a lot and it seems to be more common in the Java community.
From Debian's point of view (other distributions like Fedora share the
same view) it is essential being able to rebuild software from source.
The prerequisite is the availability of source code of course. Most of
us find it even strange when upstream developers recommend to use their
prebuilt versions. Do they have something to hide? Why can't they just
make building from source easy and trivial?

We believe that every user should have the ability to modify software
but this is only possible if she can build it from source. We go to
great lengths to ensure that all software complies with Debian's free
software guidelines. For the enduser the language and build tools of a
certain piece of software almost become meaningless. They just type "apt
source maven", change into the maven directory and rebuild the software
with another one-liner.

In case of Maven I don't see where our release differs fundamentally
from your binary releases. As I said there is only one reproducibility
patch left that doesn't change the functionality at all. So what we do
is grab your sources from https://github.com/apache/maven/releases or
maven.apache.org. In our opinion, without making any significant
changes, it should just behave as your binary release when we build it
from source. Otherwise there is source code missing or different.

> I'm also wondering how you build Maven, since Maven is
> being built with Maven. That should be a challenge to also rebuild all
> plugins, etc.
> And how do you test this and confirm that it works as the official
> distribution?
> Sure, *IF* Maven is 100% reproducible then you can rely on our
> test-infra, but that's not the situation.

It is a challenge to build Maven from source. We solved the
bootstrapping problem and now we can use Debian's Maven version to build
newer versions but we have to follow a certain build order when we make
an update.

> So here are my main questions:
> - Are you making clear that you're not using the official Maven
> distribution, e.g. by adjust the info from 'mvn --version'?

This is how it looks on Debian 9 "Stretch" at the moment.

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_181, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.9.0-8-amd64", arch: "amd64", family: "unix"

It is obvious from Maven home I guess but there is no special emphasis
on Debian because when you install Maven from Debian you will never get
a prebuilt binary release, this is implicit for all software in Debian's
main distribution.

> - What is the optimum way of distributing Maven sources? For example:
> also providing compile and package scripts (instead of calling
> maven-plugins)?

The major headache for us is the initial bootstrapping of new compilers
or build tools. We often write our own Ant scripts to solve the chicken
and egg problem. For Maven this is currently solved but if I recall
correctly there are sometimes plugins that require a certain Maven
version which in turn requires a specific plugin version, a classic
dependency loop. So if there was a way to build Maven without Maven or
certain plugins that would obviously make our life easier.

[...]
>> Our biggest challenge is Gradle. If Robert wants to help us then he
>> should never rewrite parts of Maven in Kotlin or encourage developers to
>> use a specific prebuilt version of Maven and to ship a script in every
>> project that downloads it from the internet (gradle-wrapper). ;)
> 
> Interesting :) We've been discussing how we could get more contributors
> and Kotlin was one idea, but that one didn't make it.
> Even though we as Maven developers don't like the wrapper, the community
> is asking for it, so we're serio

Re: Fwd: FOSDEM 19 Debian Java talk

[Dalibor Topic]

Hi Markus,

On 12.02.2019 12:34, Markus Koschany wrote:

Regarding javadoc generation we would like to see an option that
basically reverts to pre OpenJDK8 and simply is less strict than the
current implementation. 


Unfortunately, we don't plan to go back to the pre-Java 8 Javadoc 
implementation in OpenJDK.


We do plan to remove the old doclet API in a future release, though: 
https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-February/000848.html 
, and the support for HTML4 output has been removed two weeks ago: 
https://hg.openjdk.java.net/jdk/jdk/rev/0d9dee001667 .


With respect to strictness, the doclint feature can be turned off 
generally or selectively. A talklet/demo can be seen at 
https://youtu.be/VrI6rJNO2x4?t=829


cheers,
dalibor topic
--
Oracle 
Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Green Oracle  Oracle is committed to
developing practices and products that help protect the environment

Re: Fwd: FOSDEM 19 Debian Java talk

[Michael Osipov]

Am 2019-02-12 um 20:09 schrieb Robert Scholte:

On Tue, 12 Feb 2019 12:34:56 +0100, Markus Koschany  wrote:


Hello,

Dalibor Topic (Oracle) and Robert Scholte (Apache Maven) contacted me
and were so kind to agree to make this discussion public, so that others
can chime in too. I would like to use the opportunity to answer the
initial question "what we are interested in seeing better supported from
build tools" and give some general feedback about integrating Java into
Debian.


First of all Ant and Maven are most likely the best supported build
systems at the moment. We carry only two patches for Maven, one because
we use a newer version of SLF4j [1] and the second one is to make Maven
builds reproducible. [2] It looks like [1] has been already merged
upstream but [2] has not been forwarded yet. It would be great of
course, if Maven builds would be reproducible out-of-the-box. In general
I would like to see reproducible builds everywhere.


Hi Markus,

first of all thanks for the insights, it is important for us to know how 
Maven is used and in which way we can improve that way-of-work. Hervé is 
already working hard on the reproducible builds specs with your team in 
order to find out how we can improve our maven-plugins to get 
reproducible artifacts.


Maven itself is not 100% reproducible. We've learned that some Linux 
vendors rebuild Maven and the presentation confirmed that Debian is one 
of those vendors. What we've seen in the past is that sometimes people 
are having issues with Maven and after a while we discovered that they 
were not using the official Apache Maven distribution[1]. For us it is 
quite easy to say: sorry, not our official distribution, please contact 
your Linux distributor.
In such case we have 3 losers: the user, the Apache Maven project and 
the Linux Distributor. If only the official Maven distribution was used, 
then we would have had 3 winners.


When you decide to rebuild Maven, you're also taking all related 
responsibilities. I'm also wondering how you build Maven, since Maven is 
being built with Maven. That should be a challenge to also rebuild all 
plugins, etc.
And how do you test this and confirm that it works as the official 
distribution?
Sure, *IF* Maven is 100% reproducible then you can rely on our 
test-infra, but that's not the situation.


So here are my main questions:
- Are you making clear that you're not using the official Maven 
distribution, e.g. by adjust the info from 'mvn --version'?


I expressed my proposal to Hervé that we need a new property: 
maven.vendor. Our official distribution will carry the value: ASF. 
Everyone else who modifies the content must change the value in the 
build.properties. Thus, we will quickly know that this distro has been 
modified by someone else.


Michael

AW: Fwd: FOSDEM 19 Debian Java talk

[Bernd Eckenfels]

Hello,

according to the Apache Release Policy a release is the source and while it 
allows and defines convinience binaries there is not really a Notion of 
„official binaries“ from the ASF Point of view. So Maybe the new property 
should be something like „binary Vendor“ or „packager“ (similiar what many 
package Managers have?)

I think the number of additional support Problems because of distribution 
specific packages and the number of solved Problems by distributions doing a 
good Integration Job can not be clearly tallied.

And therefore I would stay away from language like „modified“, „official“ to 
avoid those Groups to feel unwelcome (especially in the ASF spirit of open 
SOURCE).

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Michael Osipov
Gesendet: Mittwoch, 13. Februar 2019 19:36
An: Maven Developers List; Robert Scholte; Dalibor Topic; Markus Koschany
Cc: debian-java@lists.debian.org; Matthias Klose
Betreff: Re: Fwd: FOSDEM 19 Debian Java talk

Am 2019-02-12 um 20:09 schrieb Robert Scholte:
> On Tue, 12 Feb 2019 12:34:56 +0100, Markus Koschany  wrote:
> 
>> Hello,
>>
>> Dalibor Topic (Oracle) and Robert Scholte (Apache Maven) contacted me
>> and were so kind to agree to make this discussion public, so that others
>> can chime in too. I would like to use the opportunity to answer the
>> initial question "what we are interested in seeing better supported from
>> build tools" and give some general feedback about integrating Java into
>> Debian.
>>
>>
>> First of all Ant and Maven are most likely the best supported build
>> systems at the moment. We carry only two patches for Maven, one because
>> we use a newer version of SLF4j [1] and the second one is to make Maven
>> builds reproducible. [2] It looks like [1] has been already merged
>> upstream but [2] has not been forwarded yet. It would be great of
>> course, if Maven builds would be reproducible out-of-the-box. In general
>> I would like to see reproducible builds everywhere.
> 
> Hi Markus,
> 
> first of all thanks for the insights, it is important for us to know how 
> Maven is used and in which way we can improve that way-of-work. Hervé is 
> already working hard on the reproducible builds specs with your team in 
> order to find out how we can improve our maven-plugins to get 
> reproducible artifacts.
> 
> Maven itself is not 100% reproducible. We've learned that some Linux 
> vendors rebuild Maven and the presentation confirmed that Debian is one 
> of those vendors. What we've seen in the past is that sometimes people 
> are having issues with Maven and after a while we discovered that they 
> were not using the official Apache Maven distribution[1]. For us it is 
> quite easy to say: sorry, not our official distribution, please contact 
> your Linux distributor.
> In such case we have 3 losers: the user, the Apache Maven project and 
> the Linux Distributor. If only the official Maven distribution was used, 
> then we would have had 3 winners.
> 
> When you decide to rebuild Maven, you're also taking all related 
> responsibilities. I'm also wondering how you build Maven, since Maven is 
> being built with Maven. That should be a challenge to also rebuild all 
> plugins, etc.
> And how do you test this and confirm that it works as the official 
> distribution?
> Sure, *IF* Maven is 100% reproducible then you can rely on our 
> test-infra, but that's not the situation.
> 
> So here are my main questions:
> - Are you making clear that you're not using the official Maven 
> distribution, e.g. by adjust the info from 'mvn --version'?

I expressed my proposal to Hervé that we need a new property: 
maven.vendor. Our official distribution will carry the value: ASF. 
Everyone else who modifies the content must change the value in the 
build.properties. Thus, we will quickly know that this distro has been 
modified by someone else.

Michael


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Javadoc -link makes broken links if module name matches package name

[Markus Koschany]

Hi,

Am 26.01.19 um 20:07 schrieb tony mancill:
[...]
> I'm trying to peel the onion and believe that this is a problem in the
> maven-javadoc-plugin package.  I found the same issue for a project
> outside of Debian, for example [1], which refers to a JIRA ticket for that
> plugin [2].  There is a commit [3] referencing that JIRA on the master
> branch of maven-javadoc-plugin.
> 
> I would like to try cherry-picking the fix onto our current version of
> maven-javadoc-plugin to see if it resolves our issue.  Or if that gets
> too complicated, we could look into updating to a snapshot of 3.1.0 (our
> version would 3.1.0~foo), since it looks like all of these commits will
> be part of 3.1.0 [4].
> 
> I'm not sure how much time I'll have to dedicate to this over the
> weekend and so would be happy if someone fixes it before I get to it.

I have updated the maven-javadoc-plugin package to the latest Git
snapshot and pushed the changes. An update of libplexus-languages-java
was also necessary (currently in experimental) and tony already took
care of it. I also had to add a compatibility patch for Debian's version
of maven-artifact-transfer. A new upstream release just because of some
minor refactoring seemed to be not the best way forward during the freeze.

Now I would have expected that libparanamer-java (#920750) just built
fine again but it doesn't. According to README.source in
maven-javadoc-plugin maven2-core (should be src:maven?) must be updated
as well. I'm not sure what button I have to press to make this work
right now. Any ideas?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: old version of scala

[Thomas Finneid]

On 07.02.2019 15:29, Thorsten Glaser wrote:

If there’s no such path, you’d need more intermediate versions and
upload them, one after another. Into experimental would most likely
be the best, with the understanding that these are intended for
bootstrapping, not for use by users, although they could, in theory,
do that.



Hi

Could you explain how this works in more detail? What do you mean by 
intermediate versions and how to get them. Cause this could possibly be 
a solution to the problem.


Regards

Thomas

Re: sbt / scala and jdk 6 and 8

[Thomas Finneid]

On 12.02.2019 23:48, Markus Koschany wrote:

Personally I would like to keep OpenJDK 8 as well but you also have to
keep the following points in mind:


All these ar good reasons. The issue here is that Jdk8 -> jdk11 is a 
special case. Oracle decided to just change the entire release scheme to 
one that suits their business needs, upsetting the entire java community 
and all businesses. Suddenly we get new versions every 6 months. 1 year 
after the release of jdk 9, we are at jdk 11, and in 2 months time at 
jdk 12.


In this case, one has to consider the huge number of projects and 
businesses who invested in jdk8. Every release took many many years to 
get out the door, so suddenly changing the release speed, makes it time 
consuming for businesses to migrate their entire code base.


The entire java community, projects and businesses knows jdk-8 has EOL 
in december 2020, so they are running to figure out a migration plan. 
Most businesses are now running two jdk versions, 8 and 11 (nobody cares 
about 9 and 10), until they get rid of 8. And they wont care about jdk 
12 or 13. Maybe Jdk 15, but that depends.


For jdk 8, a notice at installation, that jdk 8 is available only for 
backwards compatability until EOL, and it will not be supported after 
Java 8 EOL, should be enough. Only applications that actually need jdk8, 
will have it as its dependency. Every other apps, should buld against 
default-jdk. Everybody knows they would be using jdk8 with risk after 
EOL anyway.


An additional issue, at least for Debian, is that now any non-LTS 
releases only get security updates for 6 months. And, only LTS versions 
of java will be used in production by projects and businesses. LTS 
versions and Debian version dont coincide in their 5 year release plans 
either. So every release of Debian will have either a random jdk, which 
is only supported for 6 months or an LTS version that is supported for 
the next 3,5 years.


No matter how one looks at it, Debian needs to make a strategy change 
regarding OpenJdk releases and versions supported.


Regards

Thomas