Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Hi, I just saw that Mike made a change in wicketstuff-core: change wicket dependency to wicket-core The prevously reverted change was correct but I failed to adjust the project pom.xml's that directly refer to it. This commit changes the dependency from wicket (which no longer exists) to wicket-core. And it also changes the project pom's that used to refer to artifactIdwicket/artifactId to nothing since it is inherited from the parent project. o.a.w:wicket *does* exist but it the user should add typepom/type to the dependency. Now a new question arise: do you find this as inconvenient for the user ? depending on o.a.w:wicket:pom is the solution for the strategy that Igor described - the user app always depends on o.a.w:wicket, no matter in how many smaller modules are actually behind (-core, -util, -request, -html, -wml, ...) If you think this is inconvenient and you have other solutions - I'm all ears. On Tue, Jan 25, 2011 at 8:40 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: yes, people can still make mistakes, but at least when they are fixed its easy to see all places affected. even currently it offers a lot of advantages. for example when working on request module you cannot mistaking add a dependency on Application or Component or somethign else core-specific because it is not in that module. if someone would move Application or Component mistakingly into that module i think it would be easily noticed. -igor On Tue, Jan 25, 2011 at 11:36 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. It seems so far that most are in agreement with this. I tried to do this briefly tonight, but apparently my Maven foo isn't high enough. If anyone wants to try it out, feel free. You can see a diff of what I tried at [1]. I tried several variations, but I think I have a core problem with the approach. Basically, I figured that I could make the wicket module a pom-only project that listed a dependency on -core. Later, a dependency on -html could exist if that were created. -core brings with it -util and -request. Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. They kept looking for wicket.jar, even though I wasn't building a jar. I tried several variations of making it a pom-only project, but perhaps this approach won't work at all. I haven't ever tried this sort of thing before with Maven. Feel free to give me a tip, or a working patch :) [1] - http://mysticpaste.com/view/4881/text (trying out Lombardi's paste tool you need a unified diff colorizer :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. you need to change the dependency type to 'pom' I'll check it later. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. It seems so far that most are in agreement with this. I tried to do this briefly tonight, but apparently my Maven foo isn't high enough. If anyone wants to try it out, feel free. You can see a diff of what I tried at [1]. I tried several variations, but I think I have a core problem with the approach. Basically, I figured that I could make the wicket module a pom-only project that listed a dependency on -core. Later, a dependency on -html could exist if that were created. -core brings with it -util and -request. Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. They kept looking for wicket.jar, even though I wasn't building a jar. I tried several variations of making it a pom-only project, but perhaps this approach won't work at all. I haven't ever tried this sort of thing before with Maven. Feel free to give me a tip, or a working patch :) [1] - http://mysticpaste.com/view/4881/text (trying out Lombardi's paste tool you need a unified diff colorizer :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
[x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. On Tue, Jan 25, 2011 at 9:27 AM, Guillaume Smet guillaume.s...@gmail.comwrote: Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. Guillaume, read the previous mails about the reason to depend on o.a.w:wicket:pom. Actually this kind of dependency is also recommended in Sonatype's Maven book - aggregation over inheritance. They have plans to make improvements in that area in Maven 3.1. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. I have it working here. Commit is coming. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? On Tue, Jan 25, 2011 at 7:17 AM, Martin Grigorov mgrigo...@apache.org wrote: [x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. On Tue, Jan 25, 2011 at 9:27 AM, Guillaume Smet guillaume.s...@gmail.comwrote: Hi Jeremy, On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Then, I changed all other modules that were depending on -core to depend on plain wicket. But, that didn't work. IMHO, it's a bad idea. If the goal is to have cleaner dependencies, you should make your modules dependant on the -core/-whatever jars, not the aggregated pom dependency. The latter should only be used by users to facilitate their migration. Guillaume, read the previous mails about the reason to depend on o.a.w:wicket:pom. Actually this kind of dependency is also recommended in Sonatype's Maven book - aggregation over inheritance. They have plans to make improvements in that area in Maven 3.1. But if you really want to do that, you need to add: typepom/type to your wicket dependency to make it work. Have a nice day. I have it working here. Commit is coming. -- Guillaume
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. signature.asc Description: OpenPGP digital signature
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: 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. It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Spring distribution hasn't the spring.jar anymore: https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote: When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. -- Pedro Henrique Oliveira dos Santos
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Spring stopped distributing aggregate jar since version 3.0. We could consider to keep distributing aggregate jar for a certain number of future versions but in the end i think we should fully embrace modules organization. When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsherm...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Which is kinda sad, since I still find too many Ant (and variants) -based projects out there (which is even more sad). Spring is becoming increasingly more difficult for beginners. Even the old MVC tutorial (which were a very good step-by-step script) isn't available anywhere anymore. It doesn't really affect me, since I use maven whenever I have the option, and already know how to do all these, but Well, the good side is that, beginners will have to learn maven from the start (since is the only bearable option), and hopefully Ant will become a forgotten artifact from ancient times... :) Tetsuo On Tue, Jan 25, 2011 at 11:27 AM, Pedro Santos pedros...@gmail.com wrote: Spring distribution hasn't the spring.jar anymore: https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote: When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. -- Pedro Henrique Oliveira dos Santos
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 7:06 AM, James Carman ja...@carmanconsulting.comwrote: It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO. The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
yes, people can still make mistakes, but at least when they are fixed its easy to see all places affected. even currently it offers a lot of advantages. for example when working on request module you cannot mistaking add a dependency on Application or Component or somethign else core-specific because it is not in that module. if someone would move Application or Component mistakingly into that module i think it would be easily noticed. -igor On Tue, Jan 25, 2011 at 11:36 AM, James Carman ja...@carmanconsulting.com wrote: On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
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 jer...@wickettraining.com 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*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
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 ja...@carmanconsulting.com 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 jer...@wickettraining.com 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*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: 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*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
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.comwrote: 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*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
I looked into the wicket/pom.xml and the maven-source-plugin is disabled: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId configuration !-- Do not deploy -sources.jar file. This project has no .java files -- attachfalse/attach /configuration /plugin But google found this goal for the plugin: http://maven.apache.org/plugins/maven-source-plugin/aggregate-mojo.html I haven't tested it but the description of 'Aggregate sources for all modules in an aggregator project.' sounds like exactly what you want for these tasks. Mike the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynbergigor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
I think this still wouldn't solve the duplicated classes issue (depending on wicket and wicket-extensions in the same time). Peter 2011-01-24 19:23 keltezéssel, Michael O'Cleirigh írta: I looked into the wicket/pom.xml and the maven-source-plugin is disabled: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId configuration !-- Do not deploy -sources.jar file. This project has no .java files -- attachfalse/attach /configuration /plugin But google found this goal for the plugin: http://maven.apache.org/plugins/maven-source-plugin/aggregate-mojo.html I haven't tested it but the description of 'Aggregate sources for all modules in an aggregator project.' sounds like exactly what you want for these tasks. Mike the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynbergigor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 7:09 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: the aggregate is there to protect users if/when we split more things out... And to also protect our users when they only 'up' the version number, but keep the wicket artifact id. Martijn
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 7:23 PM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: I looked into the wicket/pom.xml and the maven-source-plugin is disabled: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId configuration !-- Do not deploy -sources.jar file. This project has no .java files -- attachfalse/attach /configuration /plugin I added this few days ago. This disables the deployment of -sources.jar because it is empty (just META-INF). But google found this goal for the plugin: http://maven.apache.org/plugins/maven-source-plugin/aggregate-mojo.html Yes, this would solve the problem. There is similar for -javadoc. I haven't tested it but the description of 'Aggregate sources for all modules in an aggregator project.' sounds like exactly what you want for these tasks. Mike the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynbergigor.vaynb...@gmail.com wrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
2011/1/24 Major Péter majorpe...@sch.bme.hu I think this still wouldn't solve the duplicated classes issue (depending on wicket and wicket-extensions in the same time). Let's think now what problems would cause making -extentions (and all other except -util and -request) depending on wicket.jar Peter 2011-01-24 19:23 keltezéssel, Michael O'Cleirigh írta: I looked into the wicket/pom.xml and the maven-source-plugin is disabled: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId configuration !-- Do not deploy -sources.jar file. This project has no .java files -- attachfalse/attach /configuration /plugin But google found this goal for the plugin: http://maven.apache.org/plugins/maven-source-plugin/aggregate-mojo.html I haven't tested it but the description of 'Aggregate sources for all modules in an aggregator project.' sounds like exactly what you want for these tasks. Mike the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynbergigor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Then depending on wicket-core would cause the very same trouble with duplicated classes... 2011-01-24 19:36 keltezéssel, Martin Grigorov írta: 2011/1/24 Major Pétermajorpe...@sch.bme.hu I think this still wouldn't solve the duplicated classes issue (depending on wicket and wicket-extensions in the same time). Let's think now what problems would cause making -extentions (and all other except -util and -request) depending on wicket.jar Peter 2011-01-24 19:23 keltezéssel, Michael O'Cleirigh írta: I looked into the wicket/pom.xml and the maven-source-plugin is disabled: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId configuration !-- Do not deploy -sources.jar file. This project has no .java files -- attachfalse/attach /configuration /plugin But google found this goal for the plugin: http://maven.apache.org/plugins/maven-source-plugin/aggregate-mojo.html I haven't tested it but the description of 'Aggregate sources for all modules in an aggregator project.' sounds like exactly what you want for these tasks. Mike the aggregate is there to protect users if/when we split more things out... -igor On Mon, Jan 24, 2011 at 10:06 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynbergigor.vaynb...@gmail.comwrote: have the wicket module not create an aggregate jar, just list all the dependencies. Then we don't need the wicket module at all, right? Or I'm misunderstanding what you mean by list all the dependencies - which I assume to mean document the jars you need somewhere. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:43 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov mgrigo...@apache.orgwrote: Let's think now what problems would cause making -extentions (and all other except -util and -request) depending on wicket.jar IMHO, we do *not* want wicket.jar to even be available in Maven. The aggregate jar should be only for those who do not use Maven. Those who use it should just change from wicket to wicket-core when they upgrade versions and everything will continue to work. Should have mentioned the reason again for this: to avoid the possibility of Maven users having duplicate classes in the classpath. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
we should have the aggregate module explained for the reason in mine and martijn's emails. we should simply change it so it doesnt deploy any artifacts, just a pom. non-maven users will have to figure it out. -igor On Mon, Jan 24, 2011 at 10:43 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 12:43 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov mgrigo...@apache.orgwrote: Let's think now what problems would cause making -extentions (and all other except -util and -request) depending on wicket.jar IMHO, we do *not* want wicket.jar to even be available in Maven. The aggregate jar should be only for those who do not use Maven. Those who use it should just change from wicket to wicket-core when they upgrade versions and everything will continue to work. Should have mentioned the reason again for this: to avoid the possibility of Maven users having duplicate classes in the classpath. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: we should have the aggregate module explained for the reason in mine and martijn's emails. we should simply change it so it doesnt deploy any artifacts, just a pom. I disagree. Why go through the trouble of creating a fake aggregate module just so someone doesn't have to type five characters in their pom when upgrading a major version? When they change 1.4.16 in their POM to 1.5.0, they can also type -core at the end of their wicket dependency. Done. No maintenance on our side. non-maven users will have to figure it out. I'm fine with this - they're used to it. I think they must like the pain. :) So, in summary: my opinion is that we just remove the aggregate module and move on with real development. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. -igor On Mon, Jan 24, 2011 at 10:52 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: we should have the aggregate module explained for the reason in mine and martijn's emails. we should simply change it so it doesnt deploy any artifacts, just a pom. I disagree. Why go through the trouble of creating a fake aggregate module just so someone doesn't have to type five characters in their pom when upgrading a major version? When they change 1.4.16 in their POM to 1.5.0, they can also type -core at the end of their wicket dependency. Done. No maintenance on our side. non-maven users will have to figure it out. I'm fine with this - they're used to it. I think they must like the pain. :) So, in summary: my opinion is that we just remove the aggregate module and move on with real development. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* I'm +1 for this one: [+1] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
[+1] - Just forget about the aggregated wicket.jar and modify the wicket... -igor On Mon, Jan 24, 2011 at 2:40 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: what if we factor out html packages out of core? core wont have a dependency on them. then all people will have to change from wicket-core to wicket-html. the wicket module serves as a standard wicket profile which is everything you need to run on a servlet container and build web apps. Gotcha. So, please cast a vote (this is not an official vote thread, but I want to get the feelings on this) for one of the following two methods of handling this: [ ] - Make an aggregated jar for classes, one for sources, and one for javadocs. This means that people can accidentally end up in classpath nightmares by having multiple duplicate classes on their classpath. It helps non-Maven users by making a single jar download. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, 24 Jan 2011 15:47:58 -0800 Igor Vaynberg igor.vaynb...@gmail.com wrote: [+1] - Just forget about the aggregated wicket.jar and modify the wicket... Non-binding, just my opinion: [+1] - Just forget about the aggregated wicket.jar and modify the wicket... Carl-Eric www.wicketbuch.de
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
[x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
[x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module On Mon, Jan 24, 2011 at 10:59 PM, Ryan McKinley [via Apache Wicket] ml-node+3235299-873970764-65...@n4.nabble.comml-node%2b3235299-873970764-65...@n4.nabble.com wrote: [x] - Just forget about the aggregated wicket.jar and modify the wicket module a pom-only module. This means Maven users can eternally depend on wicket only, and not care about how we (re-)structure our code. Non-maven users will have to download all the separate jars, or use Ivy, or whatever. -- If you reply to this email, your message will be added to the discussion below: http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-tp3234420p3235299.html To start a new topic under Apache Wicket, email ml-node+1842946-398011874-65...@n4.nabble.comml-node%2b1842946-398011874-65...@n4.nabble.com To unsubscribe from Apache Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=. -- Sincerely, JC (http://www.linkedin.com/in/jcgarciam) --Anyone who has never made a mistake has never tried anything new.-- -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-tp3234420p3235357.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
