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 <igor.vaynb...@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 >> <dani...@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 <mgrigo...@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 >>>> <jcar...@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" <igor.vaynb...@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 >>>>>> <juergen.donners...@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 < >>>> mgrigo...@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 >>>>>>>> <juergen.donners...@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 >>>>>>>>> <martijn.dasho...@gmail.com> wrote: >>>>>>>>>> On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg < >>>>> igor.vaynb...@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 >>>> >>> >> >
