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* >
