I think it will be better to integrate them into a forth artifact
wicket.jar. This will make it easier to integrate wicket-osgi tomorrow :-)
On Aug 16, 2011 10:18 PM, "Brian Topping" <[email protected]> wrote:
> There are definitely a number of ways to go about it. What I am
considering at the moment is that the build will proceed normally for -util
and -request, but set the deploy plugin to not deploy for those first two.
Then -core will integrate the contents of the other two (from local
repository only) and allow the deploy plugin to operate normally.
>
> On Aug 16, 2011, at 4:05 PM, Martin Grigorov wrote:
>
>> On Tue, Aug 16, 2011 at 10:54 PM, Andreas Pieber <[email protected]>
wrote:
>>> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[email protected]>
wrote:
>>>>
>>>> Indeed it is Maven problem. We (Wicket devs) want to keep the code
>>>> clean and that's why the old wicket.jar from 1.4 has been split in
>>>> three modules. The goal is that -util classes are just utilities, they
>>>> should not know about Application, RequestCycle, Session, etc.
>>>> -request can use the classes from -util but again should not see
>>>> Application, RequestCycle, Session, etc.
>>>> The best solution for both devs and users I think would be if Maven
>>>> supported the scenario where you have several modules which depend on
>>>> each other but should not be installed/deployed in local/remote repos.
>>>> If this was/is possible then we can merge those sub-modules at install
>>>> time in wicket.jar again and everything will be the same from user
>>>> perspective. But AFAIK it is not possible to tell Maven to not
>>>> install/deploy modules.
>>>> Maybe we can solve that with a second pom.xml - one pom.xml for
>>>> developers and another for official builds.
>>>>
>>>
>>> This could be also done in one pom. Still one option would be to still
>>> deploy them AND repackage them (into e.g. wicket.jar). I think this is
the
>>> same (or at least very similar) to what Brian has in mind :-)
>>>
>>>
>>>> We have different understanding about "get into wicket" :-)
>>>> You want to put the new classes in wicket-core and I prefer to put
>>>> them in o.a.w:wicket-osgi:jar which still will be part of Wicket
>>>> distro and will be used only by users who deploy apps in OSGi
>>>> containers. So you can develop in wicketstuff/wicket-osgi and when
>>>> ready we can just adopt it in Wicket.
>>>>
>>>
>>> No we're not :-) I just want to name all options. If it is really only
the
>>> problem of repackaging we can add wicket-osgi and pack wicket-osgi,
core,
>>> request and util into one wicket.jar. This one can deploy without any
>>> problem (and although there are (optional) osgi deps to any j2ee server
AND
>>> on any osgi environment. If someone is really caring about the ten
>>> additional osgi classes never used he can still use core, util and
request;
>>> otherwise the repacked wicket.jar will also do.
>> Not sure what Brian has in mind but the idea is to not deploy -util,
>> -request and -core in Maven Cental repo.
>> Those should be something which stays in Wicket's kitchen. Maven will
>> use them to build the uber jar (wicket.jar) which will be deployed
>> with the proper OSGi headers in Maven repos and used by users.
>> Only Wicker devs will know about -util, -request, -core,
>> -whatever-we-split-later...
>>
>> The same can be achieved with CheckStyle but this is a different topic.
>>>
>>> The reason why I would like to work in a fork is NOT core util and
request.
>>> We do not have to change anything there. BUT for e.g. spring we'll have
to.
>>> And I don't think that we want to play the same game there again
(additional
>>> package and repacking). This sounds ways overpowered for about 2-3
>>> additional classes.
>>>
>>>
>>>> But I guess it is a matter of 10 files or so, so there is not big
>>>> difference.
>>>> In both cases I'd like to have some tests which will verify that OSGi
>>>> stuff still works for the next release. Maybe integration tests ?!
>>>>
>>>
>>> No discussion about this. While pax-wicket might not have the highest
>>> unit-test coverage I've about 87% coverage by integration tests.
Pax-Exam in
>>> combination with Tiny-Bundle and HTML-Unit is extremly useful such
>>> situations. So there will be enough tests that you know immediately if
any
>>> change breaks the osgi integration :-)
>>>
>>> I'm a little bit busy tomorrow morning but I'll start tomorrow evening
>>> providing first ideas in a wicket fork based on Brian's implementation.
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>
>>>>>
>>>>>
>>>>>> I cannot
>>>>>> decide that by myself. I have just a single vote.
>>>>>>
>>>>>
>>>>> Of cause; that's why we/I discuss this here in public to reach as many
>>>>> wicket devs as possible :-)
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> In that way I think the following solution might be more interesting
for
>>>>> you: use the split-package approach to osgify all three jars and add
an
>>>>> additional wicket-osgi package containing all the osgi specific code.
>>>> I've
>>>>> already taken a quick look at guice and spring and although there are
>>>> some
>>>>> additions required I think they can be included directly in those
>>>>> "side-projects". Does this sound interesting for you?
>>>>>
>>>>>
>>>>>> No matter what you decide I'll be glad to help you!
>>>>>>
>>>>>
>>>>> Thank you very much Martin!
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
