I googled maven convention two jars classifier, and the top hit was: http://blog.sonatype.com/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/
which basically says this breaks "a core convention of Maven, and when you do this, you are on your own. Tools that have been designed to work with Maven won't help you." A second search hit describe how to create a 2nd JAR that includes some classes, not others. Subsequent search hits seem to also be about creating additional Jars that filter some classes. Haven't found any that address having multiple sets of /target/classes/ directories. Looking at the maven compiler plugin, there isn't a configuration option for changing where the output goes. Googling how to change the compiler destination directory gives http://stackoverflow.com/questions/11141529/maven-compiler-plugin-how-to-change-the-classes-destination-directory with the comments: Maven deliberately makes such monstrosities hard. The best answer is to change your requirement and Make separate projects out of it. Wrong way. Not the maven way. Keep you finger off maven. So, still looking for ideas re: a good way to do multiple versions of the same sources as classifiers. -Marshall On 1/16/2017 8:50 AM, Marshall Schor wrote: > 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 >
