Re: Looks like there's a problem with OSGi and how we use Maven.

[Ralph Goers <ra...@dslextreme.com>]

What is wrong with the approach we have been using under the osgi module - each Maven module is some subset of core.

Ralph

On Mar 31, 2014, at 1:59 PM, Matt Sicker <bo...@gmail.com> wrote:

> Alright, the basic problem is that each bundle corresponds logically to a Maven module. Since we have only one log4j-core module with optional dependencies, that apparently goes completely against how this would normally be done. Realistically, the better idea would be to split up log4j-core into logical modules based on optional dependencies (thus making them required) and then use the maven-shade-plugin to assemble a log4j-core artifact to avoid having to use multiple JARs in typical environments (or when you aren't using Maven/Gradle/etc.). It's how most other projects are being organized nowadays, and that's probably also due to OSGi.
> 
> If we continue with the monolithic log4j-core with optional dependencies, then creating OSGi versions would require a custom Ant build most likely. In order to get application servers to upgrade log4j, they'll probably desire OSGi bundles as all the major app servers use OSGi presently. We don't need to use anything from OSGi other than using Maven modules logically. If this is undesired, I don't really know how to provide bundles other than through a custom build process which would defeat the purpose of using Maven.
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: Looks like there's a problem with OSGi and how we use Maven.

[Matt Sicker <bo...@gmail.com>]

Well, I've tried a few different methods using the maven-bundle-plugin, but
nothing seems to be working. The only promising looking goals (wrap and
bundleall) are both deprecated. I think we might be able to get away with
using the assembly plugin or something to copy over the necessary files
from log4j-core to build the various bundles.


On 31 March 2014 20:21, Ralph Goers <rg...@apache.org> wrote:

> They are probably just built wrong
>
> Ralph
>
> On Mar 31, 2014, at 5:54 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> They don't seem to work for one. They only declare dependency information
> and don't actually import anything. The API bundle looks fine as it's
> generated directly from log4j-api, but the log4j-core bundles are empty
> (except for a manifest file).
>
>
> On 31 March 2014 18:37, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> What is wrong with the approach we have been using under the osgi module
>> - each Maven module is some subset of core.
>>
>> Ralph
>>
>> On Mar 31, 2014, at 1:59 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Alright, the basic problem is that each bundle corresponds logically to a
>> Maven module. Since we have only one log4j-core module with optional
>> dependencies, that apparently goes completely against how this would
>> normally be done. Realistically, the better idea would be to split up
>> log4j-core into logical modules based on optional dependencies (thus making
>> them required) and then use the maven-shade-plugin to assemble a log4j-core
>> artifact to avoid having to use multiple JARs in typical environments (or
>> when you aren't using Maven/Gradle/etc.). It's how most other projects are
>> being organized nowadays, and that's probably also due to OSGi.
>>
>> If we continue with the monolithic log4j-core with optional dependencies,
>> then creating OSGi versions would require a custom Ant build most likely.
>> In order to get application servers to upgrade log4j, they'll probably
>> desire OSGi bundles as all the major app servers use OSGi presently. We
>> don't need to use anything from OSGi other than using Maven modules
>> logically. If this is undesired, I don't really know how to provide bundles
>> other than through a custom build process which would defeat the purpose of
>> using Maven.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: Looks like there's a problem with OSGi and how we use Maven.

[Ralph Goers <rg...@apache.org>]

They are probably just built wrong

Ralph

> On Mar 31, 2014, at 5:54 PM, Matt Sicker <bo...@gmail.com> wrote:
> 
> They don't seem to work for one. They only declare dependency information and don't actually import anything. The API bundle looks fine as it's generated directly from log4j-api, but the log4j-core bundles are empty (except for a manifest file).
> 
> 
>> On 31 March 2014 18:37, Ralph Goers <ra...@dslextreme.com> wrote:
>> What is wrong with the approach we have been using under the osgi module - each Maven module is some subset of core.
>> 
>> Ralph
>> 
>>> On Mar 31, 2014, at 1:59 PM, Matt Sicker <bo...@gmail.com> wrote:
>>> 
>>> Alright, the basic problem is that each bundle corresponds logically to a Maven module. Since we have only one log4j-core module with optional dependencies, that apparently goes completely against how this would normally be done. Realistically, the better idea would be to split up log4j-core into logical modules based on optional dependencies (thus making them required) and then use the maven-shade-plugin to assemble a log4j-core artifact to avoid having to use multiple JARs in typical environments (or when you aren't using Maven/Gradle/etc.). It's how most other projects are being organized nowadays, and that's probably also due to OSGi.
>>> 
>>> If we continue with the monolithic log4j-core with optional dependencies, then creating OSGi versions would require a custom Ant build most likely. In order to get application servers to upgrade log4j, they'll probably desire OSGi bundles as all the major app servers use OSGi presently. We don't need to use anything from OSGi other than using Maven modules logically. If this is undesired, I don't really know how to provide bundles other than through a custom build process which would defeat the purpose of using Maven.
>>> 
>>> -- 
>>> Matt Sicker <bo...@gmail.com>
> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: Looks like there's a problem with OSGi and how we use Maven.

[Matt Sicker <bo...@gmail.com>]

They don't seem to work for one. They only declare dependency information
and don't actually import anything. The API bundle looks fine as it's
generated directly from log4j-api, but the log4j-core bundles are empty
(except for a manifest file).


On 31 March 2014 18:37, Ralph Goers <ra...@dslextreme.com> wrote:

> What is wrong with the approach we have been using under the osgi module -
> each Maven module is some subset of core.
>
> Ralph
>
> On Mar 31, 2014, at 1:59 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Alright, the basic problem is that each bundle corresponds logically to a
> Maven module. Since we have only one log4j-core module with optional
> dependencies, that apparently goes completely against how this would
> normally be done. Realistically, the better idea would be to split up
> log4j-core into logical modules based on optional dependencies (thus making
> them required) and then use the maven-shade-plugin to assemble a log4j-core
> artifact to avoid having to use multiple JARs in typical environments (or
> when you aren't using Maven/Gradle/etc.). It's how most other projects are
> being organized nowadays, and that's probably also due to OSGi.
>
> If we continue with the monolithic log4j-core with optional dependencies,
> then creating OSGi versions would require a custom Ant build most likely.
> In order to get application servers to upgrade log4j, they'll probably
> desire OSGi bundles as all the major app servers use OSGi presently. We
> don't need to use anything from OSGi other than using Maven modules
> logically. If this is undesired, I don't really know how to provide bundles
> other than through a custom build process which would defeat the purpose of
> using Maven.
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>


-- 
Matt Sicker <bo...@gmail.com>