while util and request *can* be used outside of wicket, they probably wont be - but that was not the reason for the split. 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. you basically could not unit test any part of the code without wickettester anymore because something somewhere would depend on something that needed request cycle, or session, or application setup.
with the new split we have introduced iprovider interface which decouples the mess. a good example is that if now some part of request processing needs a configurable option it gets it via iprovider which in turn gets it from an application setting. this allows us to unit test that part of code without requiring the application to be set up and thus without requiring wicket tester. in the future there may be more splits. for example splitting an http module out which handles all the servlet related stuff. this would probably require another large effort because i bet lots of unrelated packages depend on servlet stuff because its easier to do that then introduce an indirection. another candidate is html stuff. split that out into a separate module. this is why we have tried to introduce the wicket module. it was meant to be as an aggregate for these smaller modules so if we were going to split something out it would be transparent to the user. -igor On Mon, Jan 24, 2011 at 9:14 AM, James Carman <[email protected]> wrote: > I have also questioned the usefulness of this new approach, compared > to all of the hoops you have to go through to get it to work? What > are we saving here? Are wicket-request and wicket-util really > intended to be used outside of Wicket? I really don't see the > benefit, at least when you consider the "cost". > > On Mon, Jan 24, 2011 at 12:02 PM, Jeremy Thomerson > <[email protected]> wrote: >> There are two issues [1] and [2] that deal with 1.5-RC1 having an aggregate >> jar for the wicket-core, wicket-request, and wicket-util classes, but not >> having an aggregate of the sources. Martin graciously assigned it to me, >> but I want to discuss it with the community to figure out how we should >> resolve it. First, some background (hopefully I'm remembering it all >> correctly) >> >> What was all previously in the wicket subfolder was split into wicket / >> wicket-core / wicket-util in the early development of 1.5. I don't know why >> - can someone comment on why? I don't think it could possibly give us that >> much benefit or be *that much* cleaner. But, maybe it is. >> >> Then, to avoid confusion for those who previously depended on wicket.jar >> (which now is missing all -util and -request classes), the wicket subfolder >> was renamed to wicket-core, and wicket.jar was built as an aggregate of >> wicket-core, wicket-util, and wicket-request. This was really just done for >> non-Maven users so that they could get all the core Wicket dependencies in >> one jar rather than three. >> >> Problems: >> 1 - if you use Maven, you should just depend on wicket-core, which will >> depend on the others. But, if you incorrectly depend on wicket.jar, and >> wicket-auth-roles or extensions, etc, you end up with duplicated classes >> because you'll have wicket.jar and the three independent jars. >> 2 - If you don't use Maven, you can just use wicket.jar, but we're not >> building wicket-sources.jar (or it's built empty), so you can't really >> attach sources in your IDE. >> >> Solutions: >> 1 - Martin suggests that we don't deploy wicket.jar to maven repos because >> it's not intended for maven users. I agree with this, but it doesn't fix >> all the problems above >> 2 - We could somehow build wicket-sources (and wicket-javadocs) jar files. >> These should be deployed wherever wicket.jar is, but like #1 mentions, none >> should go to Maven repos. >> 3 - Combine all three projects back into one. All these problems are solved >> instantly. >> 4 - Don't build the aggregated jar(s) at all. >> >> Really, I'd opt for #3. I don't think we need all three separate projects. >> I don't see a benefit. If we must keep the three separate code modules, >> then I opt for #4. I don't like the idea of deploying multiple artifacts >> with the same stuff in them. It's too easy for folks to end up with >> duplicated classes in their classpath. We don't want to contribute to that. >> >> Whatever we decide, I feel that if we build wicket.jar (aggregated classes), >> we *must* build a sources and javadocs jar. >> >> Input? >> >> [1] - https://issues.apache.org/jira/browse/WICKET-3365 >> [2] - https://issues.apache.org/jira/browse/WICKET-3376 >> >> -- >> Jeremy Thomerson >> http://wickettraining.com >> *Need a CMS for Wicket? Use Brix! http://brixcms.org* >> >
