Brett Porter wrote: > 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". > Hmm, ok, this works for new releases; but I'm wondering if really all old poms will be converted and corrected.
> > 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. > :) Yes, Cocoon depends on more than 130 jars; I'm trying to migrate the core of Cocoon to m2 and the core uses only about 40 jars and we are affected by several "wrong" poms. It will take ages to correct them all. As we are currently using Ant to build Cocoon, today we know exactly which libs are requried in what version - and of course Cocoon runs fine :). With m2 we loose this power. Now, don't get me wrong I really like this transitive dependency handling and it will be a great improvement, but I don't get Cocoon running just because of this :( - and we all agree that poms can always be "wrong" in one way or the other. > Anyway, I hope we've got everything necessary to help you along with this. Hmm, so what can I do today? We currently have the three problems described (avalon, servletapi and ant). Thanks Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
