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 <artifactId>wicket</artifactId> to nothing since it is inherited from the parent project. o.a.w:wicket *does* exist but it the user should add <type>pom</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.com>wrote: > 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? > > >
