You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by Jason Dillon <ja...@planet57.com> on 2010/05/30 08:49:51 UTC
slf4j-jdk14 (or other slf4j impls) should not be in the compile scope
Right now, all of the wink components have a compile dependency on slf4j-jdk14, which isn't quite right. You should probably mark the slf4j implementation you are using as scope=test or optional, so that others (like me) don't have to go and do stuff like this:
<dependency>
<groupId>org.apache.wink</groupId>
<artifactId>wink-client</artifactId>
<version>1.1-incubating</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.wink</groupId>
<artifactId>wink-guice-server</artifactId>
<version>1.1-incubating</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
</exclusion>
</exclusions>
</dependency>
Wink, being a library, should not be including an implementation of slf4j, only the api. Its up to the integrator (developer using wink, or application server where wink is deployed) to provide the backing implementation for the slf4j api.
--jason
Re: slf4j-jdk14 (or other slf4j impls) should not be in the compile scope
Posted by Jason Dillon <ja...@planet57.com>.
On May 30, 2010, at 1:33 PM, Bryant Luk wrote:
> Do you recommend putting the jaxb dependencies in a profile for only
> Java 5 as well? I don't know if that profile selection works in
> practice or not so was wondering if you've any experience here.
Profile selection based on jdk version works just fine. So if you want to exclude those deps from the main build and only include them for java5 compat that should be fine. But if you want your dist to be java5 compat, then leave them it... folks that want to use the jdk6's impl can exclude them.
I generally only use provides for the internal build needs, not for including jars in dependent builds based on a profile. I guess it should work, but then when you generate your dist.zip's you have to be sure you are using a java5 vm to get those additional bits included as needed... ie. error prone.
I think the only problem is that older jdk6's did bitch and complain when it found multiple jaxb2 provider bits, but that has been fixed a while back. But the solution is simple enough, either upgrade your jdk, or remove the jaxb2 stuff... both are user actives.
--jason
Re: slf4j-jdk14 (or other slf4j impls) should not be in the compile
scope
Posted by Bryant Luk <br...@gmail.com>.
Do you recommend putting the jaxb dependencies in a profile for only
Java 5 as well? I don't know if that profile selection works in
practice or not so was wondering if you've any experience here.
On Sunday, May 30, 2010, Jason Dillon <ja...@planet57.com> wrote:
> BTW, if you upgrade to slf4j 1.6.0, then it will default to a nop impl instead of complaining, when no other impl is found.
>
> --jason
>
>
> On May 30, 2010, at 5:58 AM, Bryant Luk wrote:
>
>> I agree with this change so I'll make the fix for the next version.
>> For anyone that does not already have a slf4j impl, you will need to
>> include a dependency to your actual implementation.
>>
>> On Sun, May 30, 2010 at 1:49 AM, Jason Dillon <ja...@planet57.com> wrote:
>>> Right now, all of the wink components have a compile dependency on slf4j-jdk14, which isn't quite right. You should probably mark the slf4j implementation you are using as scope=test or optional, so that others (like me) don't have to go and do stuff like this:
>>>
>>> <dependency>
>>> <groupId>org.apache.wink</groupId>
>>> <artifactId>wink-client</artifactId>
>>> <version>1.1-incubating</version>
>>> <scope>test</scope>
>>> <exclusions>
>>> <exclusion>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-jdk14</artifactId>
>>> </exclusion>
>>> </exclusions>
>>> </dependency>
>>>
>>> <dependency>
>>> <groupId>org.apache.wink</groupId>
>>> <artifactId>wink-guice-server</artifactId>
>>> <version>1.1-incubating</version>
>>> <exclusions>
>>> <exclusion>
>>> <groupId>org.slf4j</groupId>
>>> <artifactId>slf4j-jdk14</artifactId>
>>> </exclusion>
>>> </exclusions>
>>> </dependency>
>>>
>>> Wink, being a library, should not be including an implementation of slf4j, only the api. Its up to the integrator (developer using wink, or application server where wink is deployed) to provide the backing implementation for the slf4j api.
>>>
>>> --jason
>
>
Re: slf4j-jdk14 (or other slf4j impls) should not be in the compile scope
Posted by Jason Dillon <ja...@planet57.com>.
BTW, if you upgrade to slf4j 1.6.0, then it will default to a nop impl instead of complaining, when no other impl is found.
--jason
On May 30, 2010, at 5:58 AM, Bryant Luk wrote:
> I agree with this change so I'll make the fix for the next version.
> For anyone that does not already have a slf4j impl, you will need to
> include a dependency to your actual implementation.
>
> On Sun, May 30, 2010 at 1:49 AM, Jason Dillon <ja...@planet57.com> wrote:
>> Right now, all of the wink components have a compile dependency on slf4j-jdk14, which isn't quite right. You should probably mark the slf4j implementation you are using as scope=test or optional, so that others (like me) don't have to go and do stuff like this:
>>
>> <dependency>
>> <groupId>org.apache.wink</groupId>
>> <artifactId>wink-client</artifactId>
>> <version>1.1-incubating</version>
>> <scope>test</scope>
>> <exclusions>
>> <exclusion>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-jdk14</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>>
>> <dependency>
>> <groupId>org.apache.wink</groupId>
>> <artifactId>wink-guice-server</artifactId>
>> <version>1.1-incubating</version>
>> <exclusions>
>> <exclusion>
>> <groupId>org.slf4j</groupId>
>> <artifactId>slf4j-jdk14</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>>
>> Wink, being a library, should not be including an implementation of slf4j, only the api. Its up to the integrator (developer using wink, or application server where wink is deployed) to provide the backing implementation for the slf4j api.
>>
>> --jason
Re: slf4j-jdk14 (or other slf4j impls) should not be in the compile
scope
Posted by Bryant Luk <br...@gmail.com>.
I agree with this change so I'll make the fix for the next version.
For anyone that does not already have a slf4j impl, you will need to
include a dependency to your actual implementation.
On Sun, May 30, 2010 at 1:49 AM, Jason Dillon <ja...@planet57.com> wrote:
> Right now, all of the wink components have a compile dependency on slf4j-jdk14, which isn't quite right. You should probably mark the slf4j implementation you are using as scope=test or optional, so that others (like me) don't have to go and do stuff like this:
>
> <dependency>
> <groupId>org.apache.wink</groupId>
> <artifactId>wink-client</artifactId>
> <version>1.1-incubating</version>
> <scope>test</scope>
> <exclusions>
> <exclusion>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> <dependency>
> <groupId>org.apache.wink</groupId>
> <artifactId>wink-guice-server</artifactId>
> <version>1.1-incubating</version>
> <exclusions>
> <exclusion>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> Wink, being a library, should not be including an implementation of slf4j, only the api. Its up to the integrator (developer using wink, or application server where wink is deployed) to provide the backing implementation for the slf4j api.
>
> --jason