I thought of classifiers, but I think classifiers work for producing multiple artifacts from one set of "sources".
For instance, using classifiers would apply if we had a single source for the JCas objects, but produced alternative Jars for these. I think we have a slightly different situation, in that we have different sources as well. I suppose, with enough maven customization, we could have these in the same project. I'm thinking we'd have to override the convention of source directories and class directories, something like: proj-name src main java org/apache/uima etc... main2 java org/apache/uima etc. and similar things for the compiled class files. The alternative I think is to have two different JCasGen artifact "projects" as part of Ruta / uimaFIT; this feels like a more "natural" maven fit. I'm guessing (hoping) that whatever mechanism people use to automatically "pick" the right classifier dependency could be used with this approach too. -Marshall On 1/15/2017 2:16 PM, Richard Eckart de Castilho wrote: > 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 >