On 04/05/2013, at 5:00 AM, Steve Ebersole <steven.ebers...@gmail.com> wrote:
> This is really not meant as bashing, but you can't develop stuff mark, it as > incubating , elicit folks for feedback and then just say "well you should not > use this stuff" when it does not work or misses functionality. What > incentive does that give me, as a user, to ever try this stuff and for you? It's a good point. Usually when we start on new stuff, we implement the simple use cases first and build from there, supporting more use cases as we go. Often the simple use cases are good enough for most builds to start using the new feature, and to start benefiting from the new feature. If you have a Java library whose API does not have any dependencies, then the new stuff would work just fine for you - it's simpler to configure and has fewer bugs and better error handling and better documentation and so on. I think the problem here is that your use case is common enough that we haven't quite reached the "good enough for most builds" point. So, perhaps for this kind of feature we should document the major use cases we know aren't implemented yet. Another approach would be to not announce the feature until we hit the "good enough" point, but I'd rather expose new stuff early. > > > On Fri 03 May 2013 09:05:33 AM CDT, Peter Niederwieser wrote: >> Steve Ebersole-2 wrote >>> Anyway to alter that then on my end (in the build) in the interim? >> >> You could certainly post-process the publication's POM (see >> http://www.gradle.org/docs/current/dsl/org.gradle.api.publish.maven.MavenPublication.html). >> Personally, I'd consider staying on the old publication support for the time >> being, but then I haven't followed the rest of this discussion. >> >> Cheers, >> Peter >> >> >> >> >> >> -- >> View this message in context: >> http://gradle.1045684.n5.nabble.com/New-maven-publishing-featureset-tp5711110p5711271.html >> Sent from the gradle-dev mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
