Re: Java 11 Compatibility Problem
To be complete on this subject, the pack200 algorithm has been implemented to be able to resolve artifacts in an Eclipse updatesite. I don’t know how nowadays artifacts are packaged on a « p2 repository », but some documentation still exists and doesn’t contain any warnings: https://wiki.eclipse.org/Equinox_p2_Repository_Optimization#Pack200_Optimization Nicolas > Le 10 oct. 2018 à 14:04, Jaikiran Pai a écrit : > > Hi Jan, > > For end users (of Ivy), the place where pack200 packaging becomes > visible is when they reference it in their dependencies as noted in our > doc[1]. So IMO, I think we should probably add a note/warning within our > documentation than a runtime log/warn message. But I still think, it's a > bit too early to do that. Maybe we should wait a few more releases of > Java and see if any alternatives show up? > > [1] > https://ant.apache.org/ivy/history/latest-milestone/concept.html#packaging > > -Jaikiran > On 10/10/18 11:09 AM, Jan Matèrne (jhm) wrote: >> If I understand Dragans point right, the warning comes when analyzing the >> code. >> Not just running Ivy. >> So the normal user won't see the warning. Maybe we should implement a >> warning? >> >> Jan >> >>> -Ursprüngliche Nachricht- >>> Von: Jaikiran Pai [mailto:jaiki...@apache.org] >>> Gesendet: Mittwoch, 10. Oktober 2018 07:08 >>> An: dev@ant.apache.org >>> Betreff: Re: Java 11 Compatibility Problem >>> >>> I agree with Stefan, at the moment I recommend ignoring those warnings. >>> There isn't anything else we can do (other than removing support for >>> pack200, which isn't a good option). >>> >>> -Jaikiran >>> >>> >>> On 10/10/18 9:56 AM, Stefan Bodewig wrote: Hi Krzysztof I'm not actively working on Ivy so take my response with a grain of salt. On 2018-10-09, Dragan, Krzysztof wrote: > Hi, > scanning latest version of Apache Ivy(2.5.0-rc-1) using jdeprscan on > jdk11 I noticed two problems with this jar. > These two methods using internal jdk marked for removal and will be >>> deleted: > * class org/apache/ivy/util/FileUtil uses deprecated class >java/util/jar/Pack200$Unpacker (forRemoval=true) > * class org/apache/ivy/util/FileUtil uses deprecated class >java/util/jar/Pack200 (forRemoval=true) For background see https://openjdk.java.net/jeps/336 The Java community has decided to eventually remove support for the pack200 format, but it still is there in Java11. Right now this is only a warning, it will only become a real problem once the classes actually get removed. They do not offer any alternative >>> implementation right now, and may never do (unlike the JAXB case, which is available as an external library now). I am aware of an alternative based on the former Apache Harmony code in https://github.com/pfirmstone/pack200 but am unsure about its >>> state - both technically and legally - I very vaguely recall the Pack200 spec was encumbered with Oracle patents but may be totally wrong. In Ivy's case the only save option right now was to remove support >>> for pack200 archives and break existing setups that consume such archives which seems to be excessive just in order to get rid of a warning. If yu ask me I'd recommend to live with the warning for now and wait for an alternative to the class library's pack200 classes to become available - which hopefully happens before the Java version removing support gets released. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional >>> commands, e-mail: dev-h...@ant.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/69 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Linux/81/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/69 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Windows/87/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/69 The build actually caught a genuine issue that this build.xml was meant to catch. I have now added a 3rd commit to this PR which fixes that issue. I'll be squashing these commits before merging, if/when these changes are approved. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user jaikiran commented on the issue: https://github.com/apache/ant/pull/69 The build.xml changes that I committed look a bit wrong. Fixing them to a working version. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/69 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Linux/80/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #69: Allow more control over JUnit libraries and Ant runtime libra...
Github user asfgit commented on the issue: https://github.com/apache/ant/pull/69 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/Ant%20Github-PR-Windows/86/ --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant pull request #69: Allow more control over JUnit libraries and Ant runtim...
GitHub user jaikiran opened a pull request: https://github.com/apache/ant/pull/69 Allow more control over JUnit libraries and Ant runtime libraries for users of junitlauncher I've been sitting on these changes for a while now trying to complete this work and then get some inputs. But I think these changes have now reached a state where I can get some feedback for them. **Background** 1.10.3 of Ant introduced support for using JUnit 5 through the new `junitlauncher` task. The support was minimal but had enough features for users to get started with using JUnit 5. JUnit 5 project divides the JUnit libraries into `platform`, `launcher` and `engine` libraries. Ant's `junitlauncher` task relies only on JUnit `platform` and `launcher` libraries to support launching the tests. The `engine` libraries are allowed to be part of the task's classpath (configured via the `classpath` element). Unlike for the `engine` libraries, the `junitlauncher` task requires the JUnit `platform` and `launcher` libraries to be part of the Ant runtime classpath (either in the Ant installation directories or by using the `-lib` option while launching Ant). Historically, as seen with `junit` task, users prefer more control over the location of these jars while running their tests. **Goal** The goal of the commit(s) in this PR is to allow users to configure a classpath for the `junitlauncher` task with the necessary `platform`, `launcher` JUnit libraries and not force them to place these jars in the Ant runtime classpath. Imagine something like: ``` ``` and then just run the build as: ``` ant test ``` without any explicit `-lib` nor the necessity to place the JUnit libraries in the Ant installation directory. **Overview of changes** Changes in this PR borrow ideas from the `junit` task and at the same time try and keep the complexity of this task manageable. This PR has 2 commits. One is solely in the build file and can be discussed/reviewed separately. I'll explain the build changes later in this PR. The main change in this PR is the commit which refactors the existing code. What that commit does is separates out the classes that are part of the `junitlauncher` task into 2 separate packages. The `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` package as noted in its `package-info.java` documentation is _not_ allowed to have any _compile_ time dependency on the classes in `org.apache.tools.ant.taskdefs.optional.junitlauncher` or any of the classes in JUnit libraries. This allows the implementation of the task to load the JUnit libraries or any classes that depend on those libraries in a way that those classes don't have to be on the runtime classpath of Ant when the build is launched (see `TaskConfiguredPathClassLoader` in this PR and its usage for details). On the other hand, the classes in the `org.apache.tools.ant.taskdefs.optional.junitlauncher` are allowed to have compile time dependency on classes in `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` or any classes that belong to JUnit libraries. Most the "core" logic of launching the tests happens in this package. The commits in this PR are only refactoring changes to get this working. These do not contain any logic changes to the currently supported features of junitlauncher task. Although these refactoring changes do touch some classes/code that's meant to deal with `fork` mode support, none of these changes have any impact on the current functionality of how `fork` mode is implemented. In fact, the classloading changes that are described and implemented here play no role, if the `junitlauncher` task is configured to use `fork` mode. **Backward compatibility** One unfortunate but unavoidable change that I had to do was move the `JUnitLauncherTask` class (among some others) from `org.apache.tools.ant.taskdefs.optional.junitlauncher` to `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` package. This effectively means that if there was anyone out there who were relying on this class (out side of the task usage in the build file itself) will start running into issue. I need input on this part (among other things in this PR) - are we allowed to do such changes and add a backward compatiblity note in our release notes? **Build file change** The commit in this PR which deals with the build file, updates the `build` task to add a `verification` check (to be extra careful) to ensure that the classes in the `org.apache.tools.ant.taskdefs.optional.junitlauncher.confined` package have no compile time dependency on JUnit libraries
