If I recall correctly than we split the sources into -core, -util and -request for development reasons. To keep our internal architecture clean and identify possibly unwanted dependencies between them early and easy.
I thought because Maven does not support (internal) subprojects, we ended up with 3 jars in the maven repository. Juergen On Tue, Aug 16, 2011 at 7:07 PM, Martin Grigorov <[email protected]> wrote: > Hi Andreas, > > Sorry, but it is hard for me to understand what you mean in the three > points in your first mail. > > I'll copy them here to make it easier to comment on them: > 1. OSGifying all three of them using split-package. > Without OSGi experience it is hard for me to imagine what this mean. > 2. Embed util and request into wicket-core. > Do you mean here to merge back the code from -util and -request back > in wicket-core/src/main/java ? > I hope you don't because I see this as a step back. What if my app > uses Guice - should I merge the code in -ioc and -guice into -core ?! > No. > 3. Provide e.g. "apache-wicket" which repacks core, util and request into > one package. > Again: what is the difference with wicketstuff/wicket-bundle project ? > > If the best solution is to deploy just one .jar in the OSGi container > than maybe wicket-bundle should merge -util, -request and -core from > Wicket distro and -osgi from wicketstuff/ops4j. > > Start your work in wicketstuff/ops4j and when you have it done then we > can start a vote whether to add it in Wicket distro or not. I cannot > decide that by myself. I have just a single vote. > I personally don't like the approach "merge -util, -request and -core > into wicket.jar (as in Wicket 1.4) and put the additional OSGi related > code there too. > > No matter what you decide I'll be glad to help you! > > On Tue, Aug 16, 2011 at 6:51 PM, Andreas Pieber <[email protected]> wrote: >> Hey Martin, >> >> I think this is more kind of a principle question. Yes, it is possible to >> keep this all in wicketstuff/pax-wicket. We can also fork wicket and >> implement osgi support there. Or I can use maven to adapt and >> overwrite/repack wicket in pax-wicket as required. >> >> So again, this thread isn't about what can be done, but rather what should >> be done. What is the best for wicket and what is the best for osgi. Wicket >> can become THE webframework for osgi. As long as we do not commit to the >> goal of making wicket a first class osgi framework (but rather work in >> pax-wicket/wicket stuff) people will always have the feeling that there are >> only minor interests into supporting osgi and eg move on to vaadin. IMHO >> this could not be the goal of such a great framework as wicket. >> >> OK back to the main topic of this thread. I understand that wicket 1.5 is >> already on its way and that you do not want to add anything "new and >> possible dangerous" to the release. On the other hand i've collected tons of >> experience in the past half year developing pax-wicket. As a karaf pmc and >> technical architect of various other open and closed source osgi i've >> collected enough experience to be sure that we can also introduce osgi >> support in e.g 1.5.1. There will be extensions to the manifest.mf, >> activators, bundle and service listeners. Also changes to the class loading >> at various places, but I promise that none of those changes will effect >> wicket runtime in a j2ee server. If this is not the idea we can also start >> adding osgi support from the first 1.6.0-SNAPSHOT packages. >> >> I really want to do this in a public non-intrusive way presenting the >> possible options we have per move giving you the option to add all concerns >> you have. >> >> From this point of view, if you want users to "reference" only wicket-core >> option two is the way to go. In case you want them to reference everything >> option one is the one to go. If you want to provide an all package anyhow 3 >> is the right one. Depending on this we can provide an implementation in a >> fork on github and further discuss advantages/disadvantages. WDYT? >> >> Kind regards, Andreas >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com >
