The problem > I vote for SDK, so that the dependency of the feature must be explicit in > the build.properties, rather than hidden under an EPP bundle.
Agreed - I was hoping you'd say that. :) >> * And who will maintain these? > Since this is not a lot of work, I think anyone who is interested could do > that. With my current point of view of this feature, I feel able do it. Submit a couple patches and we'll see about making you a committer then. :) > IMHO, there can only be one default. It is something to decide. I'm in > favour of latest release or maintenance build. People who would like to use > an older release or a milestone would be able to override it and manage this > by themselves. Once they start overriding, we're more or less back where we started w/ everyone setting it themselves. What's your plan for after a release, like next June when 3.6 comes out? If a build relies on the default SDK value, and it jumps ahead a year, peoples' builds may break. Is this really wise from an enterprise point of view? And if you're not comfortable using the moving-target default and set your own value... then we're back where we started. Again. :) > Ok. done at 282987 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=282987> Thanks. FWIW, I still think there's value in this idea, I'm just not sure whether the cost (potential pain, maintenance burden) to benefit (a single build.properties property need no longer be set on a per-project basis) ratio warrants it. -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio Release Engineer :: Dash Athena http://nick.divbyzero.com _______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
