Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362012-08-06T20:33:00ZEcoinformatics Redmine
Redmine Bug #5646 (New): Switching some of the add-on modules to corehttps://projects.ecoinformatics.org/ecoinfo/issues/56462012-08-06T20:33:00ZIlkay Altintasaltintas@sdsc.edu
<p>Before 2.5, we need a discussion on switching some of the key modules, e.g., modules in the reporting suite, to the core suite and release process.</p> Bug #5559 (New): Curation Package User Manual PDFhttps://projects.ecoinformatics.org/ecoinfo/issues/55592011-12-01T01:16:31ZBob Morrismorris.bob@gmail.com
<p>The Kuration Package User Manual PDF would be easier to use if the pages carried page numbers.</p> Bug #5354 (New): Integrate Kepler Wiki Into Kepler Helphttps://projects.ecoinformatics.org/ecoinfo/issues/53542011-03-22T00:40:30ZDavid Welkerdavid.v.welker@gmail.com
<p>Sven has an idea. When running Kepler, there should be two types of help. One for users and one for developers. Both should be accessible from the Help menu, and should reference appropriate places on the Kepler wiki. This should be integrated with the current help information all of which should be organized in a logical manner.</p> Bug #5340 (New): Miss a dollar sing ($) when an actor references a parameter.https://projects.ecoinformatics.org/ecoinfo/issues/53402011-03-04T23:05:26ZJing Taotao@nceas.ucsb.edu
<p>On Figure 3.20 (page 66) of KeplerUserManual-2.1.0.doc, it shows how to reference a parameter OutputDir. It shows:</p>
<p>OutputDir+"ccov6190"</p>
<p>But it doesn't work in this way. It should be:</p>
<p>$OutputDir+"ccov6190"</p>
<p>A dollar sign is missed.</p> Bug #5327 (New): Need to fix documentation systemhttps://projects.ecoinformatics.org/ecoinfo/issues/53272011-02-25T23:38:36ZDavid Welkerdavid.v.welker@gmail.com
<p>Our current documentation system creates a lot of unnecessary work and has excessive overhead to produce updated documentation for even minor changes. As a result, documentation tends not to be updated incrementally as would be ideal. Also, at release time, dealing with the production of documentation consumes much more time than it should.</p>
<p>Basically, the approach we have now is that our documentation is separated into Word documents, one Word document per chapter. Already, this limits the ability of people to contribute to the documentation to those who have Microsoft Word or perhaps OpenOffice. Requiring users to have Microsoft Word already goes significantly against the spirit of an open source project in my view. While OpenOffice, in contrast, is open source, I am not sure if it is fully compatible or not. It probably is if all you are editing is text, but may have more difficulty with other sorts of document structures. Further, since the documents tend to be large, it often takes quite a bit of time to load, even though this is partially ameliorated by only storing a single chapter in a Word document. Finally, when it comes time to compile these documents for delivery, it is a tedious process to arrange the correct documents in the correct order without any unexpected issues. Also, I think an issue that has come up in this release that also appeared in this release is that the links in the generated PDF files did not work.</p>
<p>A better approach to documentation would:</p>
<p>First and foremost be able to compile all existing documentation with a single command. There is really no good reason to have so many steps for human intervention, and hence mistakes since it should be possible, in both theory and practice, to have a simple working PDF produced with a single command. Furthermore, there is really no good reason for us to tie our documentation to a proprietary product, like Microsoft Word. Especially since we are an open source project.</p>
<p>Second, we should be able to edit documentation without any software besides a web browser. By easing the overhead of updating documentation, we are much liker to have documentation that is updated more often, to be more accurate, and of a higher quality. I believe that there might be solutions out there that allow the editing of documentation by anyone from a web browser (something like Wikibooks might do the trick, but more research is necessary). If we found a way to allow the documentation to be edited from the browser, this would make it easier to update the documentation as we work and also in response to questions we get from the community. Also, it would allow more people to be able to easier contribute to the documentation, whether or not they have Microsoft Word, whether or not they know how to access our repositories to access the current documentation and whether or not they could figure out how our current documents are structured and whether or not they have write access to our SVN repository.</p>
<p>Perhaps getting documentation that is fully editable from any browser is unrealistic. It depends on the adequacy for our needs of open source projects (like Wikibooks) and also how much effort would be involved to take our current documentation from Microsoft Word format into the more open formats supported by these projects. But at the very least, we should strongly consider at least moving away from solutions that require access to proprietary software and which are error prone when converting from the format in which documents are written into their final form.</p> Bug #5281 (New): cannot open 1.0 KARshttps://projects.ecoinformatics.org/ecoinfo/issues/52812011-01-26T19:19:56ZDaniel Crawldanielcrawl@gmail.com
<p>KARs created in Kepler 1.0 cannot be opened.</p>
<p>An example is 04-HelloWorld.kar in the outreach module:</p>
<p>[run] WARN (org.kepler.kar.KAREntry:getHandler:208) no handler for KAREntry: 04-HelloWorld.xml urn:lsid:kepler-project.org:workflow:2:1</p> Bug #5173 (New): Develop clear criteria for when code in Kepler CORE should be in its own module.https://projects.ecoinformatics.org/ecoinfo/issues/51732010-09-08T23:24:18ZDavid Welkerdavid.v.welker@gmail.com
<p>As of now, we have broken up Kepler into a number of modules. But this breaking up of Kepler has been ad hoc and not followed a consistent set of guidelines concerning when code should be in its own module and when it should be grouped with other code that is somehow related in a common module.</p>
<p>Lack of consistent guidelines make modules harder to understand. Following more consistent guidelines would make Kepler easier to understand.</p> Bug #4909 (New): Actor documentation: updates ignored, duplicate info, how to refer to other acto...https://projects.ecoinformatics.org/ecoinfo/issues/49092010-03-29T21:15:59ZChristopher Brookscxh@eecs.berkeley.edu
<p>A few comments about the Kepler Actor Documentation system</p>
<p>1. If I update the .xml file for a Director, then preexisting models<br />do not get the updates. I think this is wrong. For example,<br />I added text to PNDirector.xml. If a user has a preexisting model<br />that uses PNDirector, then to see the new text, they would need<br />to drag in a new PNDirector.</p>
<p>2. The model files contain copies of the documentation. This is<br />related to point 1 above. This will be an issue for large systems<br />because parsing a large file with redundant info takes time and<br />possibly consumes lots of memory</p>
<p>3. In a documentation .xml file, how do I refer to another actor<br />or director? For example in<br />kepler/directors/resources/kar/CoreDirectors/PNDirector.xml<br />I want to refer to the Ramp actor so that if the user<br />clicks on the link, then they are shown the Ramp actor documentation<br />How do I do that?</p>
<p>4. In a documentation .xml file, how do I refer to a model?<br />For example, in<br />kepler/directors/resources/kar/CoreDirectors/PNDirector.xml<br />I want to refer to<br />ptolemy/domains/pn/demo/RemoveNilTokens/RemoveNilTokens.xml<br />How do I do that?</p> Bug #3392 (New): Need scrollbars in Documentation > Customize Documentation windowhttps://projects.ecoinformatics.org/ecoinfo/issues/33922008-06-12T18:36:49ZKirsten Menger-Andersonkma500@hotmail.com
<p>When a workflow has many parameters, the customize documentation screen does not generate a scroll bar so that people can scroll down and enter values for parameters that don't appear on the screen; it's also impossible to commit customized documentation, since the UI buttons are pushed offscreen, too.</p>
<p>An example of this problem can be found when trying to customize documentation for the SimHofi workflow:<br /> <a class="external" href="https://code.ecoinformatics.org/code/reap/trunk/usecases/terrestrial/workflows/HosseiniSimulationWorkflow/simhofi.xml">https://code.ecoinformatics.org/code/reap/trunk/usecases/terrestrial/workflows/HosseiniSimulationWorkflow/simhofi.xml</a></p>
<p>Right-click the Workflow canvas and select Customize Documentation.</p> Bug #2265 (New): Simple Kepler features movie to be displayed at the 1st time installationhttps://projects.ecoinformatics.org/ecoinfo/issues/22652005-11-11T00:07:42ZIlkay Altintasaltintas@sdsc.edu
<p>Build up of a small movie or a slide show that walks to user through the basic<br />features of Kepler. The suggestion is to open this with the application the<br />first time a user installs Kepler as an optional movie and make it reachable<br />through a menu item at other times.</p> Bug #2027 (In Progress): provide ability to assign checkpoints in the workflowhttps://projects.ecoinformatics.org/ecoinfo/issues/20272005-03-11T20:46:58ZLaura Downeyldowney@lternet.edu
<p>provide ability for user to assign checkpoints at various points in the <br />workflow so that user can check progress and make decisions on whether to <br />modify or continue etc.</p>