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
