Hi,
if there is no obvious suitable/easy solution, then we should maybe step back a bit again. Do we really need v2 and v3 compatible releases of uimaFIT and ruta? (There could potentially also be some problems with the eclispe plugin dependencies) In case of Ruta, there could be a 3.0.0 release with the dependency to uimaj 3.0.0 and requiring Java 8. Do you think that there will be a requirement from users to have an additional ruta version containing new features (from 3.0.0) but be compatible with uima 2.x? Or the other way around? This is more likely for uimaj itself. Let me mention that I do not recall any maintenance release for any previous minor releases (also not for the switch to Java 7). Probably that won't happen too often. I have the feeling that we try to solve a problem that maybe does not occur. If we do not provide compatible versions for v2 in future, we still can do it if it is really necessary by cherry-picking the required changes and work with branches even if this is annoying in SVN. I do not know, but maybe it's less work if we postpone it. I personally do not have a bad feeling if we force ruta users to upgrade to uima 3.x Best, Peter Am 16.01.2017 um 08:42 schrieb Richard Eckart de Castilho: > 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
