Has anyone tried maven's <runtime/> scoped dependency?
The primary requirement is not to require developers/users to download large
models (*-res projects) if they just want to use the cTAKES code.
After some tinkering, I think what the ideal solution is not to delete them
from the pom's, but rather scope the *-res dependencies to "runtime"- wanted to
ping those who may have had some experience with this- does maven still
download the runtime scoped libs if you just need the code?
Example from ctakes-core/pom.xml would be:
<dependency>
<groupId>org.apache.ctakes</groupId>
<artifactId>ctakes-core-res</artifactId>
<scope>runtime</scope>
</dependency>
> -----Original Message-----
> From: Steven Bethard [mailto:[email protected]]
> Sent: Thursday, May 09, 2013 2:46 AM
> To: [email protected]
> Subject: Re: Aren't the *-res dependencies backwards?
>
> On May 8, 2013, at 9:03 PM, "Chen, Pei" <[email protected]>
> wrote:
> > I finally got a chance to look into this again, but noticed 2 things:
> > 1) The various TypeSystem.xml files doesn't/shouldn't need to be in the
> resource/models projects. I think that was an oversight on my part last time.
>
> Yeah, I agree that The TypeSystem should be in the main project, not the -
> res project.
>
> > 2) I noticed that some of the projects have drivers or main classes which I
> assume a lot of folks are able to and plan to run pipelines directly from
> individual projects. If this is true, then I think it is actually easier to
> leave it as
> is and default to have the corresponding -res dependency in the pom.xml.
> Since it's maven controlled now, an external app can always add <exclude
> ctakes-drug-ner-res/>. This is just based on observation-- otherwise, each
> project will need to think about *-res during runtime if it's not in the
> pom.xml.
>
> I think we absolutely want each project to think about *-res. Isn't that the
> whole point of the *-res decomposition?
>
> My experience with <exclude> is that it usually comes back to bite you. For
> example, imagine that project A depends on ctakes-lvg, but excludes the -
> res dependency, and then project B depends on project A but wants ctakes-
> lvg plus the -res dependency. My experience in the past was that in
> scenarios like this, the <exclude> messed things up for me. Maybe Maven's
> gotten better about this (or maybe I know how to handle this better now),
> but my experience is that <exclude> and transitive dependencies get
> complicated very quickly.
>
> I would argue that instead, anything that actually uses the models should be
> in the -res project. That way, there's no confusion. Are you just using the
> code? Then use the regular project. Are you using models? Then use the -res
> project (which would depend on the regular project).
>
> If we assume that most people want the models, then maybe instead of
> adding "-res" to the projects that contain the models, we should add "-base"
> (or whatever) to the projects that don't contain the models?
>
> Steve
>
>
> >
> > Updated in r.1480409
> >
> >> -----Original Message-----
> >> From: Chen, Pei [mailto:[email protected]]
> >> Sent: Thursday, April 11, 2013 8:59 PM
> >> To: [email protected]
> >> Subject: RE: Aren't the *-res dependencies backwards?
> >>
> >> Steve,
> >> I think that would make sense... should be fairly straightforward
> >> and transparent change. I can take a closer look next week with a clear
> mind.
> >> ________________________________________
> >> From: Steven Bethard [[email protected]]
> >> Sent: Thursday, April 11, 2013 10:46 AM
> >> To: [email protected]
> >> Subject: Aren't the *-res dependencies backwards?
> >>
> >> On Apr 11, 2013, at 8:05 AM, "Masanz, James J."
> >> <[email protected]> wrote:
> >>>
> >>> And ctakes-drug-ner-res is listed within the Maven Dependencies for
> >> ctakes-drug-ner
> >>
> >> Shouldn't it be exactly the opposite of this? Shouldn't
> >> ctakes-drug-ner-res depend on ctakes-drug-ner? Otherwise, Maven's
> >> always going to pull in ctakes-drug-ner-res whenever you use
> >> ctakes-drug-ner. I.e. with the current setup, it's impossible to depend on
> just the code, not the models.
> >>
> >> Steve
> >
