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
>> <mailto: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
>>> <mailto: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
>>> <mailto: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
>>>> <mailto: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
>>>> <mailto: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
>>>> <mailto:log4j-dev-unsubscr...@logging.apache.org>
>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>> <mailto:log4j-dev-h...@logging.apache.org>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Mikael Ståldal
>>> Senior software developer
>>>
>>> Magine TV
>>> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com>
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>> <http://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.
>>
>
