You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Juergen Donnerstag <ju...@gmail.com> on 2011/05/01 17:20:01 UTC
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
I'm not a gradle expert which is why I had to try this and that. But
my initial tests to create the ueber jars have now been successful.
-Juergen
On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <mg...@apache.org> wrote:
> I'm interested to see how easy is to do what we weren't able to do with Maven:
> - create a new module which should:
> -- combine all the .class-es from -core, -util, -request (aka uber-jar)
> -- combine all -sources.jar from the above into one (uber-sources.jar)
> <<--- this is the reason to give up what we had in 1.5-RC1
> -- combine all -javadocs.jar from the above into one (uber-javadocs.jar)
>
>
> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
>> I played a bit with gradle recently.
>> - Transfered Wicket's build process which was fairly straight forward;
>> compile, test, install. jetty:run etc.
>> - eclipse project files generated seem to be ok
>> - maven repositories to get artifacts
>> - successfully installed a new snapshot in my local repo
>>
>> I didn't test anything beyond though, especially not our release
>> process. And I didn't look at report etc.
>>
>> -Juergen
>>
>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>> we tried to create the uber jar but it failed. maybe if we used
>>>> something like gradle we couldve done it, but switching build systems
>>>> just for this seems a little extreme.
>>>
>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>>> considering dumping it for either gradle or buildr. While I haven't
>>> looked at gradle in detail, I suspect it would make releasing Wicket a
>>> bit simpler.
>>>
>>> It wouldn't necessarily break our support for Maven, just that we now
>>> use another build system, but still deploy our artifacts to the maven
>>> repo, including pom files.
>>>
>>> Martijn
>>>
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Attila Király <ki...@gmail.com>.
You may want to look at Eike Kettner's work. A few days ago he contributed a
new wicketstuff module, named wicket-bundle, for osgi users [1] & [2].
[1] https://github.com/wicketstuff/core/pull/27
<https://github.com/wicketstuff/core/pull/27>[2]
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent
<https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent>
Attila
2011/5/7 Daniele Dellafiore <da...@dellafiore.net>
> I succeded in creating wht wicket-osgi uber-jar bundle easily, I just
> copied
> the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3,
> mvn
> package and that's it. It works nice in my osgi environments.
>
> I can publish the wicket-osgi project that create the uber-jar on a github
> repository for wicket stuff, how do I get access? I am
> https://github.com/ildella
>
> My opinion on the packages, maven/gradle debate.
>
> I do think that having packages that span over multiple modules is an
> issue,
> so the lack of maven support for this is just a consequence of that
> problem.
> I'd like to see which are the issues that people have with maven build
> system that will not have with gradle. Of course, if you can easily write a
> script to make the build custsom... that's an hack, not a feature of the
> built system, is something that's there to fix some flaw elsewhere.
>
> The issue here is that packages span over more than one jar, so we need to
> build an extra jar. That's a wicket issue, not a maven one. Maybe there are
> other better reason to change build tool, I'd like to know, but this one
> does not seem to me a reasonable one.
>
> Some good reason would be a better IDE support (an plugin to install in
> Eclipse IED, not something that generates eclipse project files, that's not
> integration, that's another hack). A real good release plugin (I do not use
> the maven one a lot but it's not that bad).
> Which are your top 3 hated maven issues?
>
>
> On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > Hibernate is also not Groovy framework but they moved to Gradle
> > because it provides better tooling for their needs.
> > Let's see how it looks first.
> >
> > On Sun, May 1, 2011 at 6:23 PM, James Carman
> > <jc...@carmanconsulting.com> wrote:
> > > I'm -1 to gradle. We don't all use it. It's not like we're a
> > groovy-based
> > > framework.
> > >
> > > On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
> > wrote:
> > >>
> > >> i guess the question then is, do we switch to gradle for 1.5? can you
> > >> check in the gradle build file so we can all take a look?
> > >>
> > >> -igor
> > >>
> > >> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
> > >> <ju...@gmail.com> wrote:
> > >> > I'm not a gradle expert which is why I had to try this and that. But
> > >> > my initial tests to create the ueber jars have now been successful.
> > >> >
> > >> > -Juergen
> > >> >
> > >> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
> > mgrigorov@apache.org>
> > > wrote:
> > >> >> I'm interested to see how easy is to do what we weren't able to do
> > with
> > > Maven:
> > >> >> - create a new module which should:
> > >> >> -- combine all the .class-es from -core, -util, -request (aka
> > uber-jar)
> > >> >> -- combine all -sources.jar from the above into one
> > (uber-sources.jar)
> > >> >> <<--- this is the reason to give up what we had in 1.5-RC1
> > >> >> -- combine all -javadocs.jar from the above into one
> > > (uber-javadocs.jar)
> > >> >>
> > >> >>
> > >> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
> > >> >> <ju...@gmail.com> wrote:
> > >> >>> I played a bit with gradle recently.
> > >> >>> - Transfered Wicket's build process which was fairly straight
> > forward;
> > >> >>> compile, test, install. jetty:run etc.
> > >> >>> - eclipse project files generated seem to be ok
> > >> >>> - maven repositories to get artifacts
> > >> >>> - successfully installed a new snapshot in my local repo
> > >> >>>
> > >> >>> I didn't test anything beyond though, especially not our release
> > >> >>> process. And I didn't look at report etc.
> > >> >>>
> > >> >>> -Juergen
> > >> >>>
> > >> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
> > >> >>> <ma...@gmail.com> wrote:
> > >> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
> > > igor.vaynberg@gmail.com> wrote:
> > >> >>>>> we tried to create the uber jar but it failed. maybe if we used
> > >> >>>>> something like gradle we couldve done it, but switching build
> > > systems
> > >> >>>>> just for this seems a little extreme.
> > >> >>>>
> > >> >>>> Not quite: I've had enough problems with Maven at $dayjob that
> I'm
> > >> >>>> considering dumping it for either gradle or buildr. While I
> haven't
> > >> >>>> looked at gradle in detail, I suspect it would make releasing
> > Wicket
> > > a
> > >> >>>> bit simpler.
> > >> >>>>
> > >> >>>> It wouldn't necessarily break our support for Maven, just that we
> > now
> > >> >>>> use another build system, but still deploy our artifacts to the
> > maven
> > >> >>>> repo, including pom files.
> > >> >>>>
> > >> >>>> Martijn
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Martin Grigorov
> > >> >> jWeekend
> > >> >> Training, Consulting, Development
> > >> >> http://jWeekend.com
> > >> >>
> > >> >
> > >
> >
> >
> >
> > --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
> >
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Sat, May 7, 2011 at 6:54 PM, Brian Topping <to...@codehaus.org> wrote:
> I'm kind of coming in on this late, but wanted to offer a few observations.
>
> Firstly, I would imagine there is more suppressed demand for OSGi in Wicket than there was total demand for portlets.
Negative. For Portlets they were ~10. Now you are the 4th user for the
last year or two mentioning OSGi in the mailing lists :-)
Well, maybe there are more but just 4 of you started experimenting with 1.5.
>Myself and few others started looking at using OSGi with Brix for purposes of plugins, which would be really helpful because the CMS could be upgraded without restarting it. I don't expect Brix to deal with packaging issues, but the whole classloader thing was a big distraction for a project that is focused on serving pages.
>
> OSGi is *sometimes* a solution in search of a problem, but evaluators sometimes consider this kind of functionality as a "safety net" to get out of situations that get created in team environments or through organic growth, and it has to be available before people can start using it. There's no way that a team with a legacy application can port their company's golden goose to Wicket 1.(x+1) just to get out of a pinch that is being caused by whatever issue is at hand, but if it exists and at least works without major risk, it will get used.
>
> But I am like many that have gotten involved too late to make a big difference here and 1.5 probably ought not be held up because some of us are just waking from our slumber. As 1.6 inevitably bootstraps, I think we should start coming together now.
I would like to ask you (OSGi users) to investigate what is needed to
be done, because as I said none of core devs use OSGi in his daily job
and at least I try to fill my spare time with technologies I like and
unfortunately OSGi is not in my list.
>
> Lastly, regarding Gradle, I'm really against any build system that publishes synthesized POMs to public repositories. The robustness of the POM that is generated is a function of the specific version of the build tool that generates them, and "versions are forever".
>
> Is it discussed anywhere why Maven is having a problem with the Wicket build?
>
>
> On May 7, 2011, at 9:19 AM, Juergen Donnerstag wrote:
>
>> The gradle build scripts produce the uber javadoc and source jar. I
>> didn't look into the pom though. From the little I know about gradle,
>> it seems to be possible (down to changing the xml).
>>
>> -Juergen
>>
>> On Sat, May 7, 2011 at 6:01 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>> generating the uber jar was easy. making sure that the uber jar has no
>>> dependencies on wicket-core,util,request in its pom was not. also,
>>> generating javadoc and source artifacts for the uber jar was hard.
>>>
>>> what we are really after here is a feature not supported by maven,
>>> which is "internal modules", we do not want these exposed to the world
>>> - just to developers, because it makes keeping an eye on dependencies
>>> between these internal modules easy. but, as far as users are
>>> concerned - they should always work with a module which is the
>>> aggregate of these.
>>>
>>> -igor
>>>
>>> On Sat, May 7, 2011 at 4:52 AM, Daniele Dellafiore
>>> <da...@dellafiore.net> wrote:
>>>> I succeded in creating wht wicket-osgi uber-jar bundle easily, I just copied
>>>> the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3, mvn
>>>> package and that's it. It works nice in my osgi environments.
>>>>
>>>> I can publish the wicket-osgi project that create the uber-jar on a github
>>>> repository for wicket stuff, how do I get access? I am
>>>> https://github.com/ildella
>>>>
>>>> My opinion on the packages, maven/gradle debate.
>>>>
>>>> I do think that having packages that span over multiple modules is an issue,
>>>> so the lack of maven support for this is just a consequence of that problem.
>>>> I'd like to see which are the issues that people have with maven build
>>>> system that will not have with gradle. Of course, if you can easily write a
>>>> script to make the build custsom... that's an hack, not a feature of the
>>>> built system, is something that's there to fix some flaw elsewhere.
>>>>
>>>> The issue here is that packages span over more than one jar, so we need to
>>>> build an extra jar. That's a wicket issue, not a maven one. Maybe there are
>>>> other better reason to change build tool, I'd like to know, but this one
>>>> does not seem to me a reasonable one.
>>>>
>>>> Some good reason would be a better IDE support (an plugin to install in
>>>> Eclipse IED, not something that generates eclipse project files, that's not
>>>> integration, that's another hack). A real good release plugin (I do not use
>>>> the maven one a lot but it's not that bad).
>>>> Which are your top 3 hated maven issues?
>>>>
>>>>
>>>> On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mg...@apache.org>wrote:
>>>>
>>>>> Hibernate is also not Groovy framework but they moved to Gradle
>>>>> because it provides better tooling for their needs.
>>>>> Let's see how it looks first.
>>>>>
>>>>> On Sun, May 1, 2011 at 6:23 PM, James Carman
>>>>> <jc...@carmanconsulting.com> wrote:
>>>>>> I'm -1 to gradle. We don't all use it. It's not like we're a
>>>>> groovy-based
>>>>>> framework.
>>>>>>
>>>>>> On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> i guess the question then is, do we switch to gradle for 1.5? can you
>>>>>>> check in the gradle build file so we can all take a look?
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
>>>>>>> <ju...@gmail.com> wrote:
>>>>>>>> I'm not a gradle expert which is why I had to try this and that. But
>>>>>>>> my initial tests to create the ueber jars have now been successful.
>>>>>>>>
>>>>>>>> -Juergen
>>>>>>>>
>>>>>>>> On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
>>>>> mgrigorov@apache.org>
>>>>>> wrote:
>>>>>>>>> I'm interested to see how easy is to do what we weren't able to do
>>>>> with
>>>>>> Maven:
>>>>>>>>> - create a new module which should:
>>>>>>>>> -- combine all the .class-es from -core, -util, -request (aka
>>>>> uber-jar)
>>>>>>>>> -- combine all -sources.jar from the above into one
>>>>> (uber-sources.jar)
>>>>>>>>> <<--- this is the reason to give up what we had in 1.5-RC1
>>>>>>>>> -- combine all -javadocs.jar from the above into one
>>>>>> (uber-javadocs.jar)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>>>>>>>>> <ju...@gmail.com> wrote:
>>>>>>>>>> I played a bit with gradle recently.
>>>>>>>>>> - Transfered Wicket's build process which was fairly straight
>>>>> forward;
>>>>>>>>>> compile, test, install. jetty:run etc.
>>>>>>>>>> - eclipse project files generated seem to be ok
>>>>>>>>>> - maven repositories to get artifacts
>>>>>>>>>> - successfully installed a new snapshot in my local repo
>>>>>>>>>>
>>>>>>>>>> I didn't test anything beyond though, especially not our release
>>>>>>>>>> process. And I didn't look at report etc.
>>>>>>>>>>
>>>>>>>>>> -Juergen
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>>>>>>>>>> <ma...@gmail.com> wrote:
>>>>>>>>>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
>>>>>> igor.vaynberg@gmail.com> wrote:
>>>>>>>>>>>> we tried to create the uber jar but it failed. maybe if we used
>>>>>>>>>>>> something like gradle we couldve done it, but switching build
>>>>>> systems
>>>>>>>>>>>> just for this seems a little extreme.
>>>>>>>>>>>
>>>>>>>>>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>>>>>>>>>>> considering dumping it for either gradle or buildr. While I haven't
>>>>>>>>>>> looked at gradle in detail, I suspect it would make releasing
>>>>> Wicket
>>>>>> a
>>>>>>>>>>> bit simpler.
>>>>>>>>>>>
>>>>>>>>>>> It wouldn't necessarily break our support for Maven, just that we
>>>>> now
>>>>>>>>>>> use another build system, but still deploy our artifacts to the
>>>>> maven
>>>>>>>>>>> repo, including pom files.
>>>>>>>>>>>
>>>>>>>>>>> Martijn
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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: [osgi] package org.apache.wicket.request exported either from core and request packages
Posted by Brian Topping <to...@codehaus.org>.
I'm kind of coming in on this late, but wanted to offer a few observations.
Firstly, I would imagine there is more suppressed demand for OSGi in Wicket than there was total demand for portlets. Myself and few others started looking at using OSGi with Brix for purposes of plugins, which would be really helpful because the CMS could be upgraded without restarting it. I don't expect Brix to deal with packaging issues, but the whole classloader thing was a big distraction for a project that is focused on serving pages.
OSGi is *sometimes* a solution in search of a problem, but evaluators sometimes consider this kind of functionality as a "safety net" to get out of situations that get created in team environments or through organic growth, and it has to be available before people can start using it. There's no way that a team with a legacy application can port their company's golden goose to Wicket 1.(x+1) just to get out of a pinch that is being caused by whatever issue is at hand, but if it exists and at least works without major risk, it will get used.
But I am like many that have gotten involved too late to make a big difference here and 1.5 probably ought not be held up because some of us are just waking from our slumber. As 1.6 inevitably bootstraps, I think we should start coming together now.
Lastly, regarding Gradle, I'm really against any build system that publishes synthesized POMs to public repositories. The robustness of the POM that is generated is a function of the specific version of the build tool that generates them, and "versions are forever".
Is it discussed anywhere why Maven is having a problem with the Wicket build?
On May 7, 2011, at 9:19 AM, Juergen Donnerstag wrote:
> The gradle build scripts produce the uber javadoc and source jar. I
> didn't look into the pom though. From the little I know about gradle,
> it seems to be possible (down to changing the xml).
>
> -Juergen
>
> On Sat, May 7, 2011 at 6:01 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>> generating the uber jar was easy. making sure that the uber jar has no
>> dependencies on wicket-core,util,request in its pom was not. also,
>> generating javadoc and source artifacts for the uber jar was hard.
>>
>> what we are really after here is a feature not supported by maven,
>> which is "internal modules", we do not want these exposed to the world
>> - just to developers, because it makes keeping an eye on dependencies
>> between these internal modules easy. but, as far as users are
>> concerned - they should always work with a module which is the
>> aggregate of these.
>>
>> -igor
>>
>> On Sat, May 7, 2011 at 4:52 AM, Daniele Dellafiore
>> <da...@dellafiore.net> wrote:
>>> I succeded in creating wht wicket-osgi uber-jar bundle easily, I just copied
>>> the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3, mvn
>>> package and that's it. It works nice in my osgi environments.
>>>
>>> I can publish the wicket-osgi project that create the uber-jar on a github
>>> repository for wicket stuff, how do I get access? I am
>>> https://github.com/ildella
>>>
>>> My opinion on the packages, maven/gradle debate.
>>>
>>> I do think that having packages that span over multiple modules is an issue,
>>> so the lack of maven support for this is just a consequence of that problem.
>>> I'd like to see which are the issues that people have with maven build
>>> system that will not have with gradle. Of course, if you can easily write a
>>> script to make the build custsom... that's an hack, not a feature of the
>>> built system, is something that's there to fix some flaw elsewhere.
>>>
>>> The issue here is that packages span over more than one jar, so we need to
>>> build an extra jar. That's a wicket issue, not a maven one. Maybe there are
>>> other better reason to change build tool, I'd like to know, but this one
>>> does not seem to me a reasonable one.
>>>
>>> Some good reason would be a better IDE support (an plugin to install in
>>> Eclipse IED, not something that generates eclipse project files, that's not
>>> integration, that's another hack). A real good release plugin (I do not use
>>> the maven one a lot but it's not that bad).
>>> Which are your top 3 hated maven issues?
>>>
>>>
>>> On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mg...@apache.org>wrote:
>>>
>>>> Hibernate is also not Groovy framework but they moved to Gradle
>>>> because it provides better tooling for their needs.
>>>> Let's see how it looks first.
>>>>
>>>> On Sun, May 1, 2011 at 6:23 PM, James Carman
>>>> <jc...@carmanconsulting.com> wrote:
>>>>> I'm -1 to gradle. We don't all use it. It's not like we're a
>>>> groovy-based
>>>>> framework.
>>>>>
>>>>> On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>> i guess the question then is, do we switch to gradle for 1.5? can you
>>>>>> check in the gradle build file so we can all take a look?
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
>>>>>> <ju...@gmail.com> wrote:
>>>>>>> I'm not a gradle expert which is why I had to try this and that. But
>>>>>>> my initial tests to create the ueber jars have now been successful.
>>>>>>>
>>>>>>> -Juergen
>>>>>>>
>>>>>>> On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
>>>> mgrigorov@apache.org>
>>>>> wrote:
>>>>>>>> I'm interested to see how easy is to do what we weren't able to do
>>>> with
>>>>> Maven:
>>>>>>>> - create a new module which should:
>>>>>>>> -- combine all the .class-es from -core, -util, -request (aka
>>>> uber-jar)
>>>>>>>> -- combine all -sources.jar from the above into one
>>>> (uber-sources.jar)
>>>>>>>> <<--- this is the reason to give up what we had in 1.5-RC1
>>>>>>>> -- combine all -javadocs.jar from the above into one
>>>>> (uber-javadocs.jar)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>>>>>>>> <ju...@gmail.com> wrote:
>>>>>>>>> I played a bit with gradle recently.
>>>>>>>>> - Transfered Wicket's build process which was fairly straight
>>>> forward;
>>>>>>>>> compile, test, install. jetty:run etc.
>>>>>>>>> - eclipse project files generated seem to be ok
>>>>>>>>> - maven repositories to get artifacts
>>>>>>>>> - successfully installed a new snapshot in my local repo
>>>>>>>>>
>>>>>>>>> I didn't test anything beyond though, especially not our release
>>>>>>>>> process. And I didn't look at report etc.
>>>>>>>>>
>>>>>>>>> -Juergen
>>>>>>>>>
>>>>>>>>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>>>>>>>>> <ma...@gmail.com> wrote:
>>>>>>>>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
>>>>> igor.vaynberg@gmail.com> wrote:
>>>>>>>>>>> we tried to create the uber jar but it failed. maybe if we used
>>>>>>>>>>> something like gradle we couldve done it, but switching build
>>>>> systems
>>>>>>>>>>> just for this seems a little extreme.
>>>>>>>>>>
>>>>>>>>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>>>>>>>>>> considering dumping it for either gradle or buildr. While I haven't
>>>>>>>>>> looked at gradle in detail, I suspect it would make releasing
>>>> Wicket
>>>>> a
>>>>>>>>>> bit simpler.
>>>>>>>>>>
>>>>>>>>>> It wouldn't necessarily break our support for Maven, just that we
>>>> now
>>>>>>>>>> use another build system, but still deploy our artifacts to the
>>>> maven
>>>>>>>>>> repo, including pom files.
>>>>>>>>>>
>>>>>>>>>> Martijn
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Martin Grigorov
>>>>>>>> jWeekend
>>>>>>>> Training, Consulting, Development
>>>>>>>> http://jWeekend.com
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>>
>>>
>>
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Juergen Donnerstag <ju...@gmail.com>.
The gradle build scripts produce the uber javadoc and source jar. I
didn't look into the pom though. From the little I know about gradle,
it seems to be possible (down to changing the xml).
-Juergen
On Sat, May 7, 2011 at 6:01 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> generating the uber jar was easy. making sure that the uber jar has no
> dependencies on wicket-core,util,request in its pom was not. also,
> generating javadoc and source artifacts for the uber jar was hard.
>
> what we are really after here is a feature not supported by maven,
> which is "internal modules", we do not want these exposed to the world
> - just to developers, because it makes keeping an eye on dependencies
> between these internal modules easy. but, as far as users are
> concerned - they should always work with a module which is the
> aggregate of these.
>
> -igor
>
> On Sat, May 7, 2011 at 4:52 AM, Daniele Dellafiore
> <da...@dellafiore.net> wrote:
>> I succeded in creating wht wicket-osgi uber-jar bundle easily, I just copied
>> the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3, mvn
>> package and that's it. It works nice in my osgi environments.
>>
>> I can publish the wicket-osgi project that create the uber-jar on a github
>> repository for wicket stuff, how do I get access? I am
>> https://github.com/ildella
>>
>> My opinion on the packages, maven/gradle debate.
>>
>> I do think that having packages that span over multiple modules is an issue,
>> so the lack of maven support for this is just a consequence of that problem.
>> I'd like to see which are the issues that people have with maven build
>> system that will not have with gradle. Of course, if you can easily write a
>> script to make the build custsom... that's an hack, not a feature of the
>> built system, is something that's there to fix some flaw elsewhere.
>>
>> The issue here is that packages span over more than one jar, so we need to
>> build an extra jar. That's a wicket issue, not a maven one. Maybe there are
>> other better reason to change build tool, I'd like to know, but this one
>> does not seem to me a reasonable one.
>>
>> Some good reason would be a better IDE support (an plugin to install in
>> Eclipse IED, not something that generates eclipse project files, that's not
>> integration, that's another hack). A real good release plugin (I do not use
>> the maven one a lot but it's not that bad).
>> Which are your top 3 hated maven issues?
>>
>>
>> On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mg...@apache.org>wrote:
>>
>>> Hibernate is also not Groovy framework but they moved to Gradle
>>> because it provides better tooling for their needs.
>>> Let's see how it looks first.
>>>
>>> On Sun, May 1, 2011 at 6:23 PM, James Carman
>>> <jc...@carmanconsulting.com> wrote:
>>> > I'm -1 to gradle. We don't all use it. It's not like we're a
>>> groovy-based
>>> > framework.
>>> >
>>> > On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
>>> wrote:
>>> >>
>>> >> i guess the question then is, do we switch to gradle for 1.5? can you
>>> >> check in the gradle build file so we can all take a look?
>>> >>
>>> >> -igor
>>> >>
>>> >> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
>>> >> <ju...@gmail.com> wrote:
>>> >> > I'm not a gradle expert which is why I had to try this and that. But
>>> >> > my initial tests to create the ueber jars have now been successful.
>>> >> >
>>> >> > -Juergen
>>> >> >
>>> >> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
>>> mgrigorov@apache.org>
>>> > wrote:
>>> >> >> I'm interested to see how easy is to do what we weren't able to do
>>> with
>>> > Maven:
>>> >> >> - create a new module which should:
>>> >> >> -- combine all the .class-es from -core, -util, -request (aka
>>> uber-jar)
>>> >> >> -- combine all -sources.jar from the above into one
>>> (uber-sources.jar)
>>> >> >> <<--- this is the reason to give up what we had in 1.5-RC1
>>> >> >> -- combine all -javadocs.jar from the above into one
>>> > (uber-javadocs.jar)
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>>> >> >> <ju...@gmail.com> wrote:
>>> >> >>> I played a bit with gradle recently.
>>> >> >>> - Transfered Wicket's build process which was fairly straight
>>> forward;
>>> >> >>> compile, test, install. jetty:run etc.
>>> >> >>> - eclipse project files generated seem to be ok
>>> >> >>> - maven repositories to get artifacts
>>> >> >>> - successfully installed a new snapshot in my local repo
>>> >> >>>
>>> >> >>> I didn't test anything beyond though, especially not our release
>>> >> >>> process. And I didn't look at report etc.
>>> >> >>>
>>> >> >>> -Juergen
>>> >> >>>
>>> >> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>>> >> >>> <ma...@gmail.com> wrote:
>>> >> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
>>> > igor.vaynberg@gmail.com> wrote:
>>> >> >>>>> we tried to create the uber jar but it failed. maybe if we used
>>> >> >>>>> something like gradle we couldve done it, but switching build
>>> > systems
>>> >> >>>>> just for this seems a little extreme.
>>> >> >>>>
>>> >> >>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>>> >> >>>> considering dumping it for either gradle or buildr. While I haven't
>>> >> >>>> looked at gradle in detail, I suspect it would make releasing
>>> Wicket
>>> > a
>>> >> >>>> bit simpler.
>>> >> >>>>
>>> >> >>>> It wouldn't necessarily break our support for Maven, just that we
>>> now
>>> >> >>>> use another build system, but still deploy our artifacts to the
>>> maven
>>> >> >>>> repo, including pom files.
>>> >> >>>>
>>> >> >>>> Martijn
>>> >> >>>>
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Martin Grigorov
>>> >> >> jWeekend
>>> >> >> Training, Consulting, Development
>>> >> >> http://jWeekend.com
>>> >> >>
>>> >> >
>>> >
>>>
>>>
>>>
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> http://jWeekend.com
>>>
>>
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Igor Vaynberg <ig...@gmail.com>.
generating the uber jar was easy. making sure that the uber jar has no
dependencies on wicket-core,util,request in its pom was not. also,
generating javadoc and source artifacts for the uber jar was hard.
what we are really after here is a feature not supported by maven,
which is "internal modules", we do not want these exposed to the world
- just to developers, because it makes keeping an eye on dependencies
between these internal modules easy. but, as far as users are
concerned - they should always work with a module which is the
aggregate of these.
-igor
On Sat, May 7, 2011 at 4:52 AM, Daniele Dellafiore
<da...@dellafiore.net> wrote:
> I succeded in creating wht wicket-osgi uber-jar bundle easily, I just copied
> the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3, mvn
> package and that's it. It works nice in my osgi environments.
>
> I can publish the wicket-osgi project that create the uber-jar on a github
> repository for wicket stuff, how do I get access? I am
> https://github.com/ildella
>
> My opinion on the packages, maven/gradle debate.
>
> I do think that having packages that span over multiple modules is an issue,
> so the lack of maven support for this is just a consequence of that problem.
> I'd like to see which are the issues that people have with maven build
> system that will not have with gradle. Of course, if you can easily write a
> script to make the build custsom... that's an hack, not a feature of the
> built system, is something that's there to fix some flaw elsewhere.
>
> The issue here is that packages span over more than one jar, so we need to
> build an extra jar. That's a wicket issue, not a maven one. Maybe there are
> other better reason to change build tool, I'd like to know, but this one
> does not seem to me a reasonable one.
>
> Some good reason would be a better IDE support (an plugin to install in
> Eclipse IED, not something that generates eclipse project files, that's not
> integration, that's another hack). A real good release plugin (I do not use
> the maven one a lot but it's not that bad).
> Which are your top 3 hated maven issues?
>
>
> On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mg...@apache.org>wrote:
>
>> Hibernate is also not Groovy framework but they moved to Gradle
>> because it provides better tooling for their needs.
>> Let's see how it looks first.
>>
>> On Sun, May 1, 2011 at 6:23 PM, James Carman
>> <jc...@carmanconsulting.com> wrote:
>> > I'm -1 to gradle. We don't all use it. It's not like we're a
>> groovy-based
>> > framework.
>> >
>> > On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
>> wrote:
>> >>
>> >> i guess the question then is, do we switch to gradle for 1.5? can you
>> >> check in the gradle build file so we can all take a look?
>> >>
>> >> -igor
>> >>
>> >> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
>> >> <ju...@gmail.com> wrote:
>> >> > I'm not a gradle expert which is why I had to try this and that. But
>> >> > my initial tests to create the ueber jars have now been successful.
>> >> >
>> >> > -Juergen
>> >> >
>> >> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
>> mgrigorov@apache.org>
>> > wrote:
>> >> >> I'm interested to see how easy is to do what we weren't able to do
>> with
>> > Maven:
>> >> >> - create a new module which should:
>> >> >> -- combine all the .class-es from -core, -util, -request (aka
>> uber-jar)
>> >> >> -- combine all -sources.jar from the above into one
>> (uber-sources.jar)
>> >> >> <<--- this is the reason to give up what we had in 1.5-RC1
>> >> >> -- combine all -javadocs.jar from the above into one
>> > (uber-javadocs.jar)
>> >> >>
>> >> >>
>> >> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>> >> >> <ju...@gmail.com> wrote:
>> >> >>> I played a bit with gradle recently.
>> >> >>> - Transfered Wicket's build process which was fairly straight
>> forward;
>> >> >>> compile, test, install. jetty:run etc.
>> >> >>> - eclipse project files generated seem to be ok
>> >> >>> - maven repositories to get artifacts
>> >> >>> - successfully installed a new snapshot in my local repo
>> >> >>>
>> >> >>> I didn't test anything beyond though, especially not our release
>> >> >>> process. And I didn't look at report etc.
>> >> >>>
>> >> >>> -Juergen
>> >> >>>
>> >> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>> >> >>> <ma...@gmail.com> wrote:
>> >> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
>> > igor.vaynberg@gmail.com> wrote:
>> >> >>>>> we tried to create the uber jar but it failed. maybe if we used
>> >> >>>>> something like gradle we couldve done it, but switching build
>> > systems
>> >> >>>>> just for this seems a little extreme.
>> >> >>>>
>> >> >>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>> >> >>>> considering dumping it for either gradle or buildr. While I haven't
>> >> >>>> looked at gradle in detail, I suspect it would make releasing
>> Wicket
>> > a
>> >> >>>> bit simpler.
>> >> >>>>
>> >> >>>> It wouldn't necessarily break our support for Maven, just that we
>> now
>> >> >>>> use another build system, but still deploy our artifacts to the
>> maven
>> >> >>>> repo, including pom files.
>> >> >>>>
>> >> >>>> Martijn
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Martin Grigorov
>> >> >> jWeekend
>> >> >> Training, Consulting, Development
>> >> >> http://jWeekend.com
>> >> >>
>> >> >
>> >
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Daniele Dellafiore <da...@dellafiore.net>.
I succeded in creating wht wicket-osgi uber-jar bundle easily, I just copied
the pom from the org.apache.wicket:1.5RC1 and changed version to 1.5RC3, mvn
package and that's it. It works nice in my osgi environments.
I can publish the wicket-osgi project that create the uber-jar on a github
repository for wicket stuff, how do I get access? I am
https://github.com/ildella
My opinion on the packages, maven/gradle debate.
I do think that having packages that span over multiple modules is an issue,
so the lack of maven support for this is just a consequence of that problem.
I'd like to see which are the issues that people have with maven build
system that will not have with gradle. Of course, if you can easily write a
script to make the build custsom... that's an hack, not a feature of the
built system, is something that's there to fix some flaw elsewhere.
The issue here is that packages span over more than one jar, so we need to
build an extra jar. That's a wicket issue, not a maven one. Maybe there are
other better reason to change build tool, I'd like to know, but this one
does not seem to me a reasonable one.
Some good reason would be a better IDE support (an plugin to install in
Eclipse IED, not something that generates eclipse project files, that's not
integration, that's another hack). A real good release plugin (I do not use
the maven one a lot but it's not that bad).
Which are your top 3 hated maven issues?
On Sun, May 1, 2011 at 6:29 PM, Martin Grigorov <mg...@apache.org>wrote:
> Hibernate is also not Groovy framework but they moved to Gradle
> because it provides better tooling for their needs.
> Let's see how it looks first.
>
> On Sun, May 1, 2011 at 6:23 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
> > I'm -1 to gradle. We don't all use it. It's not like we're a
> groovy-based
> > framework.
> >
> > On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com>
> wrote:
> >>
> >> i guess the question then is, do we switch to gradle for 1.5? can you
> >> check in the gradle build file so we can all take a look?
> >>
> >> -igor
> >>
> >> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
> >> <ju...@gmail.com> wrote:
> >> > I'm not a gradle expert which is why I had to try this and that. But
> >> > my initial tests to create the ueber jars have now been successful.
> >> >
> >> > -Juergen
> >> >
> >> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <
> mgrigorov@apache.org>
> > wrote:
> >> >> I'm interested to see how easy is to do what we weren't able to do
> with
> > Maven:
> >> >> - create a new module which should:
> >> >> -- combine all the .class-es from -core, -util, -request (aka
> uber-jar)
> >> >> -- combine all -sources.jar from the above into one
> (uber-sources.jar)
> >> >> <<--- this is the reason to give up what we had in 1.5-RC1
> >> >> -- combine all -javadocs.jar from the above into one
> > (uber-javadocs.jar)
> >> >>
> >> >>
> >> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
> >> >> <ju...@gmail.com> wrote:
> >> >>> I played a bit with gradle recently.
> >> >>> - Transfered Wicket's build process which was fairly straight
> forward;
> >> >>> compile, test, install. jetty:run etc.
> >> >>> - eclipse project files generated seem to be ok
> >> >>> - maven repositories to get artifacts
> >> >>> - successfully installed a new snapshot in my local repo
> >> >>>
> >> >>> I didn't test anything beyond though, especially not our release
> >> >>> process. And I didn't look at report etc.
> >> >>>
> >> >>> -Juergen
> >> >>>
> >> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
> >> >>> <ma...@gmail.com> wrote:
> >> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
> > igor.vaynberg@gmail.com> wrote:
> >> >>>>> we tried to create the uber jar but it failed. maybe if we used
> >> >>>>> something like gradle we couldve done it, but switching build
> > systems
> >> >>>>> just for this seems a little extreme.
> >> >>>>
> >> >>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
> >> >>>> considering dumping it for either gradle or buildr. While I haven't
> >> >>>> looked at gradle in detail, I suspect it would make releasing
> Wicket
> > a
> >> >>>> bit simpler.
> >> >>>>
> >> >>>> It wouldn't necessarily break our support for Maven, just that we
> now
> >> >>>> use another build system, but still deploy our artifacts to the
> maven
> >> >>>> repo, including pom files.
> >> >>>>
> >> >>>> Martijn
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Martin Grigorov
> >> >> jWeekend
> >> >> Training, Consulting, Development
> >> >> http://jWeekend.com
> >> >>
> >> >
> >
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Martin Grigorov <mg...@apache.org>.
Hibernate is also not Groovy framework but they moved to Gradle
because it provides better tooling for their needs.
Let's see how it looks first.
On Sun, May 1, 2011 at 6:23 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> I'm -1 to gradle. We don't all use it. It's not like we're a groovy-based
> framework.
>
> On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>>
>> i guess the question then is, do we switch to gradle for 1.5? can you
>> check in the gradle build file so we can all take a look?
>>
>> -igor
>>
>> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>> > I'm not a gradle expert which is why I had to try this and that. But
>> > my initial tests to create the ueber jars have now been successful.
>> >
>> > -Juergen
>> >
>> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>> >> I'm interested to see how easy is to do what we weren't able to do with
> Maven:
>> >> - create a new module which should:
>> >> -- combine all the .class-es from -core, -util, -request (aka uber-jar)
>> >> -- combine all -sources.jar from the above into one (uber-sources.jar)
>> >> <<--- this is the reason to give up what we had in 1.5-RC1
>> >> -- combine all -javadocs.jar from the above into one
> (uber-javadocs.jar)
>> >>
>> >>
>> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>> >> <ju...@gmail.com> wrote:
>> >>> I played a bit with gradle recently.
>> >>> - Transfered Wicket's build process which was fairly straight forward;
>> >>> compile, test, install. jetty:run etc.
>> >>> - eclipse project files generated seem to be ok
>> >>> - maven repositories to get artifacts
>> >>> - successfully installed a new snapshot in my local repo
>> >>>
>> >>> I didn't test anything beyond though, especially not our release
>> >>> process. And I didn't look at report etc.
>> >>>
>> >>> -Juergen
>> >>>
>> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>> >>> <ma...@gmail.com> wrote:
>> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
> igor.vaynberg@gmail.com> wrote:
>> >>>>> we tried to create the uber jar but it failed. maybe if we used
>> >>>>> something like gradle we couldve done it, but switching build
> systems
>> >>>>> just for this seems a little extreme.
>> >>>>
>> >>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>> >>>> considering dumping it for either gradle or buildr. While I haven't
>> >>>> looked at gradle in detail, I suspect it would make releasing Wicket
> a
>> >>>> bit simpler.
>> >>>>
>> >>>> It wouldn't necessarily break our support for Maven, just that we now
>> >>>> use another build system, but still deploy our artifacts to the maven
>> >>>> repo, including pom files.
>> >>>>
>> >>>> Martijn
>> >>>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Martin Grigorov
>> >> jWeekend
>> >> Training, Consulting, Development
>> >> http://jWeekend.com
>> >>
>> >
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by James Carman <jc...@carmanconsulting.com>.
I'm -1 to gradle. We don't all use it. It's not like we're a groovy-based
framework.
On May 1, 2011 12:07 PM, "Igor Vaynberg" <ig...@gmail.com> wrote:
>
> i guess the question then is, do we switch to gradle for 1.5? can you
> check in the gradle build file so we can all take a look?
>
> -igor
>
> On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
> <ju...@gmail.com> wrote:
> > I'm not a gradle expert which is why I had to try this and that. But
> > my initial tests to create the ueber jars have now been successful.
> >
> > -Juergen
> >
> > On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <mg...@apache.org>
wrote:
> >> I'm interested to see how easy is to do what we weren't able to do with
Maven:
> >> - create a new module which should:
> >> -- combine all the .class-es from -core, -util, -request (aka uber-jar)
> >> -- combine all -sources.jar from the above into one (uber-sources.jar)
> >> <<--- this is the reason to give up what we had in 1.5-RC1
> >> -- combine all -javadocs.jar from the above into one
(uber-javadocs.jar)
> >>
> >>
> >> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
> >> <ju...@gmail.com> wrote:
> >>> I played a bit with gradle recently.
> >>> - Transfered Wicket's build process which was fairly straight forward;
> >>> compile, test, install. jetty:run etc.
> >>> - eclipse project files generated seem to be ok
> >>> - maven repositories to get artifacts
> >>> - successfully installed a new snapshot in my local repo
> >>>
> >>> I didn't test anything beyond though, especially not our release
> >>> process. And I didn't look at report etc.
> >>>
> >>> -Juergen
> >>>
> >>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
> >>> <ma...@gmail.com> wrote:
> >>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <
igor.vaynberg@gmail.com> wrote:
> >>>>> we tried to create the uber jar but it failed. maybe if we used
> >>>>> something like gradle we couldve done it, but switching build
systems
> >>>>> just for this seems a little extreme.
> >>>>
> >>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
> >>>> considering dumping it for either gradle or buildr. While I haven't
> >>>> looked at gradle in detail, I suspect it would make releasing Wicket
a
> >>>> bit simpler.
> >>>>
> >>>> It wouldn't necessarily break our support for Maven, just that we now
> >>>> use another build system, but still deploy our artifacts to the maven
> >>>> repo, including pom files.
> >>>>
> >>>> Martijn
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Martin Grigorov
> >> jWeekend
> >> Training, Consulting, Development
> >> http://jWeekend.com
> >>
> >
Re: [osgi] package org.apache.wicket.request exported either from
core and request packages
Posted by Igor Vaynberg <ig...@gmail.com>.
i guess the question then is, do we switch to gradle for 1.5? can you
check in the gradle build file so we can all take a look?
-igor
On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag
<ju...@gmail.com> wrote:
> I'm not a gradle expert which is why I had to try this and that. But
> my initial tests to create the ueber jars have now been successful.
>
> -Juergen
>
> On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov <mg...@apache.org> wrote:
>> I'm interested to see how easy is to do what we weren't able to do with Maven:
>> - create a new module which should:
>> -- combine all the .class-es from -core, -util, -request (aka uber-jar)
>> -- combine all -sources.jar from the above into one (uber-sources.jar)
>> <<--- this is the reason to give up what we had in 1.5-RC1
>> -- combine all -javadocs.jar from the above into one (uber-javadocs.jar)
>>
>>
>> On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag
>> <ju...@gmail.com> wrote:
>>> I played a bit with gradle recently.
>>> - Transfered Wicket's build process which was fairly straight forward;
>>> compile, test, install. jetty:run etc.
>>> - eclipse project files generated seem to be ok
>>> - maven repositories to get artifacts
>>> - successfully installed a new snapshot in my local repo
>>>
>>> I didn't test anything beyond though, especially not our release
>>> process. And I didn't look at report etc.
>>>
>>> -Juergen
>>>
>>> On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst
>>> <ma...@gmail.com> wrote:
>>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg <ig...@gmail.com> wrote:
>>>>> we tried to create the uber jar but it failed. maybe if we used
>>>>> something like gradle we couldve done it, but switching build systems
>>>>> just for this seems a little extreme.
>>>>
>>>> Not quite: I've had enough problems with Maven at $dayjob that I'm
>>>> considering dumping it for either gradle or buildr. While I haven't
>>>> looked at gradle in detail, I suspect it would make releasing Wicket a
>>>> bit simpler.
>>>>
>>>> It wouldn't necessarily break our support for Maven, just that we now
>>>> use another build system, but still deploy our artifacts to the maven
>>>> repo, including pom files.
>>>>
>>>> Martijn
>>>>
>>>
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com
>>
>