ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bleeker, Troy C." <Bleeker.T...@mayo.edu>
Subject RE: cTAKES uber jar distribution
Date Thu, 11 Oct 2012 21:21:47 GMT
> Could you clarify? what types of user scenarios?  Not sure if we'll really be able to
support " ALL user scenarios"...

The scenarios were the 4 use cases I started with. Like you say, we can't document or support
every flavor of dev env out there etc. To hone it down let me try to combine what the 3 of
us said. Here are the 4 use cases (attempting not to label to avoid preconceptions).

1) A "user" (researcher but non-programmer) wants value from cTAKES with no compiles, no dev
env, just simple download/install/use.
2) A programmer new to cTAKES wants to take the whole, as quickly as possible, into some kind
of dev env, hopes not to have to deal with any dependency or build issues (given a stable
release) and invoke the APIs. Kick the tires is the notion.
3) A programmer uses cTAKES mostly as a black-box. They take cTAKES as a whole, perhaps minimal
changes, include everything. Although dictionaries could be replaced if they desire.
4) An experienced cTAKES developer - mash cTAKES into any form they want, change it, possibly
contribute to Apache. May redistribute according to the license.

For 1) we really need to wait for a GUI of some kind, but it sounds like we will/want to support
this use case in the future.
For 2), 3), & 4) there is a programmer involved and therefore those could boil down to
which IDEs do we document. Sounds like you'd say:
● Command line    (BTW, I've seen the mvn commands tossed about. Will Maven be required
for command line too?)
● Eclipse + Maven
● All others must extrapolate from above

However, which IDEs we document does not help on things like the need for an uber JAR, ability
to use Eclipse Run As..., shipping dictionaries or not, and so on. So, do the three programmer
use cases above sum up what is likely to be encountered or are there others? Do these need
edits?

Thanks
Troy

-----Original Message-----> Do we support all kinds of dev environments?

I suggest we start with command line and with Eclipse + maven.

> Would an uber jar support the 2) and 3)?

I think so.

> Do we want to try to support all the user scenarios we come up with or 
> only certain ones?

Again, I suggest we start with command line and with Eclipse + maven.

> With only the UIMA CPE GUI, did we ever really support a non-programmer user?

No, at least not for anything more than demonstration of what cTAKES is capable of (where
someone could look at the CVD GUI and see what annotations were discovered for single files,
without having to understand any XML)

> Will the new GUI in the sandbox be such support?

That's what it is supposed to be, as I understand it.

-- James

-----Original Message-----
From: ctakes-dev-return-583-Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-583-Bleeker.Troy=mayo.edu@incubator.apache.org]
On Behalf Of Chen, Pei
Sent: Wednesday, October 10, 2012 4:36 PM
To: ctakes-dev@incubator.apache.org
Subject: RE: cTAKES uber jar distribution

> Do we support all kinds of dev environments? Only a few? Is there a 
> priority order, like Eclipse only, Eclipse plus Maven, command line, 
> others. (Current doc recommends Eclipse but also documents command 
> line. For anything else the programmer is expected to extrapolate.) Do 
> we require a developer to have Maven to build cTAKES?

At a bare minimum, I think absolutely need to be able to compile, package, deploy via command
line as this is the only way we can (semi-)automate builds, tests, release management, continuous
integration etc, internally.
+1 On Maven and Eclipse IDE for Developers.  Perhaps any other dev environments supported
only on a best efforts basis?

> Would an uber jar support the 2) and 3)?
I believe so.  Or at least that was what it will be intended to do.

> Do we want to try to support all the user scenarios we come up with or 
> only certain ones?
Could you clarify? what types of user scenarios?  Not sure if we'll really be able to support
" ALL user scenarios"...

> With only the UIMA CPE GUI, did we ever really support a non-programmer user?
Not historically.

> Will the new GUI in the sandbox be such support?
Hopefully.  That was the goal/intention.



> -----Original Message-----
> From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> Sent: Wednesday, October 10, 2012 5:16 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: cTAKES uber jar distribution
> 
> You remember correctly. This was voted on way before Apache. We did 
> have interest in this kind of distribution before. However, even 
> though it may be easy to create an uber jar, perhaps we should step 
> back and verify the definition of our users. I always thought there 
> were 2 (user, developer) as defined in the current doc here:
> https://wiki.nci.nih.gov/display/VKC/cTAKES+2.5#cTAKES25-
> DownloadandInstall
> 
> Some of the other JIRA items being discussed make me think there may 
> be
> these:
> 1) A "user" (researcher but non-programmer) wants value from cTAKES 
> with no compiles, no dev env, just simple download/install/use.
> 2) A programmer new to cTAKES wants to take the whole, as quickly as 
> possible, into some kind of dev env, hopes not to have to deal with 
> any dependency or build issues (given that that take a stable release) 
> and invoke the APIs. Kick the tires is the notion.
> 3) A programmer uses cTAKES as a black-box. They take cTAKES as a 
> whole, perhaps minimal changes, include everything. Dictionaries could 
> be replaced by them if they desire.
> 4) An experienced cTAKES developer - mash cTAKES into any form they 
> want, change it, possibly contribute to Apache. Builds could be 
> accomplished from a number of IDEs.
> 
> Questions that come to mind. These are meant to be food-for-thought
> questions:
> Do we support all kinds of dev environments? Only a few? Is there a 
> priority order, like Eclipse only, Eclipse plus Maven, command line, 
> others. (Current doc recommends Eclipse but also documents command 
> line. For anything else the programmer is expected to extrapolate.) Do 
> we require a developer to have Maven to build cTAKES?
> Would an uber jar support the 2) and 3)?
> Do we want to try to support all the user scenarios we come up with or 
> only certain ones?
> With only the UIMA CPE GUI, did we ever really support a 
> non-programmer user? Will the new GUI in the sandbox be such support?
> 
> Would you all mind vetting out these user types via this email thread? 
> If we can settle on who the users are, trying to keep it generalized 
> to avoid 10s of variations, I think this will shed a lot of light on current and future
JIRA items.
> 
> Thanks
> Troy
> 
> -----Original Message-----
> From: ctakes-dev-return-534-
> Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return- 
> 534-Bleeker.Troy=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> Sent: Tuesday, October 09, 2012 11:14 AM
> To: ctakes-dev@incubator.apache.org
> Subject: cTAKES uber jar distribution
> 
> If I recall correctly, I believe there was interest and a consensus to 
> have an additional optional cTAKES binary distribution as an 
> standalone executable jar with all of its dependencies included.
> This is in additional to a simple cTAKES maven dependency or it's 
> module jars for developers to include directly into their projects 
> [geared towards end- users in addition to the future web configuration 
> gui that is currently in sandbox now].  I believe the creation of some 
> uber jar for deployment should be easily accomplished now using either 
> the maven assembly plugin or shade plugin.
> [May have to make some minor tweaks to the existing main pom such as 
> separating out the inheritance vs the aggregator specific functions 
> such as shading - which is probably a good idea anyway].
> 
> Does an uber jar still sound useful or should we wait until we create 
> a war (with separate dependency jars in the standard WEB-INF/lib) 
> which will be part of the web gui very soon anyway?
> If anyone has any concerns/objections/suggestions, please let us  
> know- or better yet just open a jira and contribute to it :).
> 
> --Pei

Mime
View raw message