OSGi and Jigsaw have considerable overlap in concepts, so I'm assuming
there will be integration efforts eventually. However, a friend went to
JavaOne a year or two ago, and the Jigsaw folk were very dismissive of OSGi
in general despite one of the leading OSGi spec leads being on the Jigsaw
project.
On 16 March 2017 at 08:37, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Nevermind. I moved the dependency plugin after the bundle plugin so that
> the classes are copied after the bundle plugin runs and all is well. I have
> no idea how that will impact the OSGi bundle though. Then again, I have no
> idea if OSGi will support multi-release jars.
>
> Ralph
>
> On Mar 15, 2017, at 11:36 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
> I have built the Java 9 code. Now I am copying the classes into the
> log4j-api jar. They have to be placed at META-INF/versions/9. However, when
> I do this I am getting an error from the Maven bundle plugin.
>
> [INFO] --- maven-bundle-plugin:3.2.0:manifest (default) @ log4j-api ---
> [ERROR] Manifest org.apache.logging.log4j:log4j-api:jar:2.8.2-SNAPSHOT :
> Classes found in the wrong directory: {META-INF/versions/9/org/
> apache/logging/log4j/util/ReflectionUtil.class=org.
> apache.logging.log4j.util.ReflectionUtil, META-INF/versions/9/org/
> apache/logging/log4j/util/ClassPredicate.class=org.
> apache.logging.log4j.util.ClassPredicate, META-INF/versions/9/org/
> apache/logging/log4j/util/ClassNamePredicate.class=org.
> apache.logging.log4j.util.ClassNamePredicate}
> [ERROR] Error(s) found in manifest configuration
>
> Any idea on how to get around this?
>
> Ralph
>
>
>
>
>
> On Mar 15, 2017, at 9:14 AM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
> I don’t see a problem with it. What is released will still run fine on
> Java 7. It will just have some Java 9 components in the jar. The release
> is scheduled for late July. I haven’t seen any indication that it will be
> pushed again. I would rather be ready to take advantage of Java 9 on the
> day it is released then be playing catch-up.
>
> Ralph
>
> On Mar 15, 2017, at 8:38 AM, Mikael Ståldal <mikael.stal...@magine.com>
> wrote:
>
> It would be bad to require Java 9 to build the main project as long as
> Java 9 is not released.
>
> On Wed, Mar 15, 2017 at 4:27 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
>> I can’t change the JDK from JDK 1.7. The rest of the build must be
>> compiled at Java 7 since that is what we support. I only want to compile
>> the new classes with Java 9.
>>
>> Using a profile is a very good solution. We would have to run the build
>> twice but that would be OK. I will give that a try.
>>
>> Ralph
>>
>> On Mar 15, 2017, at 8:13 AM, Matt Sicker <boa...@gmail.com> wrote:
>>
>> You can change the JDK from "JDK 1.7 (latest)" to one of the JDK 9
>> versions. Since there's no official release of 9 yet, they don't seem to
>> have a "JDK 9 (latest)" profile set up on Jenkins yet.
>>
>> As for building this, the best solution I've seen so far basically
>> involves a bit of manual configuration using some inline ant tasks or
>> similar overly complicated nonsense which doesn't work well in any IDE to
>> date. It may be worth investigating the existing maven plugin ecosystem and
>> seeing if we need a custom plugin developed for this. Could be a useful
>> feature addition to maven-compiler-plugin, though I haven't tried
>> contributing to Maven yet.
>>
>> Using Maven profiles would help with this so that we can still build most
>> of the project locally with JDK 1.7 or 1.8 as I doubt everyone wants to
>> install JDK 9 on all their development machines while it's still in beta.
>>
>> On 15 March 2017 at 10:07, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>
>>> I know how to implement the StackWalker code but I don’t quite know how
>>> to get it into the build. The main build needs to keep using Java 7 but of
>>> course the StackWalker stuff needs to be compiled with Java 9. Technically,
>>> I know how I could do that except I have no idea how it would work in
>>> Jenkins. It would also mean that everyone would be required to have Java 9
>>> installed in order to do the build.
>>>
>>> An alternate approach would be to have the Java 9 specific classes in a
>>> separate repo with its own build. It would have to be “released” but we
>>> really wouldn’t need or want to release those jars to Maven Central as they
>>> would only be needed in the Log4j build - the classes would be copied into
>>> the Log4j jar.
>>>
>>> If any of you know we can set a Jenkins variable to point to the latest
>>> Java 9 version that could solve the problem.
>>>
>>> Ralph
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>>
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
>
>
>
>
--
Matt Sicker <boa...@gmail.com>
