The only issue i would have is the conflicting org.apache.commons.logging.LogFactory implementations in PaxRunner vs. PaxUrl
This is a problem if you run PaxRunner via api (like in PaxDrone) If you have both in the same classpath it breaks PaxRunner is the worst case. I already mentioned that a while back to alin. I would fix it by myself but problem is why this special factory method (i think its LogFactory.getLog(Class,String)) exists in PaxRunner's implementation anyway. This is no blocker because PaxRunner is already all-in-one,just make sure to not inherit PaxUrl or anything that brings in another LogFactory Impl. flat. Anyway, i would like to know which direction to go in the long run. beside from that very special usage of paxrunner, +1 for all counts. Toni -------- Original-Nachricht -------- > Datum: Fri, 20 Jun 2008 18:03:09 +0800 > Von: "Edward Yakop" <[EMAIL PROTECTED]> > An: "General OPS4J" <[email protected]> > Betreff: Re: Pax-Runner 0.11.0 (and Pax-URL 0.3.2) > On Fri, Jun 20, 2008 at 4:55 PM, Niclas Hedhman <[EMAIL PROTECTED]> > wrote: > > On Fri, Jun 20, 2008 at 4:05 PM, Alin Dreghiciu <[EMAIL PROTECTED]> > wrote: > >> Pax URL 0.3.2 and Pax Runner 0.11.0 released. > >> > >> I think that we should think more seriously about releasing 1.0.0 > >> artifacts for all of them, meaning that we should release also Base > >> and Pax Swissbox. And of course then, releasing them to Maven Central. > > > > Yep, I agree too. So we should release, > +1 > > Regards, > Edward Yakop > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
