You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by "Donald Woods (JIRA)" <ji...@apache.org> on 2010/11/04 21:14:42 UTC
[jira] Resolved: (BVAL-85) bval-core has no dependency on
slf4j-jcl*
[ https://issues.apache.org/jira/browse/BVAL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Donald Woods resolved BVAL-85.
------------------------------
Resolution: Fixed
r1031193
> bval-core has no dependency on slf4j-jcl*
> -----------------------------------------
>
> Key: BVAL-85
> URL: https://issues.apache.org/jira/browse/BVAL-85
> Project: BeanValidation
> Issue Type: Improvement
> Components: build
> Affects Versions: 0.3-incubating
> Reporter: Albert Lee
> Assignee: Donald Woods
> Fix For: 0.3-incubating
>
> Attachments: BVAL-85.patch
>
>
> BVAL-60 indicates bval-core requires slf4j-jcl* due to dependency from beanutils. I am able to run BVAL in a container without slf4j-jcl*.
> Donald, checks beanutil and found no slf4j-* dependency.
> Need to update pom.xml for proper build procedure.
> Albert Lee.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (BVAL-85) bval-core has no dependency on slf4j-jcl*
Posted by Carlos Vara <ba...@gmail.com>.
One of the 2 dependencies (jcl or jcl-over-slf4j) is needed at runtime or
else classes in BeanUtils will fail with a CNE on instantiation. In order
for the release to be correct, IMO we need to depend on one of the 2.
I chose jcl-over-slf4j as I think it's going to be the most common option.
If a client wanted to use the slf4j-jcl module, he will also be using jcl
and so he will need to configure an exclusion for the jcl-over-slf4j
dependency (most complex maven setup, for what I consider the most rare
scenario).
The other option is making the jcl-over-slf4j dependency optional, so users
of the library will actually be forced to choose between jcl-over-slf4j or
jcl. But if one user forgets to declare any of the 2 as dependencies, the
library will fail at runtime; and there is no mechanism in maven that I know
of to indicate that the decision must be made.
I think the current configuration is the best compromise between safety and
not needing extra configuration in the most common case. However, I'm not a
maven expert so I am open to learning about better options to handle this
case.
On Sun, Nov 14, 2010 at 3:52 PM, Matt Benson <gu...@gmail.com> wrote:
>
> On Nov 10, 2010, at 4:54 PM, Carlos Vara wrote:
>
> > Sorry for the delay in answering to this.
> >
> > I chose to add the dependency to bval-core for safety reasons. Tests
> passed,
> > but some classes in beanutils use commons-logging (see BeanUtilsBean for
> > example), so I opted for the safest route of declaring the jcl-over-slf4j
> > dependency in bval-core.
> >
> > Thinking about it now, even if our current usage of beanutils doesn't
> > involve any of the classes that instantiate a jcl logger, we
> > might inadvertently add a dependency on one class that does, and if we
> don't
> > test it, we could end up shipping a wrong release. On the other side, I
> > realize it's better to avoid that dependency if possible as we are doing
> now
> > with Albert's patch.
> >
> > So simply, if we keep this as it's now, just bear in mind that when
> working
> > on bval-core or bval-jsr303, if any new dependency on beanutils is added,
> we
> > will need to check that it doesn't require jcl, or if it does, the
> > dependency on jcl-over-slf4j will need to be brought back.
> >
>
> I disagree. It *is* possible that a consumer of bval would actually want
> to use the slf4j-jcl module to bridge the slf4j API to the Commons Logging
> implementation at RT. I think the whole idea of slf4j is to depend on the
> APIs only (whether slf4j, Commons Logging, log4j, JUL, etc.); then let the
> consumer pick and choose the necessary dependencies to direct all logging to
> the desired destination.
>
> -Matt
>
> >
> > On Thu, Nov 4, 2010 at 8:14 PM, Donald Woods (JIRA) <ji...@apache.org>
> wrote:
> >
> >>
> >> [
> >>
> https://issues.apache.org/jira/browse/BVAL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
> >>
> >> Donald Woods resolved BVAL-85.
> >> ------------------------------
> >>
> >> Resolution: Fixed
> >>
> >> r1031193
> >>
> >>> bval-core has no dependency on slf4j-jcl*
> >>> -----------------------------------------
> >>>
> >>> Key: BVAL-85
> >>> URL: https://issues.apache.org/jira/browse/BVAL-85
> >>> Project: BeanValidation
> >>> Issue Type: Improvement
> >>> Components: build
> >>> Affects Versions: 0.3-incubating
> >>> Reporter: Albert Lee
> >>> Assignee: Donald Woods
> >>> Fix For: 0.3-incubating
> >>>
> >>> Attachments: BVAL-85.patch
> >>>
> >>>
> >>> BVAL-60 indicates bval-core requires slf4j-jcl* due to dependency from
> >> beanutils. I am able to run BVAL in a container without slf4j-jcl*.
> >>> Donald, checks beanutil and found no slf4j-* dependency.
> >>> Need to update pom.xml for proper build procedure.
> >>> Albert Lee.
> >>
> >> --
> >> This message is automatically generated by JIRA.
> >> -
> >> You can reply to this email to add a comment to the issue online.
> >>
> >>
>
>
Re: [jira] Resolved: (BVAL-85) bval-core has no dependency on slf4j-jcl*
Posted by Matt Benson <gu...@gmail.com>.
On Nov 10, 2010, at 4:54 PM, Carlos Vara wrote:
> Sorry for the delay in answering to this.
>
> I chose to add the dependency to bval-core for safety reasons. Tests passed,
> but some classes in beanutils use commons-logging (see BeanUtilsBean for
> example), so I opted for the safest route of declaring the jcl-over-slf4j
> dependency in bval-core.
>
> Thinking about it now, even if our current usage of beanutils doesn't
> involve any of the classes that instantiate a jcl logger, we
> might inadvertently add a dependency on one class that does, and if we don't
> test it, we could end up shipping a wrong release. On the other side, I
> realize it's better to avoid that dependency if possible as we are doing now
> with Albert's patch.
>
> So simply, if we keep this as it's now, just bear in mind that when working
> on bval-core or bval-jsr303, if any new dependency on beanutils is added, we
> will need to check that it doesn't require jcl, or if it does, the
> dependency on jcl-over-slf4j will need to be brought back.
>
I disagree. It *is* possible that a consumer of bval would actually want to use the slf4j-jcl module to bridge the slf4j API to the Commons Logging implementation at RT. I think the whole idea of slf4j is to depend on the APIs only (whether slf4j, Commons Logging, log4j, JUL, etc.); then let the consumer pick and choose the necessary dependencies to direct all logging to the desired destination.
-Matt
>
> On Thu, Nov 4, 2010 at 8:14 PM, Donald Woods (JIRA) <ji...@apache.org> wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/BVAL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Donald Woods resolved BVAL-85.
>> ------------------------------
>>
>> Resolution: Fixed
>>
>> r1031193
>>
>>> bval-core has no dependency on slf4j-jcl*
>>> -----------------------------------------
>>>
>>> Key: BVAL-85
>>> URL: https://issues.apache.org/jira/browse/BVAL-85
>>> Project: BeanValidation
>>> Issue Type: Improvement
>>> Components: build
>>> Affects Versions: 0.3-incubating
>>> Reporter: Albert Lee
>>> Assignee: Donald Woods
>>> Fix For: 0.3-incubating
>>>
>>> Attachments: BVAL-85.patch
>>>
>>>
>>> BVAL-60 indicates bval-core requires slf4j-jcl* due to dependency from
>> beanutils. I am able to run BVAL in a container without slf4j-jcl*.
>>> Donald, checks beanutil and found no slf4j-* dependency.
>>> Need to update pom.xml for proper build procedure.
>>> Albert Lee.
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
Re: [jira] Resolved: (BVAL-85) bval-core has no dependency on slf4j-jcl*
Posted by Carlos Vara <ba...@gmail.com>.
Sorry for the delay in answering to this.
I chose to add the dependency to bval-core for safety reasons. Tests passed,
but some classes in beanutils use commons-logging (see BeanUtilsBean for
example), so I opted for the safest route of declaring the jcl-over-slf4j
dependency in bval-core.
Thinking about it now, even if our current usage of beanutils doesn't
involve any of the classes that instantiate a jcl logger, we
might inadvertently add a dependency on one class that does, and if we don't
test it, we could end up shipping a wrong release. On the other side, I
realize it's better to avoid that dependency if possible as we are doing now
with Albert's patch.
So simply, if we keep this as it's now, just bear in mind that when working
on bval-core or bval-jsr303, if any new dependency on beanutils is added, we
will need to check that it doesn't require jcl, or if it does, the
dependency on jcl-over-slf4j will need to be brought back.
On Thu, Nov 4, 2010 at 8:14 PM, Donald Woods (JIRA) <ji...@apache.org> wrote:
>
> [
> https://issues.apache.org/jira/browse/BVAL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Donald Woods resolved BVAL-85.
> ------------------------------
>
> Resolution: Fixed
>
> r1031193
>
> > bval-core has no dependency on slf4j-jcl*
> > -----------------------------------------
> >
> > Key: BVAL-85
> > URL: https://issues.apache.org/jira/browse/BVAL-85
> > Project: BeanValidation
> > Issue Type: Improvement
> > Components: build
> > Affects Versions: 0.3-incubating
> > Reporter: Albert Lee
> > Assignee: Donald Woods
> > Fix For: 0.3-incubating
> >
> > Attachments: BVAL-85.patch
> >
> >
> > BVAL-60 indicates bval-core requires slf4j-jcl* due to dependency from
> beanutils. I am able to run BVAL in a container without slf4j-jcl*.
> > Donald, checks beanutil and found no slf4j-* dependency.
> > Need to update pom.xml for proper build procedure.
> > Albert Lee.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>