Yeah, I have no idea how you would build the module-info.class file.
module-info.java is compiled by the compiler and it performs checks to make
sure the things being exported are really there. So you would need to have a
maven module that unpacks all the classes and then compiles the
module-info.java and then creates the uber jar for that to work.
Ralph
> On Apr 24, 2017, at 11:36 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> It doesn't sound like there's a proper way to export a Java 9 module from
> two separate JARs, though I'm not clear on the details. If we package up
> the modules into a sort of log4j-core-all artifact, that'd be an assembly
> detail for distribution.
>
> On 24 April 2017 at 13:19, Remko Popma <remko.po...@gmail.com> wrote:
>
>> I must be missing something, I don't see the problem. Users wouldn't have
>> both the combined jar and the single-module jars on the classpath together,
>> so there should not be an issue...
>>
>> For example, assume our current log4j-core jar is split up into
>> * log4j-core-slim
>> * log4j-core-appender-db
>> * log4j-core-appender-mom
>> * log4j-core-appender-net
>>
>> That is 4 jars where we used to have 1.
>>
>> Now, the combined jar ("log4j-core-all", for example) would have all
>> classes of the above 4 jars.
>>
>> Users can then use log4j-core-all + log4j-api similar to how they
>> currently do, no?
>>
>> Are you worried about users combining log4j-core-all with
>> log4j-core-appender-db?
>>
>> Remko
>>
>> (Shameless plug) Every main() method deserves http://picocli.info
>>
>>> On Apr 25, 2017, at 2:55, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>>
>>> Guess what? If I am understanding Stephen correctly uber jars are not
>> going to work as you can’t have multiple modules that export the same
>> package.
>>>
>>> Ralph
>>>
>>>> On Apr 24, 2017, at 10:43 AM, Remko Popma <remko.po...@gmail.com>
>> wrote:
>>>>
>>>> How many new modules are we talking about, concretely?
>>>>
>>>> Matt mentioned the StackOverflow questions about transitive dependencies
>>>> etc, but I imagine splitting log4j-core into 5 or more new modules will
>>>> also cause confusion... It won't be trivial for users to figure out
>> which
>>>> of the many modules they do or don't need. The coarse granularity of the
>>>> current modules is a good thing for users.
>>>>
>>>> What problem are we trying to solve? And how can we solve it with the
>> least
>>>> disruption to our users?
>>>>
>>>> Would it be an idea, for example, to provide separate jars for the
>> separate
>>>> modules, but in addition create a combined jar (log4j-core-all) that
>>>> contains all the classes in log4j-core as well as the classes in the new
>>>> modules we split out from core?
>>>>
>>>>
>>>>> On Tue, Apr 25, 2017 at 2:00 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>
>>>>> I agree with Ralph here. I'm sure we'll figure out rather quickly which
>>>>> modules are easy to put into rarely updated repositories.
>>>>>
>>>>>> On 24 April 2017 at 11:39, Ralph Goers <ralph.go...@dslextreme.com>
>> wrote:
>>>>>>
>>>>>> I would prefer a hybrid approach. First things should be moved to
>>>>>> separate modules. Then, if they don’t seem to be modified frequently
>> they
>>>>>> can be moved to a separate repo. For example, I think it would be OK
>> for
>>>>>> the Flume Appender to be in a separate repo. It hasn’t changed in
>> quite a
>>>>>> while and I can’t remember the last time it was modified due to
>> changes
>>>>> in
>>>>>> Log4j it has and while continue to change with changes made in Flume
>>>>>> releases. I imagine we have quite a few components that are similar.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 24, 2017, at 8:39 AM, Gary Gregory <garydgreg...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Apr 24, 2017 2:38 AM, "Mikael Ståldal" <mikael.stal...@magine.com
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> I fully agree with Matt's both proposals.
>>>>>>>
>>>>>>> I'm skeptic to creating more repositories (than we already have)
>>>>> though.
>>>>>> I
>>>>>>> think that we should start by splitting out modules from log4j-core
>> and
>>>>>>> keep those modules in the main repository with synchronized
>> versioning
>>>>>> and
>>>>>>> releases, at least for the 2.9 release. We can always move those
>>>>> modules
>>>>>> to
>>>>>>> other repositories later if we want to.
>>>>>>>
>>>>>>>
>>>>>>> I do not like more repos either. Since we have already gone down the
>>>>> more
>>>>>>> modules road, I say we keep going.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>> It is a lot of administrative work to create a new repository (as we
>>>>> have
>>>>>>> seen for log4j-scala), I don't want us to do all that work over and
>>>>> over
>>>>>>> again unless really necessary.
>>>>>>>
>>>>>>> We have a JIRA ticket for this:
>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1650
>>>>>>>
>>>>>>> I have already started by breaking out log4j-server:
>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1851
>>>>>>>
>>>>>>> I think the next step is to break out plugins (layouts and appenders)
>>>>>> with
>>>>>>> optional 3rd party dependencies into their own modules.
>>>>>>>
>>>>>>>
>>>>>>>> On Sun, Apr 23, 2017 at 7:45 PM, Matt Sicker <boa...@gmail.com>
>> wrote:
>>>>>>>>
>>>>>>>> I think I brought this topic up like 3 years ago when I was working
>> on
>>>>>>>> initial OSGi support, but now that we have 3 more years worth of
>> code
>>>>>>>> additions and optional features, I think this might be a more
>>>>>> appropriate
>>>>>>>> time to discuss it again in light of experience.
>>>>>>>>
>>>>>>>> Building log4j-core itself already takes a long time, and many
>> plugins
>>>>>>>> aren't updated very often at all. In the past, requiring users to
>>>>> simply
>>>>>>>> add log4j-core plus any transitive dependencies to use optional
>>>>> features
>>>>>>>> seemed to work well enough, but I still think that's a confusing
>>>>>>>> distribution mechanism as demonstrated by the numerous bug reports
>> and
>>>>>>>> Stack Overflow posts regarding missing transitive dependencies for
>>>>>> various
>>>>>>>> features. I spent some time experimenting with Log4j Boot a little
>>>>> while
>>>>>>>> ago to help alleviate this problem, but this may be unnecessary if
>> we
>>>>>> can
>>>>>>>> agree to modularize log4j-core itself.
>>>>>>>>
>>>>>>>> I have two different proposals, both of which can be used at the
>> same
>>>>>>> time.
>>>>>>>>
>>>>>>>> 1. Split out everything from log4j-core that requires 3rd party
>>>>>>>> dependencies (except for AsyncLogger, though perhaps we could
>> consider
>>>>>>>> shading and renaming those classes like some other low level
>> libraries
>>>>>> do
>>>>>>>> with JCTools). Ideally, I'd like to see each module have required
>>>>>>>> dependencies instead of optional ones, so that if, for instance, I
>>>>>> include
>>>>>>>> a "log4j-config-yaml" dependency, I know that Log4j will support
>> YAML
>>>>>>>> configuration without having to specify the individual Jackson
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>> 2. Split out from log4j-core a sort of log4j-spi module which
>> defines
>>>>>>>> interfaces, abstract classes, and annotations for plugins that would
>>>>> be
>>>>>>>> promoted to the same level of backwards compatibility guarantees as
>>>>>>>> log4j-api. This would aid in cementing what we really wish to
>> maintain
>>>>>>>> compatibility with in the backend while allowing other modules to
>> have
>>>>>>> less
>>>>>>>> strict guarantees.
>>>>>>>>
>>>>>>>> With proposal #1, I'd think that we could more easily start moving
>>>>>> modules
>>>>>>>> into separate repositories and release trains. Without #2, though,
>>>>> this
>>>>>>>> makes version support more annoying to handle, but that's what we'll
>>>>>> face
>>>>>>>> regardless as we separate more repositories. If we go this route,
>> then
>>>>>>>> there will be no need for a Log4j Boot subproject.
>>>>>>>>
>>>>>>>> What do you all think?
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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>
>>>>>
>>>
>>>
>>
>
>
>
> --
> Matt Sicker <boa...@gmail.com>
