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
>
