I see, so it's nothing to do with functionality of encapsulation (there's *never* a time when -util or -request would be used without -core)? If it were raised on the Maven or any OSGi mailing lists, I'm very confident that it would be rejected as an improvement!
It's a little surprising that with all the scrutiny of the license header improvements that changes such as these would need to be policed by creating a contrived module structure. Or do new contributors just have to jump over a much higher bar than existing ones? I'm *not* trolling here, I'm just trying to understand what's in play. I analytically thought Apache was based on meritocracy. By that definition, I am here as a "volunteer that wants to help" and focused on all aspects of "The Apache Way", as are the others who are trying to help Wicket be a premiere rendering platform for users of OSGi. I have a *lot* invested in Wicket, and as the most active current maintainer of Brix, so there's a lot in play to getting this right. Most recently on Brix, I did the majority of the work to get Brix moved to Wicket 1.5 and am focused on getting Brix plugins to be OSGi based, so they can be swapped at runtime like all good CMSs do today. Specific to the example, the license patch improves the code base, I've signed the CLA, and another PMC was reported to be working on the same thing before going on sabbatical. So rather than being "make work", it is an honest and current effort to adhere to the principles and contribute and maintain an improvement that had not been finished. And rather than bang on the door for commit privileges, I (and others!) are merely standing at the door with the first of many offerings, doing our best to educate and inform, and hoping that the community will recognize their value and let us give. I truly hope that efforts with this kind of adherence to the principles that make Apache great as well as dedication to the Wicket ecosystem are not ignored. best, Brian On Aug 16, 2011, at 1:34 PM, Juergen Donnerstag wrote: > 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 >> >
