Skip to content.
|
Skip to navigation
Site Map
Accessibility
Contact
Search Site
only in current section
Advanced Search…
Sections
user
Developer
Personal tools
Log in
Register
You are here:
Home
Nav
Home
Developer
Log in
Login Name
Password
Cookies are not enabled. You must enable cookies before you can log in.
Forgot your password?
New user?
Info
Modified items
All recently modified items, latest first.
Installing Distributed Workflows
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 03:44 PM
Kepler SRB
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 03:18 PM
Archive
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 03:10 PM
Distributed-Execution-related specifications moved from the old wiki.
New Documents in Framework Team Area
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 03:00 PM
Hi- I moved a number of framework-related docs from the old wiki to a new folder called "Archive" in the Framework area of the new wiki. Each is clearly marked with an outdated status (see https://dev.kepler-project.org/developers/teams/framework/archive/kepler-repository for an example). Over in the user outreach forum, we've been talking about noting the status of specifications more clearly, and we came up with the idea of three general categories for pages (now noted on the Framework home page): Work in Progress (for current work); Technical Documentation (for documentation of completed work), and Archive (for out-of-date material--in this case stuff moved from the old site that needs review before it can be updated to current. I thought using colored icons at the top along with a text message could reinforce the status even more firmly. Will this system work for you? Do you have any additional thoughts or concerns? Note that some of the pages might not be properly categorized, in which case, please feel free to move them to the correct place. Thanks for your thoughts, kirsten
Links
by Aaron Schultz, last updated: Sep 22, 2008 02:49 PM
Useful links to external resources used by the Framework Team.
Implementations
by David Welker, last updated: Sep 22, 2008 02:49 PM
A folder containing instructions for compiling and running implementations of OSGi Kepler.
Files
by Aaron Schultz, last updated: Sep 22, 2008 02:48 PM
Shared resources used by the Framework Team.
Meetings
by Timothy McPhillips, last updated: Sep 22, 2008 02:48 PM
Framework Team meeting agendas, notes, and minutes.
Glossary
by Timothy McPhillips, last updated: Sep 22, 2008 02:47 PM
Framework Team Glossary: Definitions of key terms used to describe the overall framework architecture for Kepler.
KAR Encapsulation Specification
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 02:21 PM
Kepler Startup Time
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 02:17 PM
Archive
by Kirsten Menger-Anderson, last updated: Sep 22, 2008 01:10 PM
Framework-related specifications moved from the old wiki.
Useful resources
by Aaron Schultz, last updated: Sep 22, 2008 11:00 AM
Re: Useful resources
by Aaron Schultz, last updated: Sep 22, 2008 11:00 AM
Some more on JSR 277 and 291 Also, a new release of OSGi in Practice And for blog fans, planeteclipse.org
Re: need feedback on new wiki organization
by Matthew Jones, last updated: Sep 19, 2008 02:18 PM
That all sounds great to me. I think limiting the menu to a fixed number of levels would be good, and I also like rearranging the order of things in the developers tree, and the use of the Archive folder. I also support the standardized format for specifications, although as we don't have any formatting police we'll have to see how well that is adopted -- its good to try though.
Re: need feedback on new wiki organization
by Kirsten Menger-Anderson, last updated: Sep 19, 2008 01:01 PM
Hi- Tim and I talked over the outstanding wiki issues and have some proposals (and questions), detailed below for comment: 1. Move the pages from the old wiki to the new. All pages will go into an "archive" folder beneath the appropriate team or group, with new incubation teams created when necessary (e.g., for user interface and Kepler Execution Monitoring documents). In addition to the archive folder, create a "work in progress" directory for current work and begin to use the "technical documentation" directory for completed work. These items will be listed as the last three items on the team/group homepage in the following order: 1. work in progress 2. technical documentation 3. archive. Team members can move archive pages if the destination chosen is not quite right, or promote an archived document to current (or just mine the archived doc for useful bits to repurpose/leaving the archived version where it is). 2. Implement a standard header on each specification page including a title, an overview of the page content and intended audience (if not all kepler developers), and the status. 3. Create an "Exemplar Approach" template in the Developer/Reference section that developers can use as a guide when creating new specifications. Question: Are there any existing specifications that would be good examples? 4. Invert the nav items in the Developer section so that documents relevant to all developers (get code, reference, faq, etc) are at the top and the more project-specific items are at the bottom. Propose that the nav menu be limited to three levels of hierarchy, and that the horizontal indent between levels be increased to more clearly indicate the hierarchy. 5. Add index pages to Teams and Groups directories providing more context about what each is, what resources are found there, and how to get involved. Descriptive content drawn from management charter. 6. Move the meeting notes to a new "Developer Meeting" directory under Developer. This directory will not appear in the navigation. That's it! Please let me know your thoughts. Thanks, kirsten
Re: Build System Requirements
by Derik Barseghian, last updated: Sep 19, 2008 12:46 PM
Hi David, I gave this a try with os X 10.5.5 with my default ant 1.7.0 and then started the procedure over completely using 1.7.1, but received this failure both times: <code> nceas-macbook05:build-area derik$ ~/code/ant_1.7.1/apache-ant-1.7.1/bin/ant run Buildfile: build.xml compile: [compile] Compiling A... BUILD FAILED /Users/derik/dev3/1.0/build-area/build.xml:15: srcdir "/Users/derik/dev3/1.0/A/src/main/java" does not exist! Total time: 0 seconds </code> Derik Previously David Welker wrote: Hi Chad, Right now, I am finishing up Netbeans support for the build. After that point, I would like to begin the non-trivial task of documenting it. The build is in fact checked in at https://code.kepler-project.org/code/kepler/kepler.build/branches/1.0 Please note, you need version 1.7.1 of Ant to run the build system. Anyway, taking a quick crack at it to run the most basic version of Kepler is not too hard. Later, I will produce more complete documentation. Here is a quick and dirty set of steps you can use to try it out. (1) Checkout the code above. (2) Make sure you have 1.7.1 of ant installed. (3) Navigate to the build-area/ folder. (4) Type ant get. The build downloads kepler, ptolemy, as well as a required extension known as loader. This should take something like 6.5 minutes. (5) Type ant run. Vanilla kepler runs. ---------- Please note, there are some bugs having to do with the cache that may frustrate this simple set of instructions. That bug did not manifest itself until somewhat recently because I have been using the ppod extension, and the bug does not seem to manifest itself in that context. Anyway, whether or not step (5) works, you can try the following. (6) Type ant change-to -Dmod=ppod. This download additional modules needed by ppod and changes configuration information. (7) Type ant run. Now, the ppod distribution of Kepler should run. (8) Type ant change-to -Dmod=vanilla. This should change back the configuration information to run vanilla ppod. (9) Type ant run. Plain Kepler should run. With one caveat. Since it is using the cache generated by ppod, it will look a little different. One thing we need to do is restructure that cache so that you can seemlessly change back and forth between extensions. Anyway, after adding support for netbeans and working out a few bugs, I will produce some real documentation.
Re: typo in devel forum URLs
by Daniel Crawl, last updated: Sep 19, 2008 09:01 AM
Thanks Shaun! --dan
Re: need feedback on new wiki organization
by Matthew Jones, last updated: Sep 18, 2008 08:14 PM
I'd really like to participate tomorrow, but I'm going to have to skip this one due to pressing deadlines (like a seminar to be prepared for tomorrow afternoon) that I've been putting off way too long. So... a synopsis of your decisions would be great. I looked at Kirsten's work so far and generally I am happy with it. I'd like to see the Developer section have a sensible set of introductory pages that explain how to develop with Kepler, and a reference section that accurately explains how Kepler actually works form an architecture and design perspective. These pages should reflect the current release, or maybe have different subsections for each major release. Then I think the technical design and implementation details of particular new or changing subsystems should be contained within the correct development team collaboration area, and will become the responsibility of that team to keep updated. In terms of the documents still to be migrated -- I'd like to make sure we don't lose any of that content. For example, the ObjectManager description has a lot of valuable reference information, even though its not quite correct. I suggest these pages get migrated into 'Legacy' folders inside each of the appropriate team areas, which will allow the proper team to revise them to reflect current behavior and then migrate them to the proper team or reference part of the site. They could even be made private to the team for the time being if they are misleading or otherwise contain material we don't want broadly distributed to avoid confusing things, etc. Looking forward to hearing how you decide to move forward.
Re: Build System Requirements
by Timothy McPhillips, last updated: Sep 18, 2008 12:26 PM
Hi Chad, integrating all of the build system use cases and requirements that are floating around and putting them in one document sounds great. It will help us be more articulate about what we're trying to achieve and what constraints we face. I like how the Extension Framework requirements document (especially the non-functional requirements section) is turning out. Do you want to start the requirements document for the build system? I'm also happy to do so. By the way, you may have noticed I started an overview document for providing background to the ongoing work on supporting development of extensions. This document could be mined for more formal requirements as well. Tim
« Previous 20 items
Next 20 items »
1
…
35
36
37
38
39
40
41
…
46
News
Kepler talks at EIM 2008
Sep 15, 2008