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 designe
On 16.01.2017, at 14:50, 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-
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 approac
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 rel
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
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 fi
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, i
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/dee
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 t
Re: uimaFIT / Ruta compiled against v2 being binary compatible with v3: Yes
this works!
I wasn't thinking clearly... I've already done experiments where I ran the
migration tool to get new JCas class definitions, and then ran with previously
compiled (against v2) versions of user code.
I know ja
On 1/13/2017 2:51 PM, Richard Eckart de Castilho wrote:
> Hi Marshall,
>
>> On 13.01.2017, at 04:50, Marshall Schor wrote:
>>
>> 1) I made a version of uimaFIT and Ruta for v3, and called them by some
>> different version number.
>>
>> Having a separate version allows the builds to create separa
On 1/13/2017 2:55 PM, Richard Eckart de Castilho wrote:
> On 13.01.2017, at 15:12, Marshall Schor wrote:
>> (1) could also be managed this way - by having Jar-producing modules have
>> two
>> versions of built artifacts (for example, ruta-core-v2 and ruta-core-v3).
>>
>> When a user wants to run
On 13.01.2017, at 15:12, Marshall Schor wrote:
>
> (1) could also be managed this way - by having Jar-producing modules have two
> versions of built artifacts (for example, ruta-core-v2 and ruta-core-v3).
>
> When a user wants to run with a particular version, they would need a way to
> order t
Hi Marshall,
> On 13.01.2017, at 04:50, Marshall Schor wrote:
>
> 1) I made a version of uimaFIT and Ruta for v3, and called them by some
> different version number.
>
> Having a separate version allows the builds to create separate sets of Maven
> objects, which don't "overlay" the others.
>
I'm guessing that realistically, there will be a transition period for migration
to happen to V3 (many reasons, including the fact that new stuff may come with
new bugs that get fixed over time...).
Here's some thinking about how to **not** have two versions of dependent
big-projects like uimaFIT
Hi,
I was naively hoping that we do not need to maintain/develop two
versions of, e.g., Ruta. In my opinion, this is really painful in SVN
compared to git or mercurial.
I assume the changes in the POM are not so problematic at all, maybe? A
user could set the Java-level to 8 and add a dependency
Very since :-)
I'll also bet that the CAS creation is faster? There are no ThreadLocals
yet in the Ruta tests.
Best,
Peter
Am 13.01.2017 um 04:56 schrieb Marshall Schor:
> An interesting comparison: The Ruta-core tests, for 2.5.0, run (on my laptop
> develop machine) in 48 seconds. If I sw
An interesting comparison: The Ruta-core tests, for 2.5.0, run (on my laptop
develop machine) in 48 seconds. If I switch the Java to 8, it runs in 40
seconds. If I switch to Uima v3, it runs in about 23 seconds :-).
This amount of speedup is perhaps unusual; I haven't really analyzed what's
cont
I'm wondering how to do the version management for v3 style components. Here's
what I did for testing:
1) I made a version of uimaFIT and Ruta for v3, and called them by some
different version number. For instance, for uimaFIT, I started with
2.3.0-SNAPSHOT (trunk) and made a 2.3.0.3-SNAPSHOT ve
19 matches
Mail list logo
