I'm fine with either approach. I suspect different projects may find each approach, or even a 3rd approach (e.g., Peter's idea of just migrating at some point), best for their project. I would hope to include a short chapter in the uv3-guide describing a bit of a cookbook for each of these approaches :-).
One thing I don't yet understand: if we have two "generated-sources" in target/, each defining identically named JCas classes, the compile targets for these can't both be target/classes/. Anyone know the Maven convention for handling this so two different JARs can be built? -Marshall On 1/16/2017 2:42 AM, Richard Eckart de Castilho wrote: > Speaking for uimaFIT and thinking in a further step also of DKPro Core which > has more than 19 modules that also include type systems, I tend to think that > the > JCas classes are only an aspect of a module which may also contain other code. > For instance "example" code. > > In particular for cases where the JCas classes are generated it seems it > should > be doable with reasonable effort to package up only the generated classes in > "classified sub-jars". For customized JCas classes, it may be slightly more > effort. > > So in case of the uimaFIT examples, the main example code would be in the main > artifact. Then the generated JCas classes would be in two different > "classified sub-jars". > > proj-name > src > main > java > org/apache/uima/fit/examples/RoomAnnotator etc... > resources > desc/type/typesystem.xml > target > generated-sources > jcasgen-v2 > org/apache/uima/types/ etc... > jcasgen-v3 > org/apache/uima/types/ etc... > > I fear that following your approach in a project like DKPro Core which has a > modular type system would significantly increase the number of Maven modules. > > Cheers, > > -- Richard > >> On 15.01.2017, at 22:23, Marshall Schor <m...@schor.com> wrote: >> >> 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
