[kepler-dev] 2.1.0 release testing

Christopher Brooks cxh at eecs.berkeley.edu
Wed Sep 15 17:43:52 PDT 2010


Hi Derik,
Cool!
Thanks for the instructions.  It looks like the module manager is working reasonably
well, though there are some minor issues.  I think the "Save As" problem is
a potential blocker.  I'm willing to give up on not being able to save .xml files,
but I think removing saving as a .xml is a big mistake which will be regretted.  Removing functionality
never goes over well with users.  There are issues with the demos, but other
than that, it 2.1 looks like it is coming along.

Details are below

I updated
https://kepler-project.org/developers/teams/build/kepler-2.1-release-roadmap
with notes about how to run 2.1/

On 9/15/10 12:26 PM, Derik Barseghian wrote:
> Sorry, I forgot to add to the starting fresh list, before the last step:
>>>>>>> change releaseLocation in module-manager's configuration.xml to: https://code.kepler-project.org/code/kepler/releases/test-releases

Thanks, I edited
module-manager-2.1/resources/configurations/configuration.xml

I added notes about this to the 2.1 release roadmap (above).

More comments below.

> On Sep 15, 2010, at 12:22 PM, Derik Barseghian wrote:
>
>> Hi Christopher,
>>
>> Thanks for testing.
>>
>> On Sep 15, 2010, at 8:03 AM, Christopher Brooks wrote:
>>
>>> Hi Derik,
>>> Precisely how should I test the 2.1.0 release?
>>>
>>> I started up the devel head, below are some comments.
>>>
>>> * I updated my tree with:
>>> cd kepler/build_area
>>> rm -rf ~/.kepler ~/KeplerData
>>> ant clean-all update run
>>>
>>> * The version number in the splash screen says 2.0.0, is this correct?
>>> * Help | About shows the version number as 2.0.0, is this correct?
>>> We released 2.0, the version in the devel tree should be updated.
>>>
>>> * How would I know that I'm running 2.1.0?
>>>
>>
>> Starting fresh:
>> rm -rf ~/KeplerData ~/.kepler;
>> mkdir kepler.modules.2.1;
>> svn co https://code.kepler-project.org/code/kepler/trunk/module/build-area;
Actually, this should be "modules" not "module"

svn co https://code.kepler-project.org/code/kepler/trunk/modules/build-area

>> cd build-area;
>> ant change-to -Dsuite=kepler-2.1;
>> ant clean-all run;
>>

BTW - After doing the module manager update, why do I have 2.0 and 2.0.0 versions of modules?
In my mind, 2.0 == 2.0.0, much like 2.0 == 2.00.

I also have 2.1 and 2.1.0 versions.  When I did the change-to, shouldn't
just the 2.1 modules have come over?

What is the difference between ptolemy-8.0 and ptolemy-8.0.0?

The current size of the 2.1 directory is 1.1gig, which is huge!

Here's what I have:

bash-3.2$ cd ~/src/kepler2.1
bash-3.2$ ls
actors-2.1			io-2.0.0
actors-2.1.0			io-2.0.0.zip
actors-2.1.0.zip		job-2.0
apple-extensions-2.0		job-2.0.0
apple-extensions-2.0.0		job-2.0.0.zip
apple-extensions-2.0.0.zip	kepler-2.1
authentication-2.1		kepler-2.1.0
authentication-2.1.0		kepler-2.1.0.zip
authentication-2.1.0.zip	kepler-tasks-2.1
authentication-gui-2.0		kepler-tasks-2.1.0
authentication-gui-2.0.0	kepler-tasks-2.1.0.zip
authentication-gui-2.0.0.zip	loader-2.0
build-area			loader-2.0.0
common-2.1			loader-2.0.0.zip
common-2.1.0			module-manager-2.1
common-2.1.0.zip		module-manager-2.1.0
component-library-2.0		module-manager-2.1.0.zip
component-library-2.0.0		module-manager-gui-2.1
component-library-2.0.0.zip	module-manager-gui-2.1.0
configuration-manager-2.1	module-manager-gui-2.1.0.zip
configuration-manager-2.1.0	opendap-2.0
configuration-manager-2.1.0.zip	opendap-2.0.0
core-2.1			opendap-2.0.0.zip
core-2.1.0			outreach-2.0
core-2.1.0.zip			outreach-2.0.0
data-handling-2.0		outreach-2.0.0.zip
data-handling-2.0.0		ptolemy-8.0
data-handling-2.0.0.zip		ptolemy-8.0.0
dataturbine-2.0			ptolemy-8.0.0.zip
dataturbine-2.0.0		r-2.0
dataturbine-2.0.0.zip		r-2.0.0
directors-2.0			r-2.0.0.zip
directors-2.0.0			repository-2.1
directors-2.0.0.zip		repository-2.1.0
ecogrid-2.1			repository-2.1.0.zip
ecogrid-2.1.0			sms-2.1
ecogrid-2.1.0.zip		sms-2.1.0
event-state-2.0			sms-2.1.0.zip
event-state-2.0.0		ssh-2.0
event-state-2.0.0.zip		ssh-2.0.0
gui-2.1				ssh-2.0.0.zip
gui-2.1.0			util-2.0
gui-2.1.0.zip			util-2.0.0
io-2.0				util-2.0.0.zip

>> The splash images will show 2.1.0.
>> To change from the svn checkout of kepler 2.1 to the test published version of 2.1.0, use the Module Manager in the GUI to download and restart into kepler-2.1.0.
>> Note that 2.1 currently relies on a mix of 2.1 and 2.0 modules (and the published 2.1.0 on a mix of 2.1.0 and 2.0.0). We've decided to not republish as 2.1 those 2.0 modules that have not changed.

* The splash screen shows Kepler-2.1, but the Welcome window still shows Kepler-2.0 after using the Module Manager?

>>
>>> * How do I save a model as an .xml file? If you are going to remove
>>> functionality, then you should probably change the version number to 3.0.
>>> I don't want to edit some file in the configuration, I want to be able to
>>> save models as MoML from the command line.
>>>
>>
>> You can't through the gui, unless you set true that configuration.xml parameter I added for you.
>> How were you saving models from the command line? I would hope whatever method you were using would still work. I just removed the File menu options for the old Save and Save As, it seems wrong if
>> code running in headless was invoking those gui menu items.

Sorry, I mistyped.  I want to be able to save .xml files from the GUI.  I mistyped
command line.
Save As should have an option to save out just the .xml file.  We should also
be able to save as pdf etc.  Removing this option breaks backward compatibility, thus
2.1 is not backward compatible with 2.0.  The user experience is different, I used
to be able to do something that I can no longer do.

The problem is that if I want to test if a bug is Ptolemy specific, I'll need to
get at the .xml file so that I can open it in Vergil.  I can either:
1) Dig through 500 Mb of email and find the right incantation
or
2) unjar the kar.

I'll probably go with #2.

I think this is pretty serious mistake, but it is only annoying to me.

I think that this is not a 2.1 release though, it is 3.0.



>>
>>> * Where is "Save"? If I modify a model and I want to save my changes, I don't
>>> want a dialog, I just want to update my model.
>>
>> Yes, this is a major limitation of the current system, we don't have a KAR manager that provides mappings between windows and kars, so there's currently no Save function, only Save As...
>> 2.0 has this same limitation with regards KARs, it was just less in your face since the old Save and Save As options for xml were the defaults, so in discussing with others we thought we could
>> release 2.1 with this limitation.

This is a major usability bug.  Should we talk about fixing this before releasing?
This will drive users who are actively developing models nuts.  We need a Save that
just uses the previous choices.
>>
>>> 1. Start Kepler
>>> 2. Drag in any actor
>>> 3. Select Save As (this is good, the model has not been saved yet)
>>> 4. Get prompted for a model name, hit ok (this is ok, though why the model
>>> name could be different from the file name is probably an issue)
>>
>> A KAR is just a container for (a) models, so while it can be confusing, it should be ok for the user to make the choice of having the KAR named differently.
>> Even more confusing imo is that MoML stores the name of the model in the model, so if the filename.xml is ever changed, the model name shown in the gui window differs. I discussed this in more
>> detail in a bug somewhere, but I can't find it atm.

Right, the MoML model name matching the name of the file can be an issue.
In general, they should match.  This can be a problem with code gen.  In
general, I prefer that objects have the same name, so a demo Foo will be
in demo/Foo/Foo.xml.  This has saved me quite a bit of time over the years.

>>
>>
>>> 5. Get prompted for semantics types. (FIXME: the help button does nothing)
>>> Hit cancel because who knows what this button does
>>
>> Yes this button does nothing for me as well. Shawn or Sean, was this ever implemented? It would be better to not have the button if not.
>>
>>> 6. Get prompted for a file name. (FIXME: I want to save as a .xml, not
>>> a .kar). Is it a problem if the model name and the file name do not match?
>>> Hit OK.
>>>
>>> 7. Add another actor.
>>> 8. Go to File. Where is Save? I just want to update my model.
>>> 9. Ok, try Save As.
>>> 10. Why am I prompted for the name of the workflow again? I just gave
>>> this information? Hit OK.
>>
>> Again, this is because we lack a KAR manager, so we don't know that this thing you're saving was previously saved to a KAR.
>>
>>> 11. Why am I prompted for Semantic Info again? I just gave this info.
>>
>> I agree this is annoying, this is because your model still lacks a semantic type. The system should probably offer an explicit "no", and keep track of that so you're not prompted again.
>> Personally I don't think we should prompt for Semantic Annotation during saves, as it probably confuses/slows down a new user, and it slows down an advanced user.
>> You can do this from the canvas context menu.

Right, I just saw your most recent post:
> Just a follow-up re: the semantic annotation prompt during the save process. We discussed this on irc,
 > and I've turned it off now in 2.1 and trunk, but have not republished the gui module yet
> (so the change won't be in effect if you test the test publication, kepler-2.1.0). I'll probably
 > hold off on republishing for awhile so as not to confuse things.


>>> 12. Why am I prompted for the filename again? I just gave this info.
>>>
>>
>> We don't know which KAR this is.
>>
>>> Regardless of being able to save just a MoML file, we need Save back.
>>>
>>
>> There was never a Save for KARs. The current Save As used to be called Save Archive, but it did the same thing (i.e. it did a Save As for a KAR).

Ok, then we need Save for KARs.  Users like to save their state as they go along.  Think about
if you were using Word and you needed to go through so many steps just to save your
state because you were worried that things would crash or something.  This
will drive users nuts.

BTW - I don't like how Save defaults to KeplerData/Workflows/MyWorkflows.
This smacks of a closed-world system.  Most users have projects in their
own directories.  Also, If I use SaveAs and change to ~/src, then the
next time I use SaveAs, I'm back at ~/KeplerData/Workflows/MyWorkflows.
I'm not sure - this could be a bug in the underlying Ptolemy code.

>>> * I can't run the demos. If I do Help | Kepler Documentation and click on the
>>> Hello World link, I get:
>>> java.io.FileNotFoundException: /Users/cxh/src/kepler/outreach/resources/demos/getting-started/04-HelloWorld.xml (No such file or directory)
>>> I think the problem is that the demos are in outreach/workflows, not outreach/resources
>>
>> You mean the Local links for the different docs? Yeah they don't work for me either. I'm not familiar with how those links are created, but I can look into it. They are the same but work in 2.0.0.

In the devel trunk, we probably need to update the Kepler Documentation page.
Either:
1) Fix the links in the file
2) Make the devel trunk match the 2.0 branch if the demos are in KeplerData.

Note that in 2.1.0, the Kepler Documentation page is different than the
same page in the devel trunk.

"All listed demos are in the KeplerData/workflows/outreach-2.0.0/demos/getting-started which can be found in your home directory"
I don't have that directory.

>>> * What version of Ptolemy are you planning on releasing. The svn head of Ptolemy has not
>>> been cleaned and it not ready for primetime. I could see about cleaning it, but I'd
>>> need to know when you want a clean version that I can tag.
>>
>> I'm planning on using the same version of ptolemy for kepler-2.1.0 that kepler-2.0.0 used, ptolemy-8.0.0, which I believe is r58234.

Offhand, I can't think of any mission critical Ptolemy bugs that have been fixed since then, but who knows.
I could take a look over the next day or two.

>>> * Is 2.1.0 based on the 2.0 release branch or on the current kepler devel head? If it
>>> is on the kepler devel head, have the source files been cleaned?
>>
>>
>> The 2.1 branches are based on the 2.0 branches (there really isn't a single branch for each, it's on a per module basis).
>> We decided 2.1 would be a special case, and that in the future we'll be cutting releases (2.2, 2.3...) from trunk.

Sounds good!

>>> * When I click on the Tools | Module Manager, I get:
>>>
>>> [run] Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.initActiveModulesList(CurrentSuitePanel.java:93)
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.initComponents(CurrentSuitePanel.java:108)
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.<init>(CurrentSuitePanel.java:86)
>>> [run] at org.kepler.modulemanager.gui.ModuleManagerPane.<init>(ModuleManagerPane.java:41)
>>> [run] at org.kepler.modulemanager.gui.ModuleManagerAction.actionPerformed(ModuleManagerAction.java:59)
>>> [run] at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882)
>>> [run] at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202)
>>> [run] at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
>>> [run] at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
>>> [run] at javax.swing.AbstractButton.doClick(AbstractButton.java:334)
>>> [run] at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1050)
>>> [run] at apple.laf.CUIAquaMenuItem.doClick(CUIAquaMenuItem.java:119)
>>> [run] at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1091)
>>> [run] at java.awt.Component.processMouseEvent(Component.java:5602)
>>> [run] at javax.swing.JComponent.processMouseEvent(JComponent.java:3129)
>>> [run] at java.awt.Component.processEvent(Component.java:5367)
>>> [run] at java.awt.Container.processEvent(Container.java:2010)
>>> [run] at java.awt.Component.dispatchEventImpl(Component.java:4068)
>>> [run] at java.awt.Container.dispatchEventImpl(Container.java:2068)
>>> [run] at java.awt.Component.dispatchEvent(Component.java:3903)
>>> [run] at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256)
>>> [run] at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936)
>>> [run] at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866)
>>> [run] at java.awt.Container.dispatchEventImpl(Container.java:2054)
>>> [run] at java.awt.Window.dispatchEventImpl(Window.java:1801)
>>> [run] at java.awt.Component.dispatchEvent(Component.java:3903)
>>> [run] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
>>> [run] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
>>> [run] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
>>> [run] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
>>> [run] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
>>> [run] at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
>>> [run] Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.initActiveModulesList(CurrentSuitePanel.java:93)
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.initComponents(CurrentSuitePanel.java:108)
>>> [run] at org.kepler.modulemanager.gui.CurrentSuitePanel.<init>(CurrentSuitePanel.java:86)
>>> [run] at org.kepler.modulemanager.gui.ModuleManagerPane.<init>(ModuleManagerPane.java:41)
>>> [run] at org.kepler.modulemanager.gui.ModuleManagerAction.actionPerformed(ModuleManagerAction.java:59)
>>> [run] at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882)
>>> [run] at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202)
>>> [run] at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
>>> [run] at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
>>> [run] at javax.swing.AbstractButton.doClick(AbstractButton.java:334)
>>> [run] at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1050)
>>> [run] at apple.laf.CUIAquaMenuItem.doClick(CUIAquaMenuItem.java:119)
>>> [run] at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1091)
>>> [run] at java.awt.Component.processMouseEvent(Component.java:5602)
>>> [run] at javax.swing.JComponent.processMouseEvent(JComponent.java:3129)
>>> [run] at java.awt.Component.processEvent(Component.java:5367)
>>> [run] at java.awt.Container.processEvent(Container.java:2010)
>>> [run] at java.awt.Component.dispatchEventImpl(Component.java:4068)
>>> [run] at java.awt.Container.dispatchEventImpl(Container.java:2068)
>>> [run] at java.awt.Component.dispatchEvent(Component.java:3903)
>>> [run] at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256)
>>> [run] at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936)
>>> [run] at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866)
>>> [run] at java.awt.Container.dispatchEventImpl(Container.java:2054)
>>> [run] at java.awt.Window.dispatchEventImpl(Window.java:1801)
>>> [run] at java.awt.Component.dispatchEvent(Component.java:3903)
>>> [run] at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
>>> [run] at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
>>> [run] at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
>>> [run] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
>>> [run] at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
>>> [run] at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
>>>
>>
>> I'm not seeing this on 2.1 or trunk. Can you try again from the 2.1 branch?

The problem does not appear in the Kepler-2.1 branch.

I checked out a clean tree from the devel head and I can't replicate the bug.
So, it must have been a problem with my tree. (yay!)


_Christopher

>>> _Christopher
>>>
>>
>> Derik
>>
>>>
>>> On 9/14/10 5:40 PM, Jing Tao wrote:
>>>> Hi, everyone:
>>>>
>>>> Derik figured out the reason why command line didn't work: we should setup uploadToServer to true in reporting configuration.xm.
>>>>
>>>> After set that value to true, the uploading worked.
>>>>
>>>> Thanks,
>>>>
>>>> Jing
>>>>
>>>> Jing Tao
>>>> National Center for Ecological
>>>> Analysis and Synthesis (NCEAS)
>>>> 735 State St. Suite 204
>>>> Santa Barbara, CA 93101
>>>>
>>>> On Tue, 14 Sep 2010, Jing Tao wrote:
>>>>
>>>>> Hi, Derik:
>>>>>
>>>>> I tested some items:
>>>>>
>>>>> 1. Using the Module Manager to change suite from kepler 2.1.0 to reporting
>>>>> 2.1.0. It worked.
>>>>> 2. Running, saving and uploading some workflows in demo directory. They
>>>>> worked.
>>>>> 3. Using command line to run a workflow kar file and upload the result to
>>>>> a server. However no uploading happened, no error message. I tried the
>>>>> same command on the trunk kepler. It worked.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jing
>>>>>
>>>>> Jing Tao
>>>>> National Center for Ecological
>>>>> Analysis and Synthesis (NCEAS)
>>>>> 735 State St. Suite 204
>>>>> Santa Barbara, CA 93101
>>>>>
>>>>>> On Tue, 14 Sep 2010, Derik Barseghian wrote:
>>>>>>
>>>>>>> Devs,
>>>>>>>
>>>>>>> Kepler 2.1.0 and Reporting, Workflow-Run-Manager, Provenance, and Tagging 2.1.0 are published to the test area and ready for release testing. If you could please do some testing and let me know
>>>>>>> your results, we should be able to release as soon as 1) the Kepler Leadership team approves the releases 2) the KNB Metacat is upgraded and 3) a final change is made to remove the Dev server
>>>>>>> listings in the Components and Data preference tabs. I'd like to release before the end of this week.
>>>>>>>
>>>>>>> Some good tests:
>>>>>>> * Running, saving, uploading to Dev, etc. your and the demo workflows.
>>>>>>> * Using the Module Manager to change between suites and Kepler 2.0.0 and 2.1.0, and testing each suite's functionality
>>>>>>>
>>>>>>> In order to test, change releaseLocation in module-manager's configuration.xml to: https://code.kepler-project.org/code/kepler/releases/test-releases
>>>>>>>
>>>>>>> Note that Kepler 2.1 now depends on a mix of 2.1 and 2.0 modules, so be sure you're up to date if you also want to test the 2.1 branch versions to see how they play along with the 2.1.0 releases.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Derik
>>>>>>> _______________________________________________
>>>>>>> Kepler-dev mailing list
>>>>>>> Kepler-dev at kepler-project.org
>>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Kepler-dev mailing list
>>>> Kepler-dev at kepler-project.org
>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>
>>> --
>>> Christopher Brooks, PMP University of California
>>> CHESS Executive Director US Mail: 337 Cory Hall
>>> Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
>>> ph: 510.643.9841 fax:510.642.2718 (Office: 545Q Cory)
>>> home: (F-Tu) 707.665.0131 cell: 707.332.0670
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670


More information about the Kepler-dev mailing list