>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:[email protected]] > Sent: Friday, March 01, 2013 2:56 PM > To: '[email protected]' > 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- > [email protected] [mailto:ctakes-dev-return- > [email protected]] On Behalf Of Masanz, > James J. > Sent: Friday, March 01, 2013 11:21 AM > To: '[email protected]' > 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....@incubator.apache.org > > [mailto:ctakes-dev-return-1307- > > [email protected]] On Behalf Of Chen, Pei > > Sent: Friday, March 01, 2013 8:20 AM > > To: [email protected] > > 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:[email protected]] > > > Sent: Thursday, February 28, 2013 3:06 PM > > > To: [email protected] > > > 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 * [email protected] > Mayo > > > Clinic * 200 First Street SW * Rochester, MN 55905 * > > www.mayoclinic.org
