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