If we imagine that JCas classes are automatically generated from type descriptions, then I think I can see how classifiers could be made to work, because then a single source (the type descriptions) are used to generate two targets. I'm still not clear how this is done when two different source files and target class files with the same names, are supposed to be handled, though, in Maven.
uimaFIT generates its JCas sources using the Maven plugin. Ruta could also do this mostly, but may have a few types which are hand built. I suppose we could imagine a process for v3 JCas where we made the migration tool a maven plugin and then the single source would generate some temporary sources (the converted v3 sources), which would be compiled into a different classifier artifact. -Marshall On 1/15/2017 4:23 PM, Marshall Schor 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 >
