Mailing-List: contact ctakes-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ctakes-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Pei.Chen@childrens.harvard.edu
 designates 134.174.20.73 as permitted sender)
From: "Chen, Pei" <Pei.Chen@childrens.harvard.edu>
To: "ctakes-dev@incubator.apache.org" <ctakes-dev@incubator.apache.org>
Subject: RE: cTAKES uber jar distribution
Thread-Topic: cTAKES uber jar distribution
Thread-Index: Ac2nLGBdp+t73R1QShCxKOm/NTR6XAAAKieQADq6YoAACDQl4A==
Date: Thu, 11 Oct 2012 21:40:42 +0000
Message-ID: <924DE05C19409B438EB81DE683A942D92051B4@CHEXMBX1A.CHBOSTON.ORG>
References: 
 <B1D5DE3F00E17F458CC1B5158EA798B3018F6D@MSGPEXCEI10A.mfad.mfroot.org>
 <924DE05C19409B438EB81DE683A942D920482D@CHEXMBX1A.CHBOSTON.ORG>
 <B1D5DE3F00E17F458CC1B5158EA798B30198E0@MSGPEXCEI10A.mfad.mfroot.org>
In-Reply-To: 
 <B1D5DE3F00E17F458CC1B5158EA798B30198E0@MSGPEXCEI10A.mfad.mfroot.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> Will Maven be required for command line too?)
Yes. (I believe Maven has become a fairly common build utility now; just li=
ke Ant or Make).

> So, do the three programmer use cases above sum up what is likely to be e=
ncountered or are there others? Do these need edits?
That's a good question.  I think we should aim to make cTAKES work Eclipse =
IDE + Maven as simple as possible (less than few steps), then it probably w=
ould cover 2,3,4 or whoever calls themselves a " programmer".

If we make an uber jar with all dependencies resolved and resources include=
d.  Then only Java would be required (no Maven, Eclipse, etc.).  Not to be =
confused with being able to compile, build, test from the CLI. (Even though=
 this may be sound technically simple now, we still have to consider the va=
rious ASF licensing issues.)

My 1/2 cent...

--Pei

> -----Original Message-----
> From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> Sent: Thursday, October 11, 2012 5:22 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: cTAKES uber jar distribution
>=20
> > Could you clarify? what types of user scenarios?  Not sure if we'll rea=
lly be
> able to support " ALL user scenarios"...
>=20
> 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 dow=
n
> let me try to combine what the 3 of us said. Here are the 4 use cases
> (attempting not to label to avoid preconceptions).
>=20
> 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 t=
he
> license.
>=20
> 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:
> =1B$B!|=1B(B Command line    (BTW, I've seen the mvn commands tossed abou=
t. Will
> Maven be required for command line too?)
> =1B$B!|=1B(B Eclipse + Maven
> =1B$B!|=1B(B All others must extrapolate from above
>=20
> 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 n=
ot, 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?
>=20
> Thanks
> Troy
>=20
> -----Original Message-----> Do we support all kinds of dev environments?
>=20
> I suggest we start with command line and with Eclipse + maven.
>=20
> > Would an uber jar support the 2) and 3)?
>=20
> I think so.
>=20
> > Do we want to try to support all the user scenarios we come up with or
> > only certain ones?
>=20
> Again, I suggest we start with command line and with Eclipse + maven.
>=20
> > With only the UIMA CPE GUI, did we ever really support a non-programmer
> user?
>=20
> 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 understan=
d
> any XML)
>=20
> > Will the new GUI in the sandbox be such support?
>=20
> That's what it is supposed to be, as I understand it.
>=20
> -- James
>=20
> -----Original Message-----
> From: ctakes-dev-return-583-
> Bleeker.Troy=3Dmayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 583-Bleeker.Troy=3Dmayo.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
>=20
> > 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?
>=20
> 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?
>=20
> > Would an uber jar support the 2) and 3)?
> I believe so.  Or at least that was what it will be intended to do.
>=20
> > 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 reall=
y be
> able to support " ALL user scenarios"...
>=20
> > With only the UIMA CPE GUI, did we ever really support a non-programmer
> user?
> Not historically.
>=20
> > Will the new GUI in the sandbox be such support?
> Hopefully.  That was the goal/intention.
>=20
>=20
>=20
> > -----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 cu=
rrent and
> future JIRA items.
> >
> > Thanks
> > Troy
> >
> > -----Original Message-----
> > From: ctakes-dev-return-534-
> > Bleeker.Troy=3Dmayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> > 534-Bleeker.Troy=3Dmayo.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