Kepler: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362011-03-15T20:56:47ZEcoinformatics Redmine
Redmine Bug #5352 (Resolved): build-area-2.1 is not working and build-area-2.2 is needed for kepler-2.2 r...https://projects.ecoinformatics.org/ecoinfo/issues/53522011-03-15T20:56:47Zjianwu jianwujianwu@sdsc.edu
<p>I didn't see build-area-2.2 module for kepler-2.2 at <a class="external" href="https://code.kepler-project.org/code/kepler/releases/release-branches/">https://code.kepler-project.org/code/kepler/releases/release-branches/</a> or <a class="external" href="https://code.kepler-project.org/code/kepler/releases/released/">https://code.kepler-project.org/code/kepler/releases/released/</a>. When I tried to use <a class="external" href="https://code.kepler-project.org/code/kepler/releases/release-branches/build-area-2.1/">https://code.kepler-project.org/code/kepler/releases/release-branches/build-area-2.1/</a>, I got the following exception. Since kepler trunk is ever changing, we'd better have a build-area-2.2 module for kepler 2.2 release.</p>
<p>kepler:build-area-2.1 jianwu$ svn info<br />Path: .<br />URL: <a class="external" href="https://code.kepler-project.org/code/kepler/releases/release-branches/build-area-2.1">https://code.kepler-project.org/code/kepler/releases/release-branches/build-area-2.1</a><br />Repository Root: <a class="external" href="https://code.kepler-project.org/code/kepler">https://code.kepler-project.org/code/kepler</a><br />Repository UUID: edc41a2b-3e5c-0410-9d3f-8540a70682f1<br />Revision: 27291<br />Node Kind: directory<br />Schedule: normal<br />Last Changed Author: welker<br />Last Changed Rev: 26871<br />Last Changed Date: 2011-01-31 14:25:53 -0800 (Mon, 31 Jan 2011)</p>
<p>kepler:build-area-2.1 jianwu$ ant<br />Buildfile: /Users/jianwu/Kepler/repository/kepler/kepler-branch-2.2/build-area-2.1/build.xml</p>
<p>BUILD FAILED<br />/Users/jianwu/Kepler/repository/kepler/kepler-branch-2.2/build-area-2.1/build.xml:4: The following error occurred while executing this line:<br />/Users/jianwu/Kepler/repository/kepler/kepler-branch-2.2/build-area-2.1/settings/taskdefs.xml:5: typedef class org.kepler.build.Get cannot be found<br /> using the classloader AntClassLoader[]</p>
<p>Total time: 0 seconds</p> Bug #5334 (Resolved): 2.2 rc3: kepler.sh file is not executable by default in Kepler.app/Contents...https://projects.ecoinformatics.org/ecoinfo/issues/53342011-03-01T23:52:08Zjianwu jianwujianwu@sdsc.edu
<p>I think many users need to use kepler.sh or kepler.bat to get console information. But in my installation on mac, Kepler.app/Contents/Resources/Java/kepler.sh is not executable. I have to change mode to run it.</p> Bug #5328 (Resolved): 2.2rc2 - standalone module manager won't starthttps://projects.ecoinformatics.org/ecoinfo/issues/53282011-02-26T01:40:00ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>On mac 10.6 and windows XP, both with java 1.6, I can't get the standalone module manager application to start. On windows I tried both shortcuts and the executable itself. I didn't have this problem in the last rc.</p> Bug #5326 (Resolved): 2.2rc2 - upgrade config file bug workaround moves KeplerData/modules to Kep...https://projects.ecoinformatics.org/ecoinfo/issues/53262011-02-25T22:03:56ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>The workflow-around for the configuration file bug is to move a user's existing KeplerData/modules to KeplerData/modules.old during the first launch of 2.2. However I think we should instead just do something along the lines of moving each module's configuration dir to a configuration.old. The issue is that more than just config files reside in KeplerData/modules. E.g. the coreDB and provenance databases.</p> Bug #5325 (Resolved): 2.2rc2 - documentation problemshttps://projects.ecoinformatics.org/ecoinfo/issues/53252011-02-25T21:26:09ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>1) Most links in the pdfs don't work - you just see blue text.</p>
<p>2) User Manual Section 6 doesn't include changes to 6.0WorkingWithDatasets.doc. My guess is you didn't build the user manual from the individual chapters but instead edited a copy of the 2.1.0 version (?). If you're taking that route, you'll have to be careful with keeping TOC in sync and include changes from other files more recent than 2.1.0 docs:</p>
<p><del>rw-r--r-</del> 1 derik derik 28614618 Sep 28 13:13 KeplerUserManual-2.1.0.pdf<br /><del>rw-r--r-</del> 1 derik derik 27385066 Sep 28 13:13 KeplerUserManual-2.1.0.doc<br /><del>rw-r--r-</del>@ 1 derik derik 2173091 Jan 11 13:53 6.0WorkingWithDatasets.doc<br /><del>rw-r--r-</del> 1 derik derik 214528 Jan 19 13:07 A.BModules.doc<br /><del>rw-r--r-</del> 1 derik derik 28160 Feb 22 17:15 Title Page.doc</p>
<p>3) Remote Copy links of Getting Started Guide and Actor Reference link to 1.0.0 versions.</p>
<p>4) Copyright link to copyright.htm is 2003-2010. Should update to 2011.</p> Bug #5318 (Resolved): 2.2.0 release testinghttps://projects.ecoinformatics.org/ecoinfo/issues/53182011-02-23T00:03:50ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>David asked me to create a list of less obvious things to test for 2.2. Obviously this isn't comprehensive; please test other things as you go.</p>
<p>Note: you have to download the installer for 2.2; upgrading to 2.2 via the module manager within 2.1 or 2.0 will not work. Also note the 2.2 installer includes a standalone Module Manager app.</p>
<p>Test Kepler 2.0.0 to 2.2.0 transition:<br />---------------<br />Developers, remove any trunk generated artifacts: rm -rf ~/.keeper ~/KeplerData;<br />Start Kepler-2.0.0 installed on your machine from the 2.0 installer.<br />Components=>Sources=>check-mark the kepler repository as a Search item. This will cause a write of ~/KeplerData/modules/repository/configuration/configuration.xml.<br />Test Components search. Use <a class="external" href="http://kepler-dev.nceas.ucsb.edu/kepler/">http://kepler-dev.nceas.ucsb.edu/kepler/</a> to verify your results.<br />Test Data search. E.g. for aphid. Drag out a data source.<br />Create a simple workflow, e.g. SDF w/ 1 iteration, String Constant=>Display. Execute. Save to kar. Export to xml.<br />Quit 2.0.0. <br />Install 2.2.0 from the 2.2 installer.<br />Launch 2.2.0, click the Sources button. Verify this dialog comes up, and that your old, incompatible config file(s) in KeplerData have been moved out of the way, into a separate directory.<br />Navigate to Sources=>Preferences=>KAR Preferences and select strict.<br />Attempt to open the kar you saved in 2.0.0. Obligue the dialog, restart into 2.0.0.<br />A known limitation is that to return to 2.2.0 you should not use the Module Manager inside Kepler, use the standalone Module Manager application that ships with 2.2.0 to restart into 2.2.0.</p>
<p>Test Kepler 2.1.0 to 2.2.0 transition.<br />--------------------<br />Similar to above, but first upgrade your installed version of 2.0.0 to kepler-2.1.0 and/or reporting-2.1.0 via the 2.0.0 module manager. <br />Create a reporting 2.1.0 kar by exporting a run from the Workflow Run Manager. Attempt to open this kar from 2.2.0 in Strict mode, etc.</p>
Misc 2.2 tests:<br />----------------
<ul>
<li>Test the built in Module Manager.</li>
<li>Test each OS Installer.</li>
<li>Test all outreach demos.</li>
<li>Check Help=>About version number. Check Help=>Kepler Documentation -- test all links.</li>
<li>Create, save, right-click rename on canvas, export, run and open a workflow.</li>
<li>Search the Kepler repository via Components tab.</li>
<li>Search for remote data using Data tab.</li>
<li>Right-click on a kar and upload to the Kepler repository -- ideally the workflow has documentation, serves as a good example, and may be left on the repository for users, otherwise subsequently delete it. Contact myself, jing or ben for help deleting.</li>
<li>Outline tab - drag a workflow component out to canvas. Then delete it.</li>
</ul> Bug #5311 (Resolved): 2.2.0rc1 - remote data sources don't workhttps://projects.ecoinformatics.org/ecoinfo/issues/53112011-02-15T21:56:43ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>In 2.2.0rc1 installed from the installer, remote data sources don't work. <br />I discovered this when trying to open PythonGenericDialog.xml demo workflow.<br />It also happens when you search the Data tab and try to drag out a data source.</p>
<p>The error message you see comes from EcogridDataCacheItem and is:<br />There has been a problem accessing the remote data<br />java.lang.String cannot be cast to [B</p>
<p>This doesn't appear to happen from trunk, or from 2.2.0 launched from the module manager. I'm not clear on why this is...</p> Bug #5310 (Resolved): 2.2.0rc1 - Documentation link problemshttps://projects.ecoinformatics.org/ecoinfo/issues/53102011-02-15T21:36:57ZDerik Barseghianbarseghian@nceas.ucsb.edu
Some issues with Help->Documentation in 2.2.0rc1:
<ul>
<li>None of the Local Copy links to documentation (at Help->Kepler Documentation) work.</li>
<li>The Remote Copy links point to 1.0 docs.</li>
<li>The workflow links don't work</li>
</ul> Bug #5309 (Resolved): 2.2.0rc1 - Preferences and Components Search (configuration) issuehttps://projects.ecoinformatics.org/ecoinfo/issues/53092011-02-15T21:34:41ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>I've given the mac installer a try and I've run into the configuration file issue - my ~/KeplerData/repository/configuration/configuration.xml does not contain the new properties authorizationPath or authenticatedquerypath and I get errors as a result. I also don't see old versions of my configuration files -- I believe the workaround that you implemented for <a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5129">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5129</a> was that the old configs are supposed to be moved out of the way on the first startup of 2.2.</p>
<p>Here's what I did:<br />cd ~/kepler.modules/build-area/; ant clean-all; rm -rf ~/KeplerData;<br />Start up previously installed Kepler 2.1.0 from Applications<br />Change my Components Sources to search the Kepler repository<br />Change Kar Preferences to Strict<br />Search for sdf. Create and run a simple workflow<br />Quit<br />Start installer 2.2.0rc1 from Applications<br />Clicking on the Sources button gives the below error. Attempting to search Components also gives an error.</p> Bug #5190 (Resolved): 6.0WorkingWithDatasets describes OPeNDAP but not DataTurbine actorhttps://projects.ecoinformatics.org/ecoinfo/issues/51902010-09-25T02:07:47ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>Chapter 6 describes the OPeNDAP actor, but not the DataTurbine actor. Since both are included modules in the kepler suite, both should be described.</p> Bug #5161 (Resolved): can't always use Module Manager to change to an older patch of a suitehttps://projects.ecoinformatics.org/ecoinfo/issues/51612010-08-25T23:27:04ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>If a module is published<br />and a patched version of this module is published<br />and the user has downloaded both<br />and the user uses the MM to change to the original version of the module<br />Kepler will restart and automatically use the newest patch of the module that's available on the local system, with no notice.</p>
<p>I would expect a user would be able to intentionally change to the old patch, especially since it's visible in the MM's gui.<br />Even if 'Automatically download new patches' is left on, they should get the prompt for an update on restart, I would think.</p>
<p>Is this a known issue, compromise, or intentional choice the MM is currently making? It's not strictly necessary for 2.1, because the Import Module Dependencies feature does allow this (and that's when it's <strong>really</strong> necessary). Also since the IMD feature can prompt a user to do this (restart into an older patch), I think a user would think they could also use the MM to do it.</p> Bug #5125 (Resolved): Add feature to do a one-step revert of a botched update from outside of Keplerhttps://projects.ecoinformatics.org/ecoinfo/issues/51252010-08-04T19:27:10ZSean Riddleswriddle@gmail.com
<p>If a patch does not work correctly, it is possible that Kepler will fail to restart after the patch's installation. The way to handle this (which will be made simpler in the future) is to run the module manager standalone and use it to restore to a working configuration.</p>
<p>The module manager should have an easy way to rollback the last patch that was applied, returning the user to the working configuration they were just in.</p>
<p>This should probably also disable automatic updates.</p> Bug #5101 (Resolved): Composite Actor windows show wrong title after workflow Renamehttps://projects.ecoinformatics.org/ecoinfo/issues/51012010-07-21T20:23:11ZDerik Barseghianbarseghian@nceas.ucsb.edu
<p>If you use the canvas Rename context menu to rename your workflow that contains composite actors, then Open Actor to see a composite actor's contents in a new window, this new window's title bar shows old_workflow_name#CompositeActor instead of new_name#CompositeActor. It doesn't matter if the Composite has been instantiated before or after the rename (so at least it's consistent).</p>
<p>You must currently Save or Save Archive before the composite actor windows use the right name in the title bar.</p> Bug #5084 (Resolved): Allow test releases in the same location as actual releases.https://projects.ecoinformatics.org/ecoinfo/issues/50842010-07-08T21:26:27ZDavid Welkerwelker4kepler@gmail.com
<p>(13) Allow test releases in the same location as actual releases.</p>
<p>Right now, the Kepler module manager can be configured to look at a test-release location rather than the actual release location. However, this is not necessarily ideal because the resources available in the test-release location may not always be identical to the actual release location, or if it is, this requires maintenance and duplication of resources. A possible solution would be to create a flag of some sort (which might be indicated by the presence of a special file, for example) so that test-modules are not shown in the module manager, unless the user selects an appropriate check box or menu item. In this way, test modules would be guaranteed to have access to the same resources as released modules.</p> Bug #5070 (Resolved): Changing the "Available Modules" tab in the Module Manager to "Available Su...https://projects.ecoinformatics.org/ecoinfo/issues/50702010-07-01T03:48:18ZDavid Welkerwelker4kepler@gmail.com
<p>(6) Changing the "Available Modules" tab in the Module Manager to "Available Suites and Modules"</p>
<p>This is a minor change that could be made to make the GUI more clear.</p>