You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by "Bleeker, Troy C." <Bl...@mayo.edu> on 2013/03/01 20:55:27 UTC
structure of binary versus source
The structure of the directories is different. If our categorization that users are potential, future developers is correct it seems odd to have them learn one structure and then as developers learn another. Maybe it's because I don't know or see the benefits of having the structure in the binary dist. And I'm not a big consumer so take it for what it is.
Binary - Top levels are bin, config, desc, lib, resources
Source - Top levels are the components
Binary - One master "desc" directory (like James mentioned), then components, then the XML descriptors
Source - No top level "desc"
Binary - All resources in one place at the top level
Source - Has resources for each component, but yet the ctakes-resources-3.0.1.zip, goes under ctakes-dictionary-lookup/resources, nothing top level
Binary - No test data at least in 3.0.
Source - Some of the components have test data. It is not centralized but within each.
With that then, is there benefit to making the binary distribution closely match the source?
Thanks
Troy
-----Original Message-----
From: ctakes-dev-return-1308-Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-1308-Bleeker.Troy=mayo.edu@incubator.apache.org] On Behalf Of Masanz, James J.
Sent: Friday, March 01, 2013 11:21 AM
To: 'ctakes-dev@incubator.apache.org'
Subject: RE: 3.0 doc summary; one failing test
As far as user vs. developer guide.
There have been people who want to just download a binary and run without compiling or even without an IDE - to 'kick the tires' a bit.
As far as the structures of binary vs source, at least one difference is the way XML descriptors are bundled together under one master desc directory rather than in within the separate components. Not sure if there was more that Troy was referring to.
-- James
> -----Original Message-----
> From:
> ctakes-dev-return-1307-Masanz.James=mayo.edu@incubator.apache.org
> [mailto:ctakes-dev-return-1307-
> Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> Sent: Friday, March 01, 2013 8:20 AM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: 3.0 doc summary; one failing test
>
> Do we need to differentiate between cTAKES developer guide and user
> guide? I think in its current state, cTAKES users are probably
> developers. Perhaps we should just combine them and just call it a
> guide/manual just like UIMA?
> I think once we have a tool that runs in the 3 steps that Andy
> referred to, then I think that would be something an end-user would use...
> (Probably not the current UIMA CPE/CVD GUI's.) Just to manage some of
> the expectations for those end-users.
>
> http://incubator.apache.org/ctakes/roadmap.html looks good, but will
> need to be maintained manually vs: the roadman from Jira which is
> automatically generated:
> https://issues.apache.org/jira/browse/CTAKES#selectedTab=com.atlassian
> .j ira.plugin.system.project%3Aroadmap-panel ?
>
> > - Agree on one structure for cTAKES projects. The binary
> > distribution is in a different form that the developer source. We
> > decided a long time ago to try something new. It never caught on in
> > the developer ranks. We should either complete the transformation in
> > dev or return the user binary structure to match dev.
> I'm not quite sure what you mean here. Each component is a separate
> module in the source code. In the distribution binary, each component
> is distributed with it's own jar in /lib now. For example: ctakes-
> assertion.jar, ctakes-core.jar.
>
>
> > -----Original Message-----
> > From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> > Sent: Thursday, February 28, 2013 3:06 PM
> > To: ctakes-dev@incubator.apache.org
> > Subject: 3.0 doc summary; one failing test
> >
> > I think I've done as much as I can do on the doc at this point. I
> > was able to run the Linux install/tests for both dev and user. For
> > user, the results of the CVD run were basically nothing. There was
> > but 1 annotation for all the text pasted in. No concepts. Nothing.
> > If someone wants to verify this we could create a JIRA item. I may
> > have
> missed something.
> >
> > Otherwise (with completed items left out) here is what could still
> > be
> done:
> >
> > - The examples, as described by Andy, would be more than a readme
> > should have. This would be great for a how-to guide. The Developer
> > Guide and User Guide have been renamed to Install Guides. I don't
> > think a how-to guide should be incorporated into these but should be
> > its own document. Making one would be great and as you say should
> > include things like 1) pointers to where to find basic information
> > 2) very high level overview of the components in the context of
> > using them to do a very basic task 3) I think it was suggested that
> > the Getting Started page might be something like this in very short form.
> > If we did that then it would point to a more comprehensive how-to
> > guide. [The Getting Started page is a short start now.]
> >
> > - Project history page of all cTAKES releases placed on Apache sites
> > somewhere. Good plan if short. I would not copy readmes there but
> > have links to them. This was done in the past but removed from the
> > bottom of the downloads page. This page exists now but is not linked
> > to from the Apache cTAKES site. Here is a direct link:
> > http://incubator.apache.org/ctakes/roadmap.html. Decide if you want
> > to go forward with something like this. An archive page will be
> > needed when we have more releases under our belt.
> >
> > - Creating a single download for a newcomer. We should revisit this
> > at some point in order to make the best first impression. A new user
> > should be able to get from nothing to running cTAKES in three steps:
> > download, uncompress, run (like 2.5).
> >
> > - Agree on one structure for cTAKES projects. The binary
> > distribution is in a different form that the developer source. We
> > decided a long time ago to try something new. It never caught on in
> > the developer ranks. We should either complete the transformation in
> > dev or return the user binary structure to match dev. New users are
> > potential new
> developers of cTAKES in the future.
> > It's confusing when those two structures are not the same for that
> > person. If you want to attract contributions well ... this does not
> help.
> >
> > Perhaps these could all be made JIRA items.
> >
> > Thanks
> > Troy Bleeker * Senior Business Analyst CBAP(r) * Biomedical
> > Statistics and Informatics
> > Phone: 507-293-1574 * Fax: 507-284-0360 * bleeker.troy@mayo.edu Mayo
> > Clinic * 200 First Street SW * Rochester, MN 55905 *
> www.mayoclinic.org
RE: structure of binary versus source
Posted by "Bleeker, Troy C." <Bl...@mayo.edu>.
I think it makes a difference because it's related to how the newcomer learns to use the cTAKES structure at first, regardless of how it's built. If they learn one way and then need to change later it's just another hurdle to get over.
Thanks
Troy
-----Original Message-----
From: ctakes-dev-return-1314-Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-1314-Bleeker.Troy=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
Sent: Friday, March 01, 2013 2:03 PM
To: ctakes-dev@incubator.apache.org
Subject: RE: structure of binary versus source
>With that then, is there benefit to making the binary distribution closely match the source?
"mvn package" is scripted and builds the dist structure behind the scenes. So does it really make a difference? My vote would be probably no if there was a script/automated way to do it.
Feel free to open the Jira as appropriate- maybe someone has an even cleaner/easier way of doing it.
--Pei
> -----Original Message-----
> From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> Sent: Friday, March 01, 2013 2:56 PM
> To: 'ctakes-dev@incubator.apache.org'
> Subject: structure of binary versus source
>
> The structure of the directories is different. If our categorization
> that users are potential, future developers is correct it seems odd to
> have them learn one structure and then as developers learn another.
> Maybe it's because I don't know or see the benefits of having the
> structure in the binary dist. And I'm not a big consumer so take it for what it is.
>
> Binary - Top levels are bin, config, desc, lib, resources Source - Top
> levels are the components
>
> Binary - One master "desc" directory (like James mentioned), then
> components, then the XML descriptors Source - No top level "desc"
>
> Binary - All resources in one place at the top level Source - Has
> resources for each component, but yet the ctakes-resources-3.0.1.zip,
> goes under ctakes- dictionary-lookup/resources, nothing top level
>
> Binary - No test data at least in 3.0.
> Source - Some of the components have test data. It is not centralized
> but within each.
>
> With that then, is there benefit to making the binary distribution
> closely match the source?
>
> Thanks
> Troy
>
> -----Original Message-----
> From: ctakes-dev-return-1308-
> Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 1308-Bleeker.Troy=mayo.edu@incubator.apache.org] On Behalf Of Masanz,
> James J.
> Sent: Friday, March 01, 2013 11:21 AM
> To: 'ctakes-dev@incubator.apache.org'
> Subject: RE: 3.0 doc summary; one failing test
>
>
> As far as user vs. developer guide.
> There have been people who want to just download a binary and run
> without compiling or even without an IDE - to 'kick the tires' a bit.
>
> As far as the structures of binary vs source, at least one difference
> is the way XML descriptors are bundled together under one master desc
> directory rather than in within the separate components. Not sure if
> there was more that Troy was referring to.
>
> -- James
>
> > -----Original Message-----
> > From:
> > ctakes-dev-return-1307-Masanz.James=mayo.edu@incubator.apache.org
> > [mailto:ctakes-dev-return-1307-
> > Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> > Sent: Friday, March 01, 2013 8:20 AM
> > To: ctakes-dev@incubator.apache.org
> > Subject: RE: 3.0 doc summary; one failing test
> >
> > Do we need to differentiate between cTAKES developer guide and user
> > guide? I think in its current state, cTAKES users are probably
> > developers. Perhaps we should just combine them and just call it a
> > guide/manual just like UIMA?
> > I think once we have a tool that runs in the 3 steps that Andy
> > referred to, then I think that would be something an end-user would use...
> > (Probably not the current UIMA CPE/CVD GUI's.) Just to manage some
> > of the expectations for those end-users.
> >
> > http://incubator.apache.org/ctakes/roadmap.html looks good, but will
> > need to be maintained manually vs: the roadman from Jira which is
> > automatically generated:
> > https://issues.apache.org/jira/browse/CTAKES#selectedTab=com.atlassi
> > an .j ira.plugin.system.project%3Aroadmap-panel ?
> >
> > > - Agree on one structure for cTAKES projects. The binary
> > > distribution is in a different form that the developer source. We
> > > decided a long time ago to try something new. It never caught on
> > > in the developer ranks. We should either complete the
> > > transformation in dev or return the user binary structure to match dev.
> > I'm not quite sure what you mean here. Each component is a separate
> > module in the source code. In the distribution binary, each
> > component is distributed with it's own jar in /lib now. For
> > example: ctakes- assertion.jar, ctakes-core.jar.
> >
> >
> > > -----Original Message-----
> > > From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> > > Sent: Thursday, February 28, 2013 3:06 PM
> > > To: ctakes-dev@incubator.apache.org
> > > Subject: 3.0 doc summary; one failing test
> > >
> > > I think I've done as much as I can do on the doc at this point. I
> > > was able to run the Linux install/tests for both dev and user. For
> > > user, the results of the CVD run were basically nothing. There was
> > > but 1 annotation for all the text pasted in. No concepts. Nothing.
> > > If someone wants to verify this we could create a JIRA item. I may
> > > have
> > missed something.
> > >
> > > Otherwise (with completed items left out) here is what could still
> > > be
> > done:
> > >
> > > - The examples, as described by Andy, would be more than a readme
> > > should have. This would be great for a how-to guide. The Developer
> > > Guide and User Guide have been renamed to Install Guides. I don't
> > > think a how-to guide should be incorporated into these but should
> > > be its own document. Making one would be great and as you say
> > > should include things like 1) pointers to where to find basic
> > > information
> > > 2) very high level overview of the components in the context of
> > > using them to do a very basic task 3) I think it was suggested
> > > that the Getting Started page might be something like this in very short form.
> > > If we did that then it would point to a more comprehensive how-to
> > > guide. [The Getting Started page is a short start now.]
> > >
> > > - Project history page of all cTAKES releases placed on Apache
> > > sites somewhere. Good plan if short. I would not copy readmes
> > > there but have links to them. This was done in the past but
> > > removed from the bottom of the downloads page. This page exists
> > > now but is not linked to from the Apache cTAKES site. Here is a direct link:
> > > http://incubator.apache.org/ctakes/roadmap.html. Decide if you
> > > want to go forward with something like this. An archive page will
> > > be needed when we have more releases under our belt.
> > >
> > > - Creating a single download for a newcomer. We should revisit
> > > this at some point in order to make the best first impression. A
> > > new user should be able to get from nothing to running cTAKES in three steps:
> > > download, uncompress, run (like 2.5).
> > >
> > > - Agree on one structure for cTAKES projects. The binary
> > > distribution is in a different form that the developer source. We
> > > decided a long time ago to try something new. It never caught on
> > > in the developer ranks. We should either complete the
> > > transformation in dev or return the user binary structure to match
> > > dev. New users are potential new
> > developers of cTAKES in the future.
> > > It's confusing when those two structures are not the same for that
> > > person. If you want to attract contributions well ... this does
> > > not
> > help.
> > >
> > > Perhaps these could all be made JIRA items.
> > >
> > > Thanks
> > > Troy Bleeker * Senior Business Analyst CBAP(r) * Biomedical
> > > Statistics and Informatics
> > > Phone: 507-293-1574 * Fax: 507-284-0360 * bleeker.troy@mayo.edu
> Mayo
> > > Clinic * 200 First Street SW * Rochester, MN 55905 *
> > www.mayoclinic.org
RE: structure of binary versus source
Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
>With that then, is there benefit to making the binary distribution closely match the source?
"mvn package" is scripted and builds the dist structure behind the scenes. So does it really make a difference? My vote would be probably no if there was a script/automated way to do it.
Feel free to open the Jira as appropriate- maybe someone has an even cleaner/easier way of doing it.
--Pei
> -----Original Message-----
> From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> Sent: Friday, March 01, 2013 2:56 PM
> To: 'ctakes-dev@incubator.apache.org'
> Subject: structure of binary versus source
>
> The structure of the directories is different. If our categorization that users
> are potential, future developers is correct it seems odd to have them learn
> one structure and then as developers learn another. Maybe it's because I
> don't know or see the benefits of having the structure in the binary dist. And
> I'm not a big consumer so take it for what it is.
>
> Binary - Top levels are bin, config, desc, lib, resources Source - Top levels are
> the components
>
> Binary - One master "desc" directory (like James mentioned), then
> components, then the XML descriptors Source - No top level "desc"
>
> Binary - All resources in one place at the top level Source - Has resources for
> each component, but yet the ctakes-resources-3.0.1.zip, goes under ctakes-
> dictionary-lookup/resources, nothing top level
>
> Binary - No test data at least in 3.0.
> Source - Some of the components have test data. It is not centralized but
> within each.
>
> With that then, is there benefit to making the binary distribution closely
> match the source?
>
> Thanks
> Troy
>
> -----Original Message-----
> From: ctakes-dev-return-1308-
> Bleeker.Troy=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 1308-Bleeker.Troy=mayo.edu@incubator.apache.org] On Behalf Of Masanz,
> James J.
> Sent: Friday, March 01, 2013 11:21 AM
> To: 'ctakes-dev@incubator.apache.org'
> Subject: RE: 3.0 doc summary; one failing test
>
>
> As far as user vs. developer guide.
> There have been people who want to just download a binary and run
> without compiling or even without an IDE - to 'kick the tires' a bit.
>
> As far as the structures of binary vs source, at least one difference is the way
> XML descriptors are bundled together under one master desc directory
> rather than in within the separate components. Not sure if there was more
> that Troy was referring to.
>
> -- James
>
> > -----Original Message-----
> > From:
> > ctakes-dev-return-1307-Masanz.James=mayo.edu@incubator.apache.org
> > [mailto:ctakes-dev-return-1307-
> > Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Chen, Pei
> > Sent: Friday, March 01, 2013 8:20 AM
> > To: ctakes-dev@incubator.apache.org
> > Subject: RE: 3.0 doc summary; one failing test
> >
> > Do we need to differentiate between cTAKES developer guide and user
> > guide? I think in its current state, cTAKES users are probably
> > developers. Perhaps we should just combine them and just call it a
> > guide/manual just like UIMA?
> > I think once we have a tool that runs in the 3 steps that Andy
> > referred to, then I think that would be something an end-user would use...
> > (Probably not the current UIMA CPE/CVD GUI's.) Just to manage some of
> > the expectations for those end-users.
> >
> > http://incubator.apache.org/ctakes/roadmap.html looks good, but will
> > need to be maintained manually vs: the roadman from Jira which is
> > automatically generated:
> > https://issues.apache.org/jira/browse/CTAKES#selectedTab=com.atlassian
> > .j ira.plugin.system.project%3Aroadmap-panel ?
> >
> > > - Agree on one structure for cTAKES projects. The binary
> > > distribution is in a different form that the developer source. We
> > > decided a long time ago to try something new. It never caught on in
> > > the developer ranks. We should either complete the transformation in
> > > dev or return the user binary structure to match dev.
> > I'm not quite sure what you mean here. Each component is a separate
> > module in the source code. In the distribution binary, each component
> > is distributed with it's own jar in /lib now. For example: ctakes-
> > assertion.jar, ctakes-core.jar.
> >
> >
> > > -----Original Message-----
> > > From: Bleeker, Troy C. [mailto:Bleeker.Troy@mayo.edu]
> > > Sent: Thursday, February 28, 2013 3:06 PM
> > > To: ctakes-dev@incubator.apache.org
> > > Subject: 3.0 doc summary; one failing test
> > >
> > > I think I've done as much as I can do on the doc at this point. I
> > > was able to run the Linux install/tests for both dev and user. For
> > > user, the results of the CVD run were basically nothing. There was
> > > but 1 annotation for all the text pasted in. No concepts. Nothing.
> > > If someone wants to verify this we could create a JIRA item. I may
> > > have
> > missed something.
> > >
> > > Otherwise (with completed items left out) here is what could still
> > > be
> > done:
> > >
> > > - The examples, as described by Andy, would be more than a readme
> > > should have. This would be great for a how-to guide. The Developer
> > > Guide and User Guide have been renamed to Install Guides. I don't
> > > think a how-to guide should be incorporated into these but should be
> > > its own document. Making one would be great and as you say should
> > > include things like 1) pointers to where to find basic information
> > > 2) very high level overview of the components in the context of
> > > using them to do a very basic task 3) I think it was suggested that
> > > the Getting Started page might be something like this in very short form.
> > > If we did that then it would point to a more comprehensive how-to
> > > guide. [The Getting Started page is a short start now.]
> > >
> > > - Project history page of all cTAKES releases placed on Apache sites
> > > somewhere. Good plan if short. I would not copy readmes there but
> > > have links to them. This was done in the past but removed from the
> > > bottom of the downloads page. This page exists now but is not linked
> > > to from the Apache cTAKES site. Here is a direct link:
> > > http://incubator.apache.org/ctakes/roadmap.html. Decide if you want
> > > to go forward with something like this. An archive page will be
> > > needed when we have more releases under our belt.
> > >
> > > - Creating a single download for a newcomer. We should revisit this
> > > at some point in order to make the best first impression. A new user
> > > should be able to get from nothing to running cTAKES in three steps:
> > > download, uncompress, run (like 2.5).
> > >
> > > - Agree on one structure for cTAKES projects. The binary
> > > distribution is in a different form that the developer source. We
> > > decided a long time ago to try something new. It never caught on in
> > > the developer ranks. We should either complete the transformation in
> > > dev or return the user binary structure to match dev. New users are
> > > potential new
> > developers of cTAKES in the future.
> > > It's confusing when those two structures are not the same for that
> > > person. If you want to attract contributions well ... this does not
> > help.
> > >
> > > Perhaps these could all be made JIRA items.
> > >
> > > Thanks
> > > Troy Bleeker * Senior Business Analyst CBAP(r) * Biomedical
> > > Statistics and Informatics
> > > Phone: 507-293-1574 * Fax: 507-284-0360 * bleeker.troy@mayo.edu
> Mayo
> > > Clinic * 200 First Street SW * Rochester, MN 55905 *
> > www.mayoclinic.org