well. looking at the headaches this is causing now, i think the easiest path forward would be to have the wicket module not create an aggregate jar, just list all the dependencies. let non-maven users figure out the dependencies for themselves.
-igor On Mon, Jan 24, 2011 at 9:40 AM, Jeremy Thomerson <jer...@wickettraining.com> wrote: > On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg > <igor.vaynb...@gmail.com>wrote: > >> the reason for >> split was to enforce good code practices. over time as more and more >> people work on wicket the code has become a mess. for example, >> application threadlocal lookups everywhere - with the new structure >> those are out of request processing pipeline. there were a lot of >> interpackage dependencies that simply didnt make sense, it made unit >> testing hell >> > > Okay, that makes good sense. I didn't remember a discussion of why it was > done - but I could have missed that discussion. I think it happened around > the time I was out of the country for a couple months, so I was several > hundred email threads behind :) > > In that case, if we want to keep the aggregated jar for non-Maven users, we > need to: > 1 - build an aggregate sources / javadocs as well > 2 - not deploy the aggregates to Maven so that nobody can accidentally end > up depending on both > > Agreed? > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* >
