Re: [The Java Posse] Any coverage of JavaOne?
What do you mean no tweets?! The keynote did generate quite a few of them, do you follow @javaoneconf? You could also try https://twitter.com/search?q=javaone Hope this helps ;-) -- You received this message because you are subscribed to the Google Groups Java Posse group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
Re: [The Java Posse] Podcast suggestions?
On Mon, 29 Sep 2014 04:33:07 +0200, Cédric Beust ♔ ced...@beust.com wrote: My feelings exactly. Every time a new build system comes out, I get excited, I try it and I realize that while it does fix a few things that don't work very well in Maven, Maven still wins overall in usability, productivity, tooling and general support. Amen. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it -- You received this message because you are subscribed to the Google Groups Java Posse group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
Re: [The Java Posse] Podcast suggestions?
On Mon, 29 Sep 2014 04:45:47 +0200, clay claytonw...@gmail.com wrote: - Declarative when you want it, imperative logic when you need it. I've heard people say Maven forces you to be declarative, which is silly. It depends. When you have heterogeneous groups where you have to enforce some order, declarative is better because you can force people to stick with a standard way to do things. - Multi-project builds are handled better. Gradle's approach of allowing everything in two files at the root (build.gradle/settings.gradle) is better than having pom.xml files scattered throughout the tree. Really most of my pom.xml files in modules just contain coordinates and inherit everything from the master pom. BTW in some projects that I booted and how I help in maintenance, I constantly find people adding useless stuff in pom.xml, that should be inherited instead. Usually it can just be deleted. I can only figure out the mess that they'd do if imperative stuff was allowed. It really depends on the kind of team you have. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it -- You received this message because you are subscribed to the Google Groups Java Posse group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
Re: [The Java Posse] Podcast suggestions?
On 29 Sep 2014, at 15:45, clay wrote: - Way more concise. Gradle has a much cleaner syntax and doesn't require mountains of XML for everything. Each library dependency in a typical Maven pom often uses five lines of XML which is silly. Gradle and SBT have a much leaner syntax. I've converted Maven builds to Gradle and while still using plenty of comments and white space and not intentionally trying to write terse builds, the Gradle build is often an order of magnitude smaller. Like 5-8 times smaller. Yes - Gradle may be far more concise, and can be more readable - I find it's more the ecosystem of plugins, and other tool integration to be more important. Add to that - ivy ( and derivatives ) are not 100% compatible with Maven ( i.e. timestamped SNAPSHOTs for a big one ). One my biggest issues with Maven is now solved since we (Richard Vowles and myself) took over the grossly broken, unsupported, but well-intentioned tiles-maven-plugin [1] which gives us mixin style composition of Maven concerns. Being able to refactor those common things makes our build files amazingly small. i.e. I declare a set of tiles for osgiapi, codestandards, karaffeature and everything for our standard checkstyle/enforcer rules come in, standard setup for an OSGi based API package gets configured, and support for Apache Karaf etc. These can be added at will, without horrible nested parents. Works remarkably well. [1] https://github.com/repaint-io/maven-tiles -- You received this message because you are subscribed to the Google Groups Java Posse group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
Re: [The Java Posse] Podcast suggestions?
On Monday, September 29, 2014 2:30:38 AM UTC-5, fabrizio.giudici wrote: It depends. When you have heterogeneous groups where you have to enforce some order, declarative is better because you can force people to stick with a standard way to do things. Maven gives a very superficial illusion of forcing declarative builds. However, it is common to see imperative logic in Maven builds in the form of ant tasks or plugins. Some builds really do justify imperative script logic, Gradle just supports this with an actual programming language. If you have a standard build, declarative build definitions are great. Gradle and SBT really don't stop that. In fact, they make simple declarative builds much more concise than Maven's mountains of XML. Maven is designed with fixed build tasks and a fixed pre-defined lifecycle. Many projects have genuine need for custom build steps. Maven expects you to rig your custom build steps into the predefined steps. Gradle lets you define new tasks and task dependencies as you need them. -- You received this message because you are subscribed to the Google Groups Java Posse group. To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
