Personal tools
You are here: Home
Log in


Forgot your password?
New user?
 

Modified items

All recently modified items, latest first.
Re: build system usability issues by Daniel Crawl, last updated: Jan 16, 2009 08:43 AM
Hi David, I don't think copying these classes into the loader module is a good policy: 1. In this case, we'd have to copy DateToken and all of its dependencies. The loader module is not the appropriate location for these classes since they are unrelated to the new build system. In the future, there may be other classes that require this kind of initialization and this policy leads to lots of unrelated classes in the loader. Additionally, suppose the next version of DateToken needs to be initialized; how will this handle multiple versions? 2. Kepler 1.0 does not have DateToken. If it is copied into the loader module, then the new build system can longer provide a vanilla 1.0. An interesting related question is: can the new build system currently provide a vanilla 1.0? If the loader module is used, then I don't see how it can...   Anyway, here's how I would split Kepler.java: 1. Everything except the build system initializations would go into the core module. 2. The build system initializations stay and after they execute, call org.kepler.loader.Kepler.main(). Both core and 1.0 have this method. What do you think?   Previously David Welker wrote: Hi Daniel, I think the easiest thing to do would probably be to copy whatever classes are needed by these initializations into loader. The issue with splitting Kepler.java into two parts is that the part that is split off (containing your initiazations) would still need to be invoked somehow. One approach would to provide some sort of class that contains a no-op function, but then overwrite that class in another module which is contained in whatever distribution needs those initializations. David  
Re: Issues on creating new modules. by Jianwu Wang, last updated: Jan 16, 2009 12:39 AM
Hi David, Thanks for your response. Currently, my module works fine. If I find more requirements, I will let you know.
Issues on creating new modules. by Jianwu Wang, last updated: Jan 16, 2009 12:39 AM
Re: build system usability issues by Aaron Schultz, last updated: Jan 15, 2009 08:08 PM
I was curious as to what suites were available for changing to from the build system and I found them listed in build-area/build-settings/module-locations.txt Easy enough, but my first reaction was to look for an ant target that listed all of the available suites.  Could we add a target for that?
Re: Issues on creating new modules. by David Welker, last updated: Jan 15, 2009 05:40 PM
Hi Jianwu, 1.) I think that your solution for specific ant tasks is a good one, at least for now. Is there further support for this use case that you would like in the build system? 2.) Your solution for menu mappings is also appropriate. In the future, we might consider a more nuanced approach, but for now this is in fact the best way to do it.
Re: build system usability issues by David Welker, last updated: Jan 15, 2009 05:13 PM
Hi Daniel, I think the easiest thing to do would probably be to copy whatever classes are needed by these initializations into loader. The issue with splitting Kepler.java into two parts is that the part that is split off (containing your initiazations) would still need to be invoked somehow. One approach would to provide some sort of class that contains a no-op function, but then overwrite that class in another module which is contained in whatever distribution needs those initializations. David
Re: Issues on creating new modules. by Jianwu Wang, last updated: Jan 15, 2009 02:39 PM
Currently, I made the master-slave module work. I already removed the old files from other modules. What I did for the above questions: <p> 1) Module specific ant tasks: I made a separate build.xml in master-slave dir, it works. </p> <p> 2) Module specific Menu item: Like pPod, I also have its own uiMenuMappings_en_US.properties. I also moved the class for this menu item from package org.kepler.gui to org.kepler.distributed. </p> <p> I don’t know whether this way is very accordant to the new build system, but at least it is viable. If anyone is interested, please have a look at it. Better solutions are welcome. Thanks. </p> <p> P.S.: Maybe we should a detailed guide document (such as FAQ) for new build system developers. I will be glad to contribute some questions. </p>
Issues on creating new modules. by Jianwu Wang, last updated: Jan 15, 2009 02:38 PM
I'm trying to create a new module to enable master-slave distributed execution. I met the following issues. They are very general questions. So I put them here so that we can argue to get the best solution. 1) Module specific ant tasks: Where to put ant tasks specific to the new module? It is reasonable to put it in the new module directory. So we need to build in a function in the main build system to execute targets from build files in other modules. 2) Module specific Menu item: one menu item is need to enable my new module. File uiMenuMapping_en_US.properties records the Menu configuration. I found that ppod-gui module put a same file in its module directory. Is it a generic solution for module specific menu item that each module keep its own configuration files?
Re: build system usability issues by Daniel Crawl, last updated: Jan 15, 2009 11:46 AM
Hi David, Has there been any decision on how to reintegrate the initializations that we deleted earlier this week? They are important since they provide backwards-compatibility for several actors and are required to run some REAP workflows. What about splitting Kepler.java into build system and non-build system components?
Re: proposed additions to provenance framework stores by Derik Barseghian, last updated: Jan 13, 2009 05:37 PM
Hi Shawn, A report contains author-specified items associated with a workflow run. A user wants to present and highlight certain things from a workflow run to others -- things like input parameters, all output from a specific actor, resultant graphs, and so forth. It's user specified data pulled out of provenance and presented in a human readable and printer-friendly way (headers and footers, page numbers, etc). Derik
moving to jdk 1.6 by Derik Barseghian, last updated: Jan 13, 2009 01:51 PM
Hi, I thought it'd be useful to get information on what's preventing us from moving to jdk 1.6 listed in one place. My motivation is to be able to use certain 1.6 javax.swing classes in the workflow-run-manager suite. After &nbsp;&nbsp; cd core/src/org/ecoinformatics/util/ &nbsp;&nbsp; cp DBConnection-JDK1.6-Java DBConnection.java kepler seems to work fine for me with 1.6 under the new build system, both from the command line beneath linux, and on Eclipse (launched w/ system default 1.5) on Mac, by selecting 1.6 from within Eclipse. What's holding us up? Can the new build system allow certain modules to require different versions of java? Derik &nbsp;
Re: build system usability issues by Daniel Crawl, last updated: Jan 13, 2009 12:23 PM
The mysql jar is no longer in the repository. How did this happen? Have other jars been removed?
Re: build system usability issues by Aaron Schultz, last updated: Jan 12, 2009 07:21 PM
Ah, OK, in subversive when I do a commit at the top level, loader for example, I get loader/target, loader/.classpath, and loader/.project all with check boxes next to them for adding to version control and then I have to uncheck them so they don't get added.
Re: build system usability issues by David Welker, last updated: Jan 12, 2009 06:47 PM
Hi Aaron, The reason that this has not been addressed is because with svn, any files that are not added using svn add will be ignored when you do a check-in. You don't have to explicitly use svn:ignore, you simply don't add them and they will be ignored. That is the reason you don't see a bunch of .project and .classpath files and for that matter .iml files (IDEA equivalents) in the repository in the absence of support for svn:ignore. &nbsp;
Re: build system usability issues by Aaron Schultz, last updated: Jan 12, 2009 04:20 PM
Another, build system usability issue I'd like to bring up is the usage of svn:ignore for all build generated files.&nbsp; It is somewhat difficult to determine exactly what has changed locally with extra build generated files laying around.&nbsp; However, it looks like a lot of care was taken to keep it to a minimum (target directory, .classpath, .project for each module)&nbsp; Perhaps this could be automated somehow.&nbsp; I have already added target, .classpath, .project to svn:ignore for the util module by hand. This brings to mind another question, where do application generated files go?&nbsp; Does each module have a folder in the .kepler directory?&nbsp; Is there a specific folder in the module directory (marked with svn:ignore) that is meant for writing by the module?&nbsp; How is this being handled?&nbsp; Is it documented somewhere that I missed? Thanks!
Re: build system usability issues by Aaron Schultz, last updated: Jan 12, 2009 04:09 PM
&nbsp; David, I just tried the ant update task and it seemed to work well.&nbsp; Doing a refresh in subversive recognized that the update had happened.&nbsp; I notice that the reported revision numbers from the ant task are the latest revision number for the entire repository and not for the individual modules.&nbsp; Not a big deal but it threw me off for a sec because the latest revision reported in subversive is specific to the module (for example the loader module is only at revision 16235 at the moment).&nbsp; Also, Shawn, if you are using a graphical SVN client you can select all the projects and do an update that way as well. pdate: [update-modules] Using command line interface [update-modules] Svn : Updating [update-modules] up -r HEAD /Users/aaron/kepler.modules/loader --non-interactive [update-modules] At revision 16300. [update-modules] Svn : Updating
Re: build system usability issues by David Welker, last updated: Jan 12, 2009 03:04 PM
Hi Shawn, I just added a new ant target to do this. Now typing in "ant update" will run svn update on all the modules listed in modules.txt.
Decision Making Capability by sm, last updated: Jan 11, 2009 07:31 PM
Hello All, I was curious to implement some sort of decision making ability in Kepler. Eg: "Switch Case" Logic or a Decision box or an If, Else Construct. Please suggest! &nbsp; Thanks in advance &nbsp;
Decision Making Capability by sm, last updated: Jan 11, 2009 07:31 PM
JDK 1.5 for Users? by sm, last updated: Jan 10, 2009 12:00 PM