Personal tools
You are here: Home
Log in


Forgot your password?
New user?
 

Modified items

All recently modified items, latest first.
Leadership Team by Development Account, last updated: Feb 10, 2010 01:09 PM
Workflow Sharing Interest Group by Timothy McPhillips, last updated: Feb 09, 2010 03:59 PM
KAR Saving Process by Aaron Schultz, last updated: Feb 01, 2010 02:15 PM
This page will explain how the KAR save process works.
Example KAR Dependency Graph by Aaron Schultz, last updated: Jan 28, 2010 01:12 PM
Incubation by Matthew Jones, last updated: Jan 24, 2010 03:40 PM
Groups that are being proposed develop their mission, charter, and roadmap here to prepare for submission to the management team for approval.
Updating the Kepler Directors and Actors by Christopher Brooks, last updated: Jan 22, 2010 09:18 PM
How to update the set of Directors and Actors that are shipped with Kepler
LSID Registration Services by Kirsten Menger-Anderson, last updated: Jan 15, 2010 05:29 PM
KAR save process by Aaron Schultz, last updated: Jan 15, 2010 01:37 PM
Using event-state in your module by Ben Leinfelder, last updated: Jan 13, 2010 10:11 PM
The 'event-state' module contains a framework for communicating gui state changes among Kepler modules.
PreferencesTab Extension Point by Aaron Schultz, last updated: Nov 30, 2009 01:25 PM
The PreferencesTab extension point allows modules to provide users the ability to set module specific preferences from a common frame within Kepler.
ViewPane and TabPane GUI Extension Points by Aaron Schultz, last updated: Nov 30, 2009 01:23 PM
This page explains how to extend the Kepler graphical user interface using the ViewPane and TabPane extension points.
ConfigurationProperty)l.get(0 by Chad Berkley, last updated: Nov 23, 2009 12:24 PM
Architecture Team by Matthew Jones, last updated: Nov 10, 2009 10:13 AM
Kepler 2.0 Release Roadmap by Matthew Jones, last updated: Oct 29, 2009 01:23 PM
This is a roadmap for the release plans for Kepler 2.0. We currently have broad agreement about the goals and approaches for this release as articulated in this document, but the final document awaits endorsement by the Kepler Leadership Team.
Re: Specifying dependencies on Module Versions by Aaron Schultz, last updated: Oct 28, 2009 09:48 AM
Thanks David, your solution sounds fine, let me know when it is implemented and documented so I can use it in the KAR system.
Specifying dependencies on Module Versions by Aaron Schultz, last updated: Oct 28, 2009 09:48 AM
Re: Specifying dependencies on Module Versions by David Welker, last updated: Oct 28, 2009 01:09 AM
Are we still using this forum? First, I do not believe it should be the responsibility of the KAR system itself to load modules. It should be the responsibility of the Module Manager. However, I do think it would be very useful to store the version of the precise modules that were present when a workflow was developed somewhere in the KAR file. It appears that we are in the process of developing systems that are in conflict with each other. Therefore, until we resolve this via Kepler management, I request that further work on this of yours be considered a prototype and occur in a separate module outside of the kepler suite. I will do likewise. Second, specifying entire ranges of possible dependencies might be okay, but I think we should think critically about whether we want or need this feature. What does it mean for two modules to "work" together. Does it mean that for all possible workflows, all modules within the range will give you identical results? This would imply that the only changes between the versions of modules are non-substantive bug fixes or performance improvements. That is, that the changes constitute patches, not major or minor releases. By contrast, if workflows are not guaranteed to yield identical results (as when a major or minor release is made), then I do not think it makes sense to say, for the purpose of a particular workflow, that the modules are interchangeable. In fact, I think this would be poisonous to scientific workflows, because repeatability is a very important objective. Anyway, I am working on this very same problem in my prototype of the new module manager. And the versions I use works like this: A published module must refer to another module either down to the exact patch level. (i.e. foo-1.1.3 depends on bar-2.1.4) or it can say that the latest patch is acceptable (i.e. foo-1.1.3 depends on bar-2.1.^). In the system I am developing, it does not make sense to say that a workflow can either use bar-2.4.6 or bar-3.0.0 interchangeably, because major and minor updates are NOT guaranteed to be semantically equivalent, as patches are supposed to be. If something is in fact semantically equivalent to bar-2.4.6, then it should be released as bar-2.4.7 or bar-2.4.X, not as bar-3.0.0 or bar-2.5.0). That is, things that are guaranteed to be semantically equivalent (they are bug fixes or performance optimizations) should be published as patches and not as major or minor releases. Things that are not bug fixes or performance improvements and are not semantically equivalent should be published as major or minor releases, and not patches. Of course, I think Aaron should be free to experiment with whatever approach he likes in his prototype. I think those experiments should occur in a separate module, however.
Re: Specifying dependencies on Module Versions by Matthew Jones, last updated: Oct 27, 2009 04:58 PM
Thanks, Aaron. This is very useful for background.  We certainly should be able to specify version and version ranges for module dependencies, and this seems like a reasonable starting point for a proposal. Matt
Re: Specifying dependencies on Module Versions by Aaron Schultz, last updated: Oct 27, 2009 04:53 PM
I'll paste here sections 3.2.5 and 3.2.6 of the OSGi spec release 4 version 4.2, available in full at http://www.osgi.org/Specifications/HomePage   this is the kind of thing that I am looking for for Kepler modules.   Thanks!   Version   Version specifications are used in several places. A version token has the fol- lowing grammar: version    ::= major( '.' minor ( '.' micro ( '.' qualifier )? )? )? major    ::= number    // See 1.3.2 minor ::=number micro ::=number qualifier ::= ( alphanum | ’_’ | '-' )+ A version token must not contain any white space. The default value for a version is 0.0.0.   Version Ranges   A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation. The syntax of a version range is: version-range ::= interval | atleast interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' ) atleast ::= version floor ::= version ceiling ::= version If a version range is specified as a single version, it must be interpreted as the range [version,∞). The default for a non-specified version range is 0, which maps to [0.0.0,∞). Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example: Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)" In the following table, for each specified range in the left-hand column, a version x is considered to be a member of the range if the predicate in the right-hand column is true.
Specifying dependencies on Module Versions by Aaron Schultz, last updated: Oct 27, 2009 04:47 PM
I was wondering what the format for designating module dependencies is?  I've added the ability for developers to add module dependencies to KAR files but it does not take into account any information about the version of the module.  It only works with the module name at the moment, which is equivalent to saying "All versions" of the module.
 
« Previous 20 items Next 20 items » 1 … 12 13 14 15 16 17 18 … 46