[kepler-dev] 2.1.0 release testing
Derik Barseghian
barseghian at nceas.ucsb.edu
Wed Sep 15 19:25:37 PDT 2010
On Sep 15, 2010, at 5:43 PM, Christopher Brooks wrote:
> 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).
Thanks. We should probably include these on the build instructions page.
>
> 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
When you ant change-to -Dsuite=kepler-2.1, you will download the set
of modules listed in kepler-2.1's modules.txt (a set of 2.1 and 2.0
modules). As it is now, you won't get anything with a patch number
(the third number) in its name. The published version zips, which
include patch numbers, e.g. kepler-2.1.0.zip, are what is downloaded
when you use the Module Manager to change to kepler-2.1.0. The Module
Manager then unzips them into the respective 2.1.0 dirs. Keep in mind
kepler-2.1.0 depends on a set of 2.1.0 and 2.0.0 modules.
The published zips are here in svn:
https://code.kepler-project.org/code/kepler/releases/released/
or in the case of the test area, here:
https://code.kepler-project.org/code/kepler/releases/test-releases/
The non-developer installer-version kepler user will never have the
2.0 or 2.1 directories.
Hope that explains it...
>
>>> 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?
>
I forgot about the welcome window. I'll have to look for that...
>>>
>>>> * 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.
>
How about if I remove that code and parameter for adding back the old
Save and Save As menu items, but add a new Export... option that does
what Save As used to do (save the xml). This shouldn't be hard.
>
>
>>>
>>>> * 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.
Ok, to create a proper Save we probably need a KAR manager that keeps
a mapping between kars and tableauFrames. This will push the release
at least a week or two into the future.
>>>
>>>> 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.
Not to sidetrack the discussion, but is it critical to keep the name
of the model in the MoML? It seems like it would be nice if we could
simplify and just use the filename as the model name, and not store it
in the MoML. When someone does an OS level rename of a file, the model
name no longer matches up.
>
>>>
>>>
>>>> 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.
A benefit of keeping your kars in MyWorkflows, or another "local
repository" that you've added through the preferences, is that they
can show up in the library tree.
>
>>>> * 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.
>
Ok, I'll try to track that stuff down.
I started looking at the bad links earlier today. I got the impression
the installer/installation process may make some of these changes, and
that this will require new code to allow for releases where we don't
use the installer.
>>>> * 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.
Ok. It will make the upgrade a smaller download for the user if they
can just keep using ptolemy-8.0.0...
>
>>>> * 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!)
>
Hope it doesn't recur.
>
> _Christopher
>
Derik
>>>> _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