You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jeremy Thomerson <je...@wickettraining.com> on 2011/01/24 18:02:35 UTC
[discuss] How to resolve wicket aggregate classes / sources jar issues
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
Posted by Martin Grigorov <mg...@apache.org>.
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 <ig...@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
> > <je...@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
Posted by Igor Vaynberg <ig...@gmail.com>.
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
> <je...@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
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson
<je...@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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Tue, Jan 25, 2011 at 7:06 AM, James Carman <ja...@carmanconsulting.com>wrote:
> 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
Posted by James Carman <ja...@carmanconsulting.com>.
On Mon, Jan 24, 2011 at 12:32 PM, Igor Vaynberg <ig...@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
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Jan 24, 2011 at 7:09 PM, Igor Vaynberg <ig...@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
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Jan 24, 2011 at 7:23 PM, Michael O'Cleirigh <
michael.ocleirigh@rivulet.ca> wrote:
> I looked into the wicket/pom.xml and the maven-source-plugin is disabled:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-source-plugin</artifactId>
> <configuration>
> <!-- Do not deploy -sources.jar file.
> This project has no .java files
> -->
> <attach>false</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
>> <je...@wickettraining.com> wrote:
>>
>>> On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg<igor.vaynberg@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
Posted by jcgarciam <jc...@gmail.com>.
[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-65838@n4.nabble.com<ml...@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-65838@n4.nabble.com<ml...@n4.nabble.com>
> To unsubscribe from Apache Wicket, click here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1842946&code=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.
Re: [discuss] How to resolve wicket aggregate classes / sources jar
issues
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
On Mon, 24 Jan 2011 15:47:58 -0800
Igor Vaynberg <ig...@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
Posted by Igor Vaynberg <ig...@gmail.com>.
[+1] - Just forget about the aggregated wicket.jar and modify the wicket...
-igor
On Mon, Jan 24, 2011 at 2:40 PM, Jeremy Thomerson
<je...@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg <ig...@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:
>
>
>
> [ ] - 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
Posted by tetsuo <ro...@gmail.com>.
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 <pe...@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=2858&r=2854&r=2940&r=3872
>
> On Tue, Jan 25, 2011 at 10:27 AM, tetsuo <ro...@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 <ma...@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
Posted by Pedro Santos <pe...@gmail.com>.
Spring distribution hasn't the spring.jar anymore:
https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858&r=2854&r=2940&r=3872
On Tue, Jan 25, 2011 at 10:27 AM, tetsuo <ro...@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 <ma...@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
Posted by Andrea Del Bene <ad...@ciseonweb.it>.
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 Bowsher<ma...@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
Posted by tetsuo <ro...@gmail.com>.
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 <ma...@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
Posted by Max Bowsher <ma...@f2s.com>.
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
Posted by tetsuo <ro...@gmail.com>.
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 <mg...@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 <gu...@gmail.com>wrote:
>
>> Hi Jeremy,
>>
>> On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson
>> <je...@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:
>> <type>pom</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
Posted by Martin Grigorov <mg...@apache.org>.
[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 <gu...@gmail.com>wrote:
> Hi Jeremy,
>
> On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson
> <je...@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:
> <type>pom</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
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Jeremy,
On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson
<je...@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:
<type>pom</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
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Jan 25, 2011 at 9:18 AM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson <
> jeremy@wickettraining.com
> > wrote:
>
> > On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson <
> > jeremy@wickettraining.com> wrote:
> >
> >> On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg <igor.vaynberg@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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 4:41 PM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
> On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson <
> jeremy@wickettraining.com> wrote:
>
>> On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg <ig...@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.
>>
>> [ ] - 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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 4:40 PM, Jeremy Thomerson <jeremy@wickettraining.com
> wrote:
>
> On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg <ig...@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.
>
> [ ] - 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
Posted by Ryan McKinley <ry...@gmail.com>.
>
> [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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 2:37 PM, Igor Vaynberg <ig...@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.
[ ] - 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> 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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 12:47 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> 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
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 12:43 PM, Jeremy Thomerson <
> jeremy@wickettraining.com> wrote:
>
>> On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov <mg...@apache.org>wrote:
>>
>>> 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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 12:43 PM, Jeremy Thomerson <
jeremy@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov <mg...@apache.org>wrote:
>
>> 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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 12:36 PM, Martin Grigorov <mg...@apache.org>wrote:
> 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.
--
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
Posted by Major Péter <ma...@sch.bme.hu>.
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éter<ma...@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>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-source-plugin</artifactId>
>>> <configuration>
>>> <!-- Do not deploy -sources.jar file.
>>> This project has no .java files
>>> -->
>>> <attach>false</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
>>>> <je...@wickettraining.com> wrote:
>>>>
>>>>> On Mon, Jan 24, 2011 at 11:50 AM, Igor
>>>>> Vaynberg<ig...@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
Posted by Martin Grigorov <mg...@apache.org>.
2011/1/24 Major Péter <ma...@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>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-source-plugin</artifactId>
>> <configuration>
>> <!-- Do not deploy -sources.jar file.
>> This project has no .java files
>> -->
>> <attach>false</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
>>> <je...@wickettraining.com> wrote:
>>>
>>>> On Mon, Jan 24, 2011 at 11:50 AM, Igor
>>>> Vaynberg<ig...@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
Posted by Major Péter <ma...@sch.bme.hu>.
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>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-source-plugin</artifactId>
> <configuration>
> <!-- Do not deploy -sources.jar file.
> This project has no .java files
> -->
> <attach>false</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
>> <je...@wickettraining.com> wrote:
>>> On Mon, Jan 24, 2011 at 11:50 AM, Igor
>>> Vaynberg<ig...@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
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
I looked into the wicket/pom.xml and the maven-source-plugin is disabled:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<configuration>
<!-- Do not deploy -sources.jar file.
This project has no .java files
-->
<attach>false</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
> <je...@wickettraining.com> wrote:
>> On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg<ig...@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
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg <ig...@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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 11:50 AM, Igor Vaynberg <ig...@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
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> wrote:
> On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg <ig...@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*
>
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Mon, Jan 24, 2011 at 11:32 AM, Igor Vaynberg <ig...@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*
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Posted by Igor Vaynberg <ig...@gmail.com>.
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
> <je...@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
Posted by James Carman <ja...@carmanconsulting.com>.
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
<je...@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*
>