Restructure Packaging for OSGi

[pieber]

Hey Guys,

While we're still in RC phase we might want to consider the following point:
Packaging

Wicket comes in with three core artifacts:

<dependency>
    <groupId>org.apache.wicket</groupId>
    <artifactId>wicket-core</artifactId>
    <version>1.5-RC5.1</version></dependency>

<dependency>
    <groupId>org.apache.wicket</groupId>
    <artifactId>wicket-util</artifactId>
    <version>1.5-RC5.1</version></dependency>

<dependency>
    <groupId>org.apache.wicket</groupId>
    <artifactId>wicket-request</artifactId>
    <version>1.5-RC5.1</version></dependency>

All three of them are required. Currently I think it is assumed best
practice to include wicket-core into your maven project and let it resolve
util and request automatically. Thinking about the OSGi integration into
wicket this leaves us with three options:

   1. OSGifying all three of them using split-package.
   2. Embed util and request into wicket-core.
   3. Provide e.g. "apache-wicket" which repacks core, util and request into
   one package.

@1: Split-Package is a real pain in OSGi. While it might work there are
always some hidden risks using this technique and I would really like to
avoid it at any chance
@2: This one would be an option since it will be the less interrupting one.
@3: This one might be the most clean solution. Among the apache-wicket
artifactId we could distribute a bundle (which can be included/referenced in
a classical J2EE env (as wicket-core before)), but could also be launched in
an OSGi environment. In addition we can also provide e.g. features.xml &
.kar packages (for Karaf) within the aritfact id, eba packages (Apache
Aries) and so on. Option three has the additional advantage that we can also
separate the OSGi code from the core code by packing and defining it in
apache-wicket.

TBH I can live with both,  @2 and @3 quite well but would slightly prefer
option 3. What does other think about this?

Please don't get me wrong. I don't want to be intrusive in any way or do
any criticism on the current way. I can live quite well with option 2 if
this is the commonly agreed solution. It's just that I want to show up the
options and possibilities we have.

I'm very interested in your feedback.

Kind regards,
Andreas

[Charles Moulliard]

Hi Andreas,

From an OSGI perspective, the approach option 3 (and also for J2EE users) is the best as it simplifies the build, release and deployment process and avoid dependencies issues.

Additional question : In which bundle will be packaged the wicket-extensions ?

Regards,

Charles

[Brian Topping]

Option 2 kind of speaks to the idea that Martijn just had about users being less inconvenienced by fewer artifacts and it would save a lot of hassle WRT these packages split across multiple artifacts.  

We were kind of wondering out loud the other day why the packages are split across artifacts like that.  I thought I had heard the reason but was not sure I could recite it exactly.  Can anyone share?

My non-binding vote is for @2.

On Aug 15, 2011, at 10:56 PM, Andreas Pieber wrote:

> Hey Guys,
>
> While we're still in RC phase we might want to consider the following point:
> Packaging
>
> Wicket comes in with three core artifacts:
>
> <dependency>
>    <groupId>org.apache.wicket</groupId>
>    <artifactId>wicket-core</artifactId>
>    <version>1.5-RC5.1</version></dependency>
>
> <dependency>
>    <groupId>org.apache.wicket</groupId>
>    <artifactId>wicket-util</artifactId>
>    <version>1.5-RC5.1</version></dependency>
>
> <dependency>
>    <groupId>org.apache.wicket</groupId>
>    <artifactId>wicket-request</artifactId>
>    <version>1.5-RC5.1</version></dependency>
>
> All three of them are required. Currently I think it is assumed best
> practice to include wicket-core into your maven project and let it resolve
> util and request automatically. Thinking about the OSGi integration into
> wicket this leaves us with three options:
>
>   1. OSGifying all three of them using split-package.
>   2. Embed util and request into wicket-core.
>   3. Provide e.g. "apache-wicket" which repacks core, util and request into
>   one package.
>
> @1: Split-Package is a real pain in OSGi. While it might work there are
> always some hidden risks using this technique and I would really like to
> avoid it at any chance
> @2: This one would be an option since it will be the less interrupting one.
> @3: This one might be the most clean solution. Among the apache-wicket
> artifactId we could distribute a bundle (which can be included/referenced in
> a classical J2EE env (as wicket-core before)), but could also be launched in
> an OSGi environment. In addition we can also provide e.g. features.xml &
> .kar packages (for Karaf) within the aritfact id, eba packages (Apache
> Aries) and so on. Option three has the additional advantage that we can also
> separate the OSGi code from the core code by packing and defining it in
> apache-wicket.
>
> TBH I can live with both,  @2 and @3 quite well but would slightly prefer
> option 3. What does other think about this?
>
> Please don't get me wrong. I don't want to be intrusive in any way or do
> any criticism on the current way. I can live quite well with option 2 if
> this is the commonly agreed solution. It's just that I want to show up the
> options and possibilities we have.
>
> I'm very interested in your feedback.
>
> Kind regards,
> Andreas

[Martin Grigorov-4]

Isn't option 3 the solution which we have currently in WicketStuff's
wicket-bundle-parent ?
If it is not then can you please give more details what exactly you mean.

I'd prefer the following approach for Wicket OSGi:
- use wicketstuff/wicket-bundle for OSGi deployments (wicket-bundle
merges -util, -request and -core into one .jar)
- use PAX-Wicket or wicketstuff/wicket-osgi for all glue code like
OSGiClassResolver, OSGiInjector, serialization... And this project
will depend on wicketstuff/wicket-bundle

If any changes are needed in Wicket -core, -ioc, ... then please
create tickets (or comment in WICKET-3737) and we will improve where
needed.

For Wicket 1.6 we could fix the split package problem in -util and
-request and wicket-bundle may be retired

Do you see any problems with this approach ?

-util, -request and -core were made this way to improve Wicket code
itself. Now code in -util doesn't use code from -request or -core.

On Tue, Aug 16, 2011 at 10:20 AM, Brian Topping <[hidden email]> wrote:

> Option 2 kind of speaks to the idea that Martijn just had about users being less inconvenienced by fewer artifacts and it would save a lot of hassle WRT these packages split across multiple artifacts.
>
> We were kind of wondering out loud the other day why the packages are split across artifacts like that.  I thought I had heard the reason but was not sure I could recite it exactly.  Can anyone share?
>
> My non-binding vote is for @2.
>
> On Aug 15, 2011, at 10:56 PM, Andreas Pieber wrote:
>
>> Hey Guys,
>>
>> While we're still in RC phase we might want to consider the following point:
>> Packaging
>>
>> Wicket comes in with three core artifacts:
>>
>> <dependency>
>>    <groupId>org.apache.wicket</groupId>
>>    <artifactId>wicket-core</artifactId>
>>    <version>1.5-RC5.1</version></dependency>
>>
>> <dependency>
>>    <groupId>org.apache.wicket</groupId>
>>    <artifactId>wicket-util</artifactId>
>>    <version>1.5-RC5.1</version></dependency>
>>
>> <dependency>
>>    <groupId>org.apache.wicket</groupId>
>>    <artifactId>wicket-request</artifactId>
>>    <version>1.5-RC5.1</version></dependency>
>>
>> All three of them are required. Currently I think it is assumed best
>> practice to include wicket-core into your maven project and let it resolve
>> util and request automatically. Thinking about the OSGi integration into
>> wicket this leaves us with three options:
>>
>>   1. OSGifying all three of them using split-package.
>>   2. Embed util and request into wicket-core.
>>   3. Provide e.g. "apache-wicket" which repacks core, util and request into
>>   one package.
>>
>> @1: Split-Package is a real pain in OSGi. While it might work there are
>> always some hidden risks using this technique and I would really like to
>> avoid it at any chance
>> @2: This one would be an option since it will be the less interrupting one.
>> @3: This one might be the most clean solution. Among the apache-wicket
>> artifactId we could distribute a bundle (which can be included/referenced in
>> a classical J2EE env (as wicket-core before)), but could also be launched in
>> an OSGi environment. In addition we can also provide e.g. features.xml &
>> .kar packages (for Karaf) within the aritfact id, eba packages (Apache
>> Aries) and so on. Option three has the additional advantage that we can also
>> separate the OSGi code from the core code by packing and defining it in
>> apache-wicket.
>>
>> TBH I can live with both,  @2 and @3 quite well but would slightly prefer
>> option 3. What does other think about this?
>>
>> Please don't get me wrong. I don't want to be intrusive in any way or do
>> any criticism on the current way. I can live quite well with option 2 if
>> this is the commonly agreed solution. It's just that I want to show up the
>> options and possibilities we have.
>>
>> I'm very interested in your feedback.
>>
>> Kind regards,
>> Andreas
>
>

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

[Martin Grigorov-4]

On Tue, Aug 16, 2011 at 2:12 PM, Martin Grigorov <[hidden email]> wrote:

> Isn't option 3 the solution which we have currently in WicketStuff's
> wicket-bundle-parent ?
> If it is not then can you please give more details what exactly you mean.
>
> I'd prefer the following approach for Wicket OSGi:
> - use wicketstuff/wicket-bundle for OSGi deployments (wicket-bundle
> merges -util, -request and -core into one .jar)
> - use PAX-Wicket or wicketstuff/wicket-osgi for all glue code like
> OSGiClassResolver, OSGiInjector, serialization... And this project
> will depend on wicketstuff/wicket-bundle
>
> If any changes are needed in Wicket -core, -ioc, ... then please
> create tickets (or comment in WICKET-3737) and we will improve where
> needed.
>
> For Wicket 1.6 we could fix the split package problem in -util and
> -request and wicket-bundle may be retired

And of course PAX/wicket-osgi project could be merged to Wicket distro
if we decide so.

>
> Do you see any problems with this approach ?
>
> -util, -request and -core were made this way to improve Wicket code
> itself. Now code in -util doesn't use code from -request or -core.
>
> On Tue, Aug 16, 2011 at 10:20 AM, Brian Topping <[hidden email]> wrote:
>> Option 2 kind of speaks to the idea that Martijn just had about users being less inconvenienced by fewer artifacts and it would save a lot of hassle WRT these packages split across multiple artifacts.
>>
>> We were kind of wondering out loud the other day why the packages are split across artifacts like that.  I thought I had heard the reason but was not sure I could recite it exactly.  Can anyone share?
>>
>> My non-binding vote is for @2.
>>
>> On Aug 15, 2011, at 10:56 PM, Andreas Pieber wrote:
>>
>>> Hey Guys,
>>>
>>> While we're still in RC phase we might want to consider the following point:
>>> Packaging
>>>
>>> Wicket comes in with three core artifacts:
>>>
>>> <dependency>
>>>    <groupId>org.apache.wicket</groupId>
>>>    <artifactId>wicket-core</artifactId>
>>>    <version>1.5-RC5.1</version></dependency>
>>>
>>> <dependency>
>>>    <groupId>org.apache.wicket</groupId>
>>>    <artifactId>wicket-util</artifactId>
>>>    <version>1.5-RC5.1</version></dependency>
>>>
>>> <dependency>
>>>    <groupId>org.apache.wicket</groupId>
>>>    <artifactId>wicket-request</artifactId>
>>>    <version>1.5-RC5.1</version></dependency>
>>>
>>> All three of them are required. Currently I think it is assumed best
>>> practice to include wicket-core into your maven project and let it resolve
>>> util and request automatically. Thinking about the OSGi integration into
>>> wicket this leaves us with three options:
>>>
>>>   1. OSGifying all three of them using split-package.
>>>   2. Embed util and request into wicket-core.
>>>   3. Provide e.g. "apache-wicket" which repacks core, util and request into
>>>   one package.
>>>
>>> @1: Split-Package is a real pain in OSGi. While it might work there are
>>> always some hidden risks using this technique and I would really like to
>>> avoid it at any chance
>>> @2: This one would be an option since it will be the less interrupting one.
>>> @3: This one might be the most clean solution. Among the apache-wicket
>>> artifactId we could distribute a bundle (which can be included/referenced in
>>> a classical J2EE env (as wicket-core before)), but could also be launched in
>>> an OSGi environment. In addition we can also provide e.g. features.xml &
>>> .kar packages (for Karaf) within the aritfact id, eba packages (Apache
>>> Aries) and so on. Option three has the additional advantage that we can also
>>> separate the OSGi code from the core code by packing and defining it in
>>> apache-wicket.
>>>
>>> TBH I can live with both,  @2 and @3 quite well but would slightly prefer
>>> option 3. What does other think about this?
>>>
>>> Please don't get me wrong. I don't want to be intrusive in any way or do
>>> any criticism on the current way. I can live quite well with option 2 if
>>> this is the commonly agreed solution. It's just that I want to show up the
>>> options and possibilities we have.
>>>
>>> I'm very interested in your feedback.
>>>
>>> Kind regards,
>>> Andreas
>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

[pieber]

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

[pieber]

On Aug 16, 2011 6:11 PM, "Charles Moulliard" <[hidden email]> wrote:
>
> Hi Andreas,
>
> From an OSGI perspective, the approach option 3 (and also for J2EE users)
is
> the best as it simplifies the build, release and deployment process and
> avoid dependencies issues.

I also think so.

> Additional question : In which bundle will be packaged the
wicket-extensions

They could be either in the wicket-core bundle, an own bundle or in the
bundle created by option three. All three options has there advantages and
disadvantages. IMHO this depends on the package solution. In case of option
1 or 2 wicket-core makes sense. In case of option 3 I think wicket-osgi
makes most sense.

Kind regards, Andreas

> ?
>
> Regards,
>
> Charles
>
> --
> View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Restructure-Packaging-for-OSGi-tp3746217p3746435.html
> Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.

[Martin Grigorov-4]

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 <[hidden email]> 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

[jdonnerstag]

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 <[hidden email]> 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 <[hidden email]> 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
>

[pieber]

Hey Martin,

On Tue, Aug 16, 2011 at 19:07, Martin Grigorov <[hidden email]> wrote:

> Sorry, but it is hard for me to understand what you mean in the three
> points in your first mail.
>

Absolutely no problem. I'm quite deep into the entire osgi thing. Therefore
I'm sometimes a little bit fast about some details. I present them here to
take fears, not to add them. Please feel free to ask as much as you like. I
know at least of Harald and Brian around here. Achim and Charles from the
Apache Karaf project are also registered on the list. So quite a bunch of
OSGi experts around right now :-)


> 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.
>

The problem is that the three packages use partly the same namespace. E.g.
a.b.c in util and a.b.c in core. The "plan" in osgi is that this not happen.
Still, since there are situations like this the split-package attribute had
been introduced. Using this annotation osgi imports packages from more than
one bundle (if a specific package is requested). Still this is a bit of a
pain merging different packages together. Split package looks something
like:

Bundle-SymbolicName: b
Export-Package: com.company.util;b=split;mandatory:=b

Bundle-SymbolicName: c
Export-Package: com.company.util;c=split;mandatory:=c
This get's even funnier if you have to merge a package from three bundles.
Still it is possible.


>   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.
>

Sorry for not being specific here. This is a "maven-only-thing". It is
possible to merge different bundles during the build process. OSGi in
addition allows a trick called Embedd-Dependencies. This allows you to
include other jars into a bundle and use them e.g. only internal or
re-export them if necessary. That way there will be only one wicket-core jar
including util and request. I'm not sure here. Does util and request contain
only "internal" dependencies? In that case this would be a quite interesting
solution hiding all classes from util and request from the developer.
Otherwise this could work out to be lot of work...


>   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 ?
>

None. Except for (a) that the package is in wicket and not somewhere in
Wicket-Stuff (or on OPS4J) and (b) that it will include additional packages.
The repacked bundle from wicketstuff is not use-able standalone. Additions
as done by wicket-osgi or pax-wicket need to be done to make it useful
afterwards.


> 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.
>

This has nothing to do with the OSGi container. I hope I was able to outline
the problems above. For example, in case you had org.apache.wicket.core,
o.a.w.util and o.a.w.request package structures in the three jars the first
approach would be extremly easy to implement. There are approaches out there
(like features and .kars in Apache Karaf or Applications like in Apache
Aries) that allow packaging of all those bundles in one "ueber-unit". So no
problem here. So in fact solution 1 is bit of a pain (but let this trouble
us :-)) solution 2 could be quite interesting and solution 3 is very similar
to the one on wicket-stuff; except that it includes the additional classes.


> 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've a different idea. Since we would like to get this into wicket do you
think we can maintain a fork of wicket trunk on wicket-stuff? We can merge
backward here and provide patches via JIRA created by git squash. WDYT?


> 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 <[hidden email]>
> 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-4]

On Tue, Aug 16, 2011 at 8:54 PM, Andreas Pieber <[hidden email]> wrote:

> Hey Martin,
>
> On Tue, Aug 16, 2011 at 19:07, Martin Grigorov <[hidden email]> wrote:
>
>> Sorry, but it is hard for me to understand what you mean in the three
>> points in your first mail.
>>
>
> Absolutely no problem. I'm quite deep into the entire osgi thing. Therefore
> I'm sometimes a little bit fast about some details. I present them here to
> take fears, not to add them. Please feel free to ask as much as you like. I
> know at least of Harald and Brian around here. Achim and Charles from the
> Apache Karaf project are also registered on the list. So quite a bunch of
> OSGi experts around right now :-)
>
>
>> 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.
>>
>
> The problem is that the three packages use partly the same namespace. E.g.
> a.b.c in util and a.b.c in core. The "plan" in osgi is that this not happen.
> Still, since there are situations like this the split-package attribute had
> been introduced. Using this annotation osgi imports packages from more than
> one bundle (if a specific package is requested). Still this is a bit of a
> pain merging different packages together. Split package looks something
> like:
>
> Bundle-SymbolicName: b
> Export-Package: com.company.util;b=split;mandatory:=b
>
> Bundle-SymbolicName: c
> Export-Package: com.company.util;c=split;mandatory:=c
> This get's even funnier if you have to merge a package from three bundles.
> Still it is possible.

OK. Let drop this as an option.

>
>
>>   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.
>>
>
> Sorry for not being specific here. This is a "maven-only-thing". It is
> possible to merge different bundles during the build process. OSGi in
> addition allows a trick called Embedd-Dependencies. This allows you to
> include other jars into a bundle and use them e.g. only internal or
> re-export them if necessary. That way there will be only one wicket-core jar
> including util and request. I'm not sure here. Does util and request contain
> only "internal" dependencies? In that case this would be a quite interesting
> solution hiding all classes from util and request from the developer.
> Otherwise this could work out to be lot of work...

No, both -util and -request can be used by apps/libraries/frameworks.

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.

>
>
>>   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 ?
>>
>
> None. Except for (a) that the package is in wicket and not somewhere in
> Wicket-Stuff (or on OPS4J) and (b) that it will include additional packages.
> The repacked bundle from wicketstuff is not use-able standalone. Additions
> as done by wicket-osgi or pax-wicket need to be done to make it useful
> afterwards.

In my previous mail I suggested the following: wicket-bundle will add
additional dependency on wicket-osgi and will pack it with -util,
-request and -core. This way it will produce a bundle which is
use-able in OSGi container.

>
>
>> 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.
>>
>
> This has nothing to do with the OSGi container. I hope I was able to outline
> the problems above. For example, in case you had org.apache.wicket.core,
> o.a.w.util and o.a.w.request package structures in the three jars the first
> approach would be extremly easy to implement.

This is easy to fix but we found the issue in RC builds and it was
late to fix it because it will make quite big compile breaks for the
RC with the fix.
Though it is easy to solve with "Optimize Imports"...

> There are approaches out there
> (like features and .kars in Apache Karaf or Applications like in Apache
> Aries) that allow packaging of all those bundles in one "ueber-unit". So no
> problem here. So in fact solution 1 is bit of a pain (but let this trouble
> us :-)) solution 2 could be quite interesting and solution 3 is very similar
> to the one on wicket-stuff; except that it includes the additional classes.
>
>
>> 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've a different idea. Since we would like to get this into wicket do you
> think we can maintain a fork of wicket trunk on wicket-stuff? We can merge
> backward here and provide patches via JIRA created by git squash. WDYT?

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.
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 ?!

>
>
>> 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 <[hidden email]>
>> 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

[Brian Topping]

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 <[hidden email]> 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 <[hidden email]> 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
>>
>

[Brian Topping]

On Aug 16, 2011, at 3:22 PM, Martin Grigorov wrote:

> 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.

This is *easily* solvable!!!  If we can deliver that on a branch in Github, will that help us resolve the issue?  I can get started on it immediately!

[Martin Grigorov-4]

On Tue, Aug 16, 2011 at 10:41 PM, Brian Topping <[hidden email]> wrote:

>
> On Aug 16, 2011, at 3:22 PM, Martin Grigorov wrote:
>
>> 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.
>
> This is *easily* solvable!!!  If we can deliver that on a branch in Github, will that help us resolve the issue?  I can get started on it immediately!

Please do.



--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

[pieber]

On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]> 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.

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 <[hidden email]>
> >> 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-4]

On Tue, Aug 16, 2011 at 10:54 PM, Andreas Pieber <[hidden email]> wrote:

> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]> 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 <[hidden email]>
>> >> 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

[Brian Topping]

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 <[hidden email]> wrote:
>> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]> 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 <[hidden email]>
>>>>> 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
>

[pieber]

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" <[hidden email]> 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 <[hidden email]>
wrote:
>>> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]>
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 <[hidden email]>
>>>>>> 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
>>
>

[Brian Topping]

Why is that?  There are still problems with the first three artifacts being uploaded to maven central.

On Aug 16, 2011, at 4:21 PM, Andreas Pieber wrote:

> 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" <[hidden email]> 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 <[hidden email]>
> wrote:
>>>> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]>
> 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 <[hidden email]>
>>>>>>> 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
>>>
>>

[pieber]

No, but if you can surpess two, you can also supress all three and adding a
forth only logical component putting all others together and add the
required osgi headers.

Kind regards,
Andreas

On Tue, Aug 16, 2011 at 22:30, Brian Topping <[hidden email]> wrote:

> Why is that?  There are still problems with the first three artifacts being
> uploaded to maven central.
>
> On Aug 16, 2011, at 4:21 PM, Andreas Pieber wrote:
>
> > 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" <[hidden email]> 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 <[hidden email]>
> > wrote:
> >>>> On Tue, Aug 16, 2011 at 21:22, Martin Grigorov <[hidden email]>
> > 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 <
> [hidden email]>
> >>>>>>> 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
> >>>
> >>
>
>