Carsten Ziegeler wrote: >1) Avalon framework. Up to version 4.1.0 (or something) Avalon had one >big jar: the avalon framework. Then starting with 4.1.1 they splitt this >into two jar files: api and impl. But for convenience they provide both >versions, so for example, you have > > Yep, I understand this is the case here. We're actually planning a "supercedes" attribute in a future version so that both api and impl can declare that they shold block an earlier version of just "framework".
>Now, you can >guess what happens, we end up with the servletapi in the WEB-INF/lib >directory, just because of the transitive dependency. > > Right, its definitely a reason to allow local overriding of the scope. >In fact I think one of the biggest problems are unique identifier for >artifacts. I guess you have already discussed this. > We have some degree of control over what gets into the repository. As long as we are diligent with upload requests, and there are good policies for those that automatically sync in like the ASF, it should be ok. We'll definitely push to migrate to FQN groups after m2's release as it is much easier to control that namespace. >So I agree that theoretically it shouldn't be required but practically >it will be. :) > > Absolutely - we've got the solutions in there in the cases where they are needed, I'd just advocate considering your position first and using them as a last resort. I think this is especially important for projects like Cocoon where you are depended upon by lots of projects, as the quality of your POMs affects everyone else. For example, if you block out dependencies you think are optional but which aren't under certain circumstances then that will affect other projects. Anyway, I hope we've got everything necessary to help you along with this. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
