[kepler-dev] 2.1.0 release testing
Derik Barseghian
barseghian at nceas.ucsb.edu
Thu Sep 16 13:16:02 PDT 2010
Christopher,
More responses inline...
On Sep 16, 2010, at 7:53 AM, Christopher Brooks wrote:
> Hi Derik,
>
> The summary is, I'd like to see Save added back in before 2.1 is
> released.
> I'd also like to see a away to export .xml files, but that is less
> critical.
>
> Further comments below.
>
> _Christopher
Ok. I'm going to file a set of new 2.1 targeted bugs today, including
one to implement Save for KARs.
>
> On 9/15/10 7:25 PM, Derik Barseghian wrote:
>>
>> 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.
>
> Feel free to move the 2.1 instructions off the roadmap page. I just
> wanted to
> have them somewhere
>
>
>>> 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.
>
> This seems very odd. It looks like the difference between ptolemy-8.0
> and 8.0.0 is that 8.0 has src/ and 8.0.0 has ptolemy-8.0.jar (a 54Mb
> jar file)
>
> I think the patch numbering system needs to be rethought out. I
> don't understand
> why I would have two copies of essentially the same code.
>
I think the salient point is that published versions of modules are
different and distinguishable from what we develop on, and that this
disk space burden is only on developers. When you use the Module
Manager to download and then run the published versions, these are
often different from what is currently in the development area (i.e.
where unpublished changes may reside). If no developer has changed the
code since publication, then yes, the source will be the same, and it
would be possible to not download what a developer already has, but
you'd have to be very careful in your determining of this, and do
clever things on the local side, e.g. wrt modules.txt files, and
unless this is done very well I suspect it will make things very
confusing. It seems like a lot of work for a very small benefit, and
will likely be challenging to do right, meaning we'll have a lot of
new bugs in the meantime.
>> 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.
>
> This is good.
>
>> Hope that explains it...
>
> I still don't see why the developer version would have a jar file
> copy of ptolemy-8.0?
This is only when the developer is running the published version of
kepler.
> What's the point? Developers need the source. Will it always be
> the case that
> the jar file is in the .0 directory? When I start up Kepler, which
> one is used?
>
I get an idea of what I'm running by:
cat build-area/current-suite.txt
If this file says unknown, I:
cat build-area/modules.txt
which can gives a rough idea. If the topmost suite doesn't self-
reference, it won't be shown, which is confusing.
From within the gui, check the Current Suite tab using the Module
Manager.
This stuff is better discussed with David though.
>>>>> 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.
>
> Thanks, I'd be very happy with Save and Save As and an Export menu
> that saves a .xml.
>
Ok great. I currently plan to make the Export do what Save As... used
to do.
I.e. are you going to be unhappy that there will exist no accelerator
that does a "Save" for a model xml file alone? :)
I'll also try to override the ptolemy control S and control A
accelerators to invoke the new KAR actions.
>>>>>
>>>>>> * 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.
>
> Pushing the release back to get the Save/Save As functionality
> working is worth it.
>
>>>>>
>>>>>> 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.
>
> Filenames are not very relevant as models can be found in many
> places, including the classpath,
> which means the name could be a URL. Models can also exist that
> don't have file names.
> Adding the filename to the MoML seems a little odd, I'm not sure how
> that would solve the
> renaming issue.
I wasn't suggesting putting the filename in the model, yes, that link
would constantly break. What I'm saying is it would be nice if the
model didn't contain the name at all, and the filename could be
thought of as the name. When a person does a rename at the OS level of
their model, and then open the model, it still contains within it its
old name, but this often isn't apparent until something bad happens.
Our guis and systems sometimes act as if the filename is the model
name, when really they're allowed to be different.
But removing the name from the model will likely cause a lot of
problems. As you say, the model may not even be a file, so what to
call it then? One compromise would be to make it very clear in vergil
and kepler what the model name is, distinct from the filename. E.g.
display it like a changeable title.
>
> When dealing with a large number of models, I've found it useful if
> the model name and the filename matches.
> There were other reasons (which I forget), but I think the primary
> reason is code generation.
>
Yes, I avoid renaming my models from my OS because of the confusion it
causes.
>>
>>>
>>>>>
>>>>>
>>>>>> 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.
>
> That's a solution to the library problem, but there is no indication
> of that anywhere.
> I certainly did not know that. I'm not sure of a good solution, but
> this should be
> made more obvious to the user. Perhaps a bit of text in the Save/
> Save As dialog someday?
> Or, put a file named
> "PlaceYourModelsHereAndTheyWillAppearInTheLibraryTree.txt" Or
> something.
>
I agree this should be made more clear.
> The Ptolemy solution is that we have ~/.ptolemyII/UserLibrary.xml
> which can be opened by the
> user and edited. The user can add arbitrary models and actors to
> that directory. This solution
> is not perfect, but one advantage over ~/KeplerData/Workflows/
> MyWorkflows is that it allows
> the user to have actors or models in arbitrary locations.
>
> I think both Kepler and Ptolemy need a better solution for discovery
> of user supplied .class
> files. I'd be willing to work on a design. One common use case is
> that a model developer wants
> to deploy a set of custom actors and models. The nice thing about
> your system is that in theory
> the model user could just put a .kar file in ~/KeplerData/Workflows/
> MyWorkflows. However, this
> means that each user has to do this separately, which is a problem
> in a shared environment.
> I suppose the Kepler system itself could be updated in a shared
> environment, though I'm not sure
> how easy that could be. Anyway, food for thought.
Yeah, this needs work.
One idea is they use the same remote repository, and we make
improvements such that remote repositories are easier to work with.
>
>>>>>> * 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.
>
> I think the demos need to be much more accessible from the UI.
> Perhaps we need to hack up
> the HTML code so that <a href="$HOME/KeplerData/workflows/
> outreach-2.0.0/demos/getting-started/04-HellowWorld.xml">Hello
> World</a>
> works. This should not slow down the 2.1 release, but I think we
> are really missing the
> point by not having demos that are accessible via links.
Right. I'll hack the html if I have to, but hopefully I can figure out
if/how these links are autogenerated and utilize/tweak that code.
>>
>>>>>> * 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...
>
> I'm still concerned about the ptolemy-8.0 vs ptolemy-8.0.0 issue.
> There will be confusion.
>
Just for developers. :) Hopefully my explanation has helped? We
probably need a webpage that succinctly explains it.
>>
>>>
>>>>>> * 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.
>
> Me too!
>
> Thanks,
>
> _Christopher
Derik
>
>>
>>>
>>> _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
More information about the Kepler-dev
mailing list