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 <[email protected]> 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) <[email protected]> > 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. > >> > >> > >
