You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've used an internally developed gradle plugin that leverages the ice-ant task for a while now, however we've been looking at moving to use the official ice-builder-gradle plugin instead.
We've hit a minor snag with the currently implementation, however - namely that the plugin only supports a single, "global" output directory for generated source files ("slice.output"), and
doesn't allow setting it per-"Ice sourceSet". The plugin also implicitly binds the "slice.output" to the input of the "project.sourceSets.main.java" sourceSet, which may not be what
you want to do.
I understand that this is an early version of the plugin, but I wonder if I may be so bold as to suggest a slightly different alternative to the "sourceSet" organisation
based on our experience with our internally developed plugin?
Our internally developed plugin is based on the mechanism used by the standard ANTLR gradle plugin. It extends the standard gradle sourceSet to allow you to do the following:
The advantage of this approach is that it ties the appropriate generated slice2java code to the appropriate java sourceSet automatically. The sourceSet names "main" and "test" are just
convention, but otherwise arbitrary, allowing extensions and other kinds of configurations to be managed by the end-user. Finally, this approach follows the convention used by the
standard gradle plugins - so the end user won't be required to learn a new way of doing things, and will "just work" with minimal configuration.
I'm yet to find a disadvantage with this approach - with a provisio: we are currently only using gradle to manage our java builds. I'm not sure how it fares outside of this use-case...
Hi there!
We've used an internally developed gradle plugin that leverages the ice-ant task for a while now, however we've been looking at moving to use the official ice-builder-gradle plugin instead.
We've hit a minor snag with the currently implementation, however - namely that the plugin only supports a single, "global" output directory for generated source files ("slice.output"), and
doesn't allow setting it per-"Ice sourceSet". The plugin also implicitly binds the "slice.output" to the input of the "project.sourceSets.main.java" sourceSet, which may not be what
you want to do.
I understand that this is an early version of the plugin, but I wonder if I may be so bold as to suggest a slightly different alternative to the "sourceSet" organisation
based on our experience with our internally developed plugin?
Our internally developed plugin is based on the mechanism used by the standard ANTLR gradle plugin. It extends the standard gradle sourceSet to allow you to do the following:
The advantage of this approach is that it ties the appropriate generated slice2java code to the appropriate java sourceSet automatically. The sourceSet names "main" and "test" are just
convention, but otherwise arbitrary, allowing extensions and other kinds of configurations to be managed by the end-user. Finally, this approach follows the convention used by the
standard gradle plugins - so the end user won't be required to learn a new way of doing things, and will "just work" with minimal configuration.
I'm yet to find a disadvantage with this approach - with a provisio: we are currently only using gradle to manage our java builds. I'm not sure how it fares outside of this use-case...
Thanks,
Tim.
Originally reported by Tim Patterson on the forums:
https://forums.zeroc.com/discussion/45846/support-for-multiple-output-directories-and-source-sets-with-ice-builder-gradle
The text was updated successfully, but these errors were encountered: