You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2011/08/18 21:13:16 UTC
Spliting packages/modules and deploy
Hi,
This is related to the currently running vote about OSGi problem with
split packages in sub-modules (-util, -request and -core).
Sven Meier - today, James Carman - few months ago, and few other
people doubted about the decision to split wicket.jar in sub-modules.
I believe this is the way to go and I even want to propose "a
solution" which is closely related to approach 2) in the other thread.
With approach 2) these sub-modules will be merged/shared back into one
uberjar (wicket.jar) which will be the same as in Wicket 1.4.
Additionally I suggest to set 'skip=true' setting of
maven-deploy-plugin for the sub-modules. This way they wont be
deployed in Maven repos and will be something that only Wicket devs
know and care about. The users will see only the merged wicket.jar and
the other "normal" modules like -extensions. -ioc, -spring, etc.
We already discussed this in IRC and Brian Toppings patch contain
these changes but I'd like to have more opinions before doing it.
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Spliting packages/modules and deploy
Posted by Juergen Donnerstag <ju...@gmail.com>.
I missed some of the discussions on mail list on this topic. To me it
sounds like what we were always after: separate (sub-)projects for
internal development purposes and a single wicket.jar in maven's
public repo. If finally somebody found a way to achieve this with
maven, the better.
Juergen
On Thu, Aug 18, 2011 at 9:13 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> This is related to the currently running vote about OSGi problem with
> split packages in sub-modules (-util, -request and -core).
> Sven Meier - today, James Carman - few months ago, and few other
> people doubted about the decision to split wicket.jar in sub-modules.
> I believe this is the way to go and I even want to propose "a
> solution" which is closely related to approach 2) in the other thread.
> With approach 2) these sub-modules will be merged/shared back into one
> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
> Additionally I suggest to set 'skip=true' setting of
> maven-deploy-plugin for the sub-modules. This way they wont be
> deployed in Maven repos and will be something that only Wicket devs
> know and care about. The users will see only the merged wicket.jar and
> the other "normal" modules like -extensions. -ioc, -spring, etc.
> We already discussed this in IRC and Brian Toppings patch contain
> these changes but I'd like to have more opinions before doing it.
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
Re: Spliting packages/modules and deploy
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I need more opinions in the discussion at
https://issues.apache.org/jira/browse/WICKET-3976
How we will proceed ?
On Fri, Aug 19, 2011 at 7:32 AM, Andreas Pieber <an...@gmail.com> wrote:
> OK, just to make this more interesting :-)
>
> On Thu, Aug 18, 2011 at 21:41, Martin Grigorov <mg...@apache.org> wrote:
>
>> Andreas Pieber works on a patch for approach 2).
>> -util, -request and -core will be shaded in wicket.jar
>>
>
> This one works really fine. I've used the patch I've set for discussion here
> [1]. To make sure that everything works as expected I've created a
> quickstart and use the org.apache.wicket/wicket reference instead of
> org.apache.wicket/wicket-core. In addition I've tried to start a.o.p/wicket
> bundle in Karaf with Harald's wicket-osgi project on wicketstuff. This also
> works. Various general remarks to this patch:
>
> [1] https://github.com/apache/wicket/pull/3
>
> a) I ONLY osgify org.apache.wicket/wicket for now. IMHO it doesn't make
> sense to provide e.g. org.apache.wicket/wicket-ioc osgified where we know
> that this wont work. I've planed to add the osgi manifest headers asap the
> most minimal version of wicket-osgi is up to show which artifacts actually
> run without modification. I think we should make a clear statement here
> which artifacts run in an osgi environment and which not and do not simply
> put osgi manifest headers to all of them.
>
> b) I've replaced all references to wicket-core with wicket. It is not very
> useful having o.a.w/wicket referencing -core, -util and -request
> in-transitiv to avoid clients referencing on them but then doing it directly
> via o.a.w/wicket-extension -> o.a.w/wicket-core -> ... (since this will fail
> if we do not deploy the artifacts to central :-))
>
> c) In addition I've tested the maven-deploy-plugin skip attribute by
> deploying my current wicket version here using the following in addition
> (which had been removed from the patch of cause):
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-deploy-plugin</artifactId>
> <version>2.6</version>
> <configuration>
> <altDeploymentRepository>WICKET::default::
> http://maven.openengsb.org/nexus/content/repositories/WICKET
> </altDeploymentRepository>
> </configuration>
> </plugin>
>
> I'll keep the alternative repo at [2] till the JIRA is finished to help
> validating the patch.
>
> [2] http://maven.openengsb.org/nexus/content/repositories/WICKET
>
> d) I've tested (b) in an empty ubuntu vm with the introduction example
> (pointing to (c)) activating wicket-extension. Neither of -core, -util,
> -request where in my .m2/repository folder afterwards. So this seams to
> work. I've attached the quickstart I've used. It uses the temporary maven
> repo ([2]). If you build it with an empty maven repo you'll see that no
> wicket-core, ... are in your repository afterwards. While I think I've
> killed them all it would be great if someone with a really big project using
> all wicket components can use my repo and change all occurrences of -core,
> -util and -request to o.a.w/wicket and check afterwards if there is still a
> reference left to core or util or request.
>
> Once the discussion at the pull-request is finished I'll do an git svn
> rebase; splash the changes and attach the patch to an JIRA issue.
>
> The following will come step by step ASAP the first one is approved.
>
>
>> A new module named wicket-osgi will be introduced with all OSGi
>> related impls of IClassResolver, ISerializer, etc...
>> -spring and -guice will receive some patches so they can be used in
>> OSGi environment as well
>>
>> -osgi, -spring and -guice will have Maven dependency 'org,osgi' with
>> scope 'provided' so they can be compiled. At runtime OSGi containers
>> will use header "Import-Package" to resolve the dependencies.
>>
>
> Kind regards,
> Andreas
>
>
>>
>> On Thu, Aug 18, 2011 at 10:33 PM, Igor Vaynberg <ig...@gmail.com>
>> wrote:
>> > brian's patch shades the artifacts under wicket-core instead of wicket...
>> >
>> > -igor
>> >
>> > On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> >> Hi,
>> >>
>> >> This is related to the currently running vote about OSGi problem with
>> >> split packages in sub-modules (-util, -request and -core).
>> >> Sven Meier - today, James Carman - few months ago, and few other
>> >> people doubted about the decision to split wicket.jar in sub-modules.
>> >> I believe this is the way to go and I even want to propose "a
>> >> solution" which is closely related to approach 2) in the other thread.
>> >> With approach 2) these sub-modules will be merged/shared back into one
>> >> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
>> >> Additionally I suggest to set 'skip=true' setting of
>> >> maven-deploy-plugin for the sub-modules. This way they wont be
>> >> deployed in Maven repos and will be something that only Wicket devs
>> >> know and care about. The users will see only the merged wicket.jar and
>> >> the other "normal" modules like -extensions. -ioc, -spring, etc.
>> >> We already discussed this in IRC and Brian Toppings patch contain
>> >> these changes but I'd like to have more opinions before doing it.
>> >>
>> >> --
>> >> 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
Re: Spliting packages/modules and deploy
Posted by Andreas Pieber <an...@gmail.com>.
OK, just to make this more interesting :-)
On Thu, Aug 18, 2011 at 21:41, Martin Grigorov <mg...@apache.org> wrote:
> Andreas Pieber works on a patch for approach 2).
> -util, -request and -core will be shaded in wicket.jar
>
This one works really fine. I've used the patch I've set for discussion here
[1]. To make sure that everything works as expected I've created a
quickstart and use the org.apache.wicket/wicket reference instead of
org.apache.wicket/wicket-core. In addition I've tried to start a.o.p/wicket
bundle in Karaf with Harald's wicket-osgi project on wicketstuff. This also
works. Various general remarks to this patch:
[1] https://github.com/apache/wicket/pull/3
a) I ONLY osgify org.apache.wicket/wicket for now. IMHO it doesn't make
sense to provide e.g. org.apache.wicket/wicket-ioc osgified where we know
that this wont work. I've planed to add the osgi manifest headers asap the
most minimal version of wicket-osgi is up to show which artifacts actually
run without modification. I think we should make a clear statement here
which artifacts run in an osgi environment and which not and do not simply
put osgi manifest headers to all of them.
b) I've replaced all references to wicket-core with wicket. It is not very
useful having o.a.w/wicket referencing -core, -util and -request
in-transitiv to avoid clients referencing on them but then doing it directly
via o.a.w/wicket-extension -> o.a.w/wicket-core -> ... (since this will fail
if we do not deploy the artifacts to central :-))
c) In addition I've tested the maven-deploy-plugin skip attribute by
deploying my current wicket version here using the following in addition
(which had been removed from the patch of cause):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.6</version>
<configuration>
<altDeploymentRepository>WICKET::default::
http://maven.openengsb.org/nexus/content/repositories/WICKET
</altDeploymentRepository>
</configuration>
</plugin>
I'll keep the alternative repo at [2] till the JIRA is finished to help
validating the patch.
[2] http://maven.openengsb.org/nexus/content/repositories/WICKET
d) I've tested (b) in an empty ubuntu vm with the introduction example
(pointing to (c)) activating wicket-extension. Neither of -core, -util,
-request where in my .m2/repository folder afterwards. So this seams to
work. I've attached the quickstart I've used. It uses the temporary maven
repo ([2]). If you build it with an empty maven repo you'll see that no
wicket-core, ... are in your repository afterwards. While I think I've
killed them all it would be great if someone with a really big project using
all wicket components can use my repo and change all occurrences of -core,
-util and -request to o.a.w/wicket and check afterwards if there is still a
reference left to core or util or request.
Once the discussion at the pull-request is finished I'll do an git svn
rebase; splash the changes and attach the patch to an JIRA issue.
The following will come step by step ASAP the first one is approved.
> A new module named wicket-osgi will be introduced with all OSGi
> related impls of IClassResolver, ISerializer, etc...
> -spring and -guice will receive some patches so they can be used in
> OSGi environment as well
>
> -osgi, -spring and -guice will have Maven dependency 'org,osgi' with
> scope 'provided' so they can be compiled. At runtime OSGi containers
> will use header "Import-Package" to resolve the dependencies.
>
Kind regards,
Andreas
>
> On Thu, Aug 18, 2011 at 10:33 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> > brian's patch shades the artifacts under wicket-core instead of wicket...
> >
> > -igor
> >
> > On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> >> Hi,
> >>
> >> This is related to the currently running vote about OSGi problem with
> >> split packages in sub-modules (-util, -request and -core).
> >> Sven Meier - today, James Carman - few months ago, and few other
> >> people doubted about the decision to split wicket.jar in sub-modules.
> >> I believe this is the way to go and I even want to propose "a
> >> solution" which is closely related to approach 2) in the other thread.
> >> With approach 2) these sub-modules will be merged/shared back into one
> >> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
> >> Additionally I suggest to set 'skip=true' setting of
> >> maven-deploy-plugin for the sub-modules. This way they wont be
> >> deployed in Maven repos and will be something that only Wicket devs
> >> know and care about. The users will see only the merged wicket.jar and
> >> the other "normal" modules like -extensions. -ioc, -spring, etc.
> >> We already discussed this in IRC and Brian Toppings patch contain
> >> these changes but I'd like to have more opinions before doing it.
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com
> >>
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
Re: Spliting packages/modules and deploy
Posted by Sven Meier <sv...@meiers.net>.
Sounds fine to me:
If the sub-modules are relevant for wicket devs only, then we shouldn't
bother our users with it, whether in osgi or non-osgi environments.
Sven
On 08/18/2011 09:41 PM, Martin Grigorov wrote:
> Andreas Pieber works on a patch for approach 2).
> -util, -request and -core will be shaded in wicket.jar
> A new module named wicket-osgi will be introduced with all OSGi
> related impls of IClassResolver, ISerializer, etc...
> -spring and -guice will receive some patches so they can be used in
> OSGi environment as well
>
> -osgi, -spring and -guice will have Maven dependency 'org,osgi' with
> scope 'provided' so they can be compiled. At runtime OSGi containers
> will use header "Import-Package" to resolve the dependencies.
>
> On Thu, Aug 18, 2011 at 10:33 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> brian's patch shades the artifacts under wicket-core instead of wicket...
>>
>> -igor
>>
>> On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mg...@apache.org> wrote:
>>> Hi,
>>>
>>> This is related to the currently running vote about OSGi problem with
>>> split packages in sub-modules (-util, -request and -core).
>>> Sven Meier - today, James Carman - few months ago, and few other
>>> people doubted about the decision to split wicket.jar in sub-modules.
>>> I believe this is the way to go and I even want to propose "a
>>> solution" which is closely related to approach 2) in the other thread.
>>> With approach 2) these sub-modules will be merged/shared back into one
>>> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
>>> Additionally I suggest to set 'skip=true' setting of
>>> maven-deploy-plugin for the sub-modules. This way they wont be
>>> deployed in Maven repos and will be something that only Wicket devs
>>> know and care about. The users will see only the merged wicket.jar and
>>> the other "normal" modules like -extensions. -ioc, -spring, etc.
>>> We already discussed this in IRC and Brian Toppings patch contain
>>> these changes but I'd like to have more opinions before doing it.
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>
>
>
>
Re: Spliting packages/modules and deploy
Posted by Martin Grigorov <mg...@apache.org>.
Andreas Pieber works on a patch for approach 2).
-util, -request and -core will be shaded in wicket.jar
A new module named wicket-osgi will be introduced with all OSGi
related impls of IClassResolver, ISerializer, etc...
-spring and -guice will receive some patches so they can be used in
OSGi environment as well
-osgi, -spring and -guice will have Maven dependency 'org,osgi' with
scope 'provided' so they can be compiled. At runtime OSGi containers
will use header "Import-Package" to resolve the dependencies.
On Thu, Aug 18, 2011 at 10:33 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> brian's patch shades the artifacts under wicket-core instead of wicket...
>
> -igor
>
> On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mg...@apache.org> wrote:
>> Hi,
>>
>> This is related to the currently running vote about OSGi problem with
>> split packages in sub-modules (-util, -request and -core).
>> Sven Meier - today, James Carman - few months ago, and few other
>> people doubted about the decision to split wicket.jar in sub-modules.
>> I believe this is the way to go and I even want to propose "a
>> solution" which is closely related to approach 2) in the other thread.
>> With approach 2) these sub-modules will be merged/shared back into one
>> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
>> Additionally I suggest to set 'skip=true' setting of
>> maven-deploy-plugin for the sub-modules. This way they wont be
>> deployed in Maven repos and will be something that only Wicket devs
>> know and care about. The users will see only the merged wicket.jar and
>> the other "normal" modules like -extensions. -ioc, -spring, etc.
>> We already discussed this in IRC and Brian Toppings patch contain
>> these changes but I'd like to have more opinions before doing it.
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Spliting packages/modules and deploy
Posted by Igor Vaynberg <ig...@gmail.com>.
brian's patch shades the artifacts under wicket-core instead of wicket...
-igor
On Thu, Aug 18, 2011 at 12:13 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> This is related to the currently running vote about OSGi problem with
> split packages in sub-modules (-util, -request and -core).
> Sven Meier - today, James Carman - few months ago, and few other
> people doubted about the decision to split wicket.jar in sub-modules.
> I believe this is the way to go and I even want to propose "a
> solution" which is closely related to approach 2) in the other thread.
> With approach 2) these sub-modules will be merged/shared back into one
> uberjar (wicket.jar) which will be the same as in Wicket 1.4.
> Additionally I suggest to set 'skip=true' setting of
> maven-deploy-plugin for the sub-modules. This way they wont be
> deployed in Maven repos and will be something that only Wicket devs
> know and care about. The users will see only the merged wicket.jar and
> the other "normal" modules like -extensions. -ioc, -spring, etc.
> We already discussed this in IRC and Brian Toppings patch contain
> these changes but I'd like to have more opinions before doing it.
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>