I think the situation that we have here is similar to that of some Java JNI API that needs to depend on different platform-specific JARs containing different native libraries (e.g. for Windows, OS X, Linux, etc.). Maybe we can take such a setup and adapt it for us.
E.g. cf: https://github.com/deeplearning4j/nd4j/blob/master/nd4j-backends/nd4j-backend-impls/pom.xml They seem to generate multiple JARs from a single project under the same artifactId but with different classifiers, e.g. nd4j-native (cross-platform part) nd4j-native - classifier: macosx-x86_64 (platform-specific part) That seems to be done be running the Maven JAR plugin multiple times with different sets of excludes. So for our case, I could imagine something like uimafit-examples (the examples code proper) uimafit-examples - classifier: jcas-v2 (UIMA v2 part) uimafit-examples - classifier: jcas-v3 (UIMA v3 part) And we would use e.g. some Maven property to control which of these the primary uimafit-examples would depend on. We standardize that property name, so that it works cross project, e.g. for uimaFIT and Ruta at the same time. I think such an approach may help avoiding that people end up with v2 and v3 JCas artifacts in their dependencies at the same time. Cheers, -- Richard > On 15.01.2017, at 15:47, Marshall Schor <m...@schor.com> wrote: > > A thought for a solution: > > Given that v2 versions of Ruta and uimaFIT should work with v3 at the binary > compatibility level, here's a thought on how to package things so that a > single > "trunk" for these projects can support both v2 and v3. > > v3 has different JCasGen classes. Imagine a reworking of these projects so > that > there's a separate jar-style artifact which has just the JCasGen classes. > Following Maven conventions, these would be put into its own "pom" project. > But > there would be two of these, with maven project names like, for instance: > ruta-jcasgen-uv2 and ruta-jcasgen-uv3. > > The main project would have a dependency on xxx-v2, as it is built using Java > 7 > and uima v2 (to remain compatible with current users). > > The submodule structure of the top level project would build both. The xxx-v3 > would override Java to be Java 8 and would depend on uima v3. > > The xxx-v3 would make use of some of the xxx-v2 "tests" (if this can be done - > not sure.) e.g. ruta-core, using v3. > > If something like this could be made to work, it would allow keeping single > versions of trunk for uimaFIT/Ruta/ etc., while producing Maven artifacts that > deployments and/or other projects could depend on, with a choice of uv2 or > uv3. > > -Marshall
