Personal tools
You are here: Home Developer Developer Forum Architecture Team Architecture team roadmap

Architecture team roadmap

Up to Architecture Team

Framework team roadmap

Posted by Timothy McPhillips at August 20. 2008

I'd like to reiterate the suggestion I made yesterday about using the ppod extension as a test case for the extension framework. 

Specifically, I would like to be able to create a bundle for the ppod extension, and additional bundles for each of the other extensions ppod depends on.  I'd then like to be able load these bundles into a installed instance of Kepler that was neither built  nor installed with these extensions.  The ppod workflows should then work, the actors should appear in the library pane, and the ppod gui customizations should be enabled in the Kepler GUI. 

 

May I add these objectives to the roadmap?

 

 

Re: Framework team roadmap

Posted by Matthew Jones at August 20. 2008

I think this is a great example, and yes, I think you should go ahead and add it to the roadmap.

Re: Framework team roadmap

Posted by Aaron Schultz at August 21. 2008

Agreed, this is a good next step.  It should be fairly straight forward as long as there are no dependencies from Kepler to the extensions.  To handle any files that were modified from the kernel you will want to create a custom kernel jar (appropriately labeled) and compile your new files there.  Also, if any of your actors use external jars they will not work since actors are still being loaded with objectmanager and not yet with the new framework.

Re: Framework team roadmap

Posted by Timothy McPhillips at August 21. 2008

Great! Maybe we can use this objective as a way of prioritizing work such as support for actors that depend on 3rd-party jars not included in the Kepler base system (if I understand you correctly)?

What would everyone think of shooting for a mini development release of the kernel that includes the first increment of new extensibility features?  The ppod extensions could be targeted to work with that release, then, and we could avoid overriding the kernel jar.

Re: Framework team roadmap

Posted by Timothy McPhillips at August 21. 2008

Another idea.  Looking at the roadmap, I'd like to phrase items here as externally verifiable milestones (e.g., 'a scientist can download a release of kepler, the ppod extension, and the extensions ppod depends on, and use them together without rebuilding Kepler') and less like tasks (for one thing, the task list could be quite long).  Also, for now I suggest we not worry about dependencies between or ordering of milestones.

 

Sound OK?

Re: Framework team roadmap

Posted by Timothy McPhillips at August 28. 2008

I've added a new milestone to the road map, proposing we release a new version of the Kepler kernel that has the features required to run the ppod-related extensions.  We can assume that the subsequent milestones depend on that version of the kernel.

Powered by Ploneboard
Document Actions