On Mon, 19 Sep 2005, Brett Porter wrote: Hi,
> Hi, > > I'd like to add an optional scope to dependencies as a way to not pass > them on to projects depending on your library. This would allow fixing > things like dom4j that pull in extra dependencies. > > If we don't do this, I believe scope=provided will be abused as using > that will do it, and prevent us from changing that behaviour in future > if desired. scope=provided currently does not do this (but I like it to :)) If that change is committed, we might need something like that new scope. > Thoughts? Anyone disagreeing has to provide a viable way to deal with > dom4j and friends :) Well, the excludes mechanism can deal with this. I believe there was an idea about specifying api's as dependencies and a default implementation for that. If a nearer project specifies another implementation, that should be used. Although I don't know how this should (and can?) be implemented. For instance, a war project can be considered final, but then you could also package it into an ear, which might override the implementation specified in the war's pom. Btw, the dependencies brought along with dom4j are needed to use that project, right? Unless the project uses that project with dom4j specifies those dependencies, it'll break at runtime. Isn't it the job of the 'nearest' conflict resolution to override versions brought in by dependencies? But i guess this is not a version issue, but an 'implementation provider' issue? Could you elaborate more on the exact problem? :) -- Kenney > > - Brett > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Kenney Westerhof http://www.neonics.com GPG public key: http://www.gods.nl/~forge/kenneyw.key --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
