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
