Hi, On Sat, May 7, 2011 at 6:54 PM, Brian Topping <[email protected]> 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 <[email protected]> >> 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 >>> <[email protected]> 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 >>>> <[email protected]>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 >>>>> <[email protected]> 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" <[email protected]> >>>>> 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 >>>>>>> <[email protected]> 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 < >>>>> [email protected]> >>>>>> 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 >>>>>>>>> <[email protected]> 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 >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg < >>>>>> [email protected]> 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
