I can see why you want to remove the provided scope from slf4j-api. But slf4j-log4j12, and log4j should have the provided scope (it is up to the containing project to choose a different logger). Wicketstuff projects should not force a logger implementation on projects that use it. The same goes for the jetty jars: you are introducing classloading issues by e.g. adding servlet-api's. Those are provided by the servlet-engine that people deploy their projects on.
Note that the "provided" scope is non-transative. On Sun, 22 Mar 2009 10:56 -0400, "James Carman" <[email protected]> wrote: > Well, I went ahead and checked in my changes to the pom files to "fix" > this issue. I would urge all of the project owners out there to make > sure everything looks okay to them. I did change one library's code > to get stuff working. One library was directly using the Log4J API > for logging and I considered that bad style, especially since the > wicket community has the opportunity to use the slf4j to adapt to any > logging environment. > > On Sat, Mar 21, 2009 at 12:55 PM, James Carman > <[email protected]> wrote: > > I don't mind fixing it at all, but I do believe it should be fixed. I > > spent a LONG time trying to figure out why my dependencies were > > showing up as "provided" when I clearly set them up in my pom as the > > default scope (compile). > > > > > > On Sat, Mar 21, 2009 at 12:27 PM, Jeremy Thomerson > > <[email protected]> wrote: > >> I'm totally in favor of anyone who knows more about Maven than me to fix > >> it. I didn't know about the transitive dependency issue. > >> > >> Here are two things that I would add, though: > >> - other than wicket itself, I don't think the parent should add any > >> required dependencies - many subprojects may not need them > >> > >> - you should only make the change if you're willing to fix anything that > >> you break. That's part of the deal. Running a mvn clean install and a > >> mvn site:deploy (it's not deploy, but I can't remember - anyway the site > >> generation is working and should be tested) > >> > >> Jeremy Thomerson > >> http://www.wickettraining.com > >> -- sent from a wireless device > >> > >> > >> -----Original Message----- > >> From: James Carman <[email protected]> > >> Sent: Saturday, March 21, 2009 10:17 AM > >> To: [email protected] > >> Subject: Re: Wicketstuff Core Dependency Management... > >> > >> Wicket itself doesn't declare the dependencies this way. So, why > >> should wicketstuff-core? > >> > >> On Sat, Mar 21, 2009 at 11:11 AM, James Carman > >> <[email protected]> wrote: > >>> But, I shouldn't *have* to do that, Brill. That's the whole point. > >>> Breaking transitive dependency resolution is a bad thing in the maven > >>> world. We're handing dependencies the wrong way if we're breaking > >>> stuff. > >>> > >>> On Sat, Mar 21, 2009 at 11:07 AM, Brill Pappin <[email protected]> wrote: > >>>> Actually that might mess up the rest of us :) > >>>> > >>>> If you need those lobs to be includes, simply add them to you pom and > >>>> change > >>>> their scope so they are included... The build should then override the > >>>> provided scope in the parent. > >>>> > >>>> - Brill Pappin > >>>> Sent from my mobile. > >>>> > >>>> > >>>> On 21-Mar-09, at 9:01 AM, James Carman <[email protected]> > >>>> wrote: > >>>> > >>>>> The dependencies in the main wicketstuff-core are "scoped" for stuff > >>>>> like slf4j and jetty to be "provided". This totally screwed me up > >>>>> when I was trying to write an example application (the log4j stuff > >>>>> wasn't showing up because it was marked as provided by the parent > >>>>> pom). Does anyone care if I remove the scope declarations from the > >>>>> <dependencyManagement> section in the wicketstuff-core parent pom? It > >>>>> fixed my problem when I did. > >>>>> > >>>>> James > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >
