[kepler-dev] breaking off a kepler-docs repository
Shawn Bowers
sbowers at ucdavis.edu
Fri Aug 5 11:13:07 PDT 2005
I think also that the kar/ksw/object manager/cache approach ultimately
should allow one (in a way similar to xemacs, e.g.) to download and
install a minimal kepler and download and run (even as kepler is running)
external workflows and workflow components. These components could be
organized or bundled into project-specific kar/ksw files. Similarly,
project specific data repositories could also be accessed using the
EcoGrid or even using kar/ksw files (however, EcoGrid would presumably
provide some additional features for data such as query and metadata
management).
-shawn
On Fri, 5 Aug 2005, Chad Berkley wrote:
> I don't think the KSW/ObjectManager system will really have an impact on
> custom builds, unless you're talking about custom releases (which I
> think are different). The objman should allow you to create your own
> ontology for the system and just load the actors (from KSW files) that
> are specific to that ontology. So you could have a GEON ontology and
> just have a GEON specific release with relevant components. As far as
> building and daily development goes, I don't see the objman affecting it
> very much.
>
> chad
>
> Bertram Ludaescher wrote:
> > Indeed, the project-oriented splitting had been discussed before (and
> > project boundaries are not always clear, e.g., if someone from SEEK
> > helps someone from SPA (or Geostreams ;-) to jointly write an
> > actor. Where does it go??
> >
> > Chad, could you briefly summarize (or point us to the respective docu)
> > how the new KSW (KAR ;-) and/or object manager approach might help the
> > problem of project-specific/custom builds? It seems that under the new
> > approach, one could just have a "minimal" Kepler build and then
> > dynamically discover components (actors, workflows, datasets)..
> >
> > Bertram
> >
> > Chad Berkley writes: > Hi Carlos,
> > >
> > > The problem I see with this is that it divides kepler into project
> > > specific lines where what we're trying to do is create a cross project
> > > modeling platform. Our src directly was already divided similarly to
> > > this and it caused numerous problems with organization so we've been
> > > trying to move stuff to the org.kepler tree. Also, reorganizing stuff
> > > on that level at this point would be a nightmare.
> > >
> > > chad
> > >
> > > Carlos A. Rueda wrote:
> > > > Dear kepler-ers,
> > > > I think having the two modules kepler/pubs and kepler/dev is a very
> > > > good idea. In fact (knowing that the current KSW efforts might
> > > > supersede the following suggestion somehow), I would suggest even go
> > > > further and split up the /dev module into submodules corresponding to
> > > > projects, something like:
> > > > kepler/dev/core
> > > > kepler/dev/projA
> > > > kepler/dev/projB
> > > > ...
> > > >
> > > > with each component (submodule) coming with its own build files
> > > > (build.xml, properties, etc.) and dependencies only on those other
> > > > required modules.
> > > >
> > > > Developer-users would be able to check out only the desired
> > > > components. This way one can avoid dealing always with the "heavy"
> > > > kepler and instead work with the minimum set of components required to
> > > > try and test new developments.
> > > >
> > > > carlos
> > > >
> > > > Bertram Ludaescher wrote:
> > > >
> > > >>Chad Berkley writes:
> > > >>...
> > > >>
> > > >> > a slightly different way. Say kepler/dev and kepler/pubs. That way if
> > > >> > you only want the code part you could do 'cvs co kepler/dev' If you
> > > >> > want it all, you would do 'cvs co kepler'. Just a thought.
> > > >>
> > > >>Looks like that easiest fix to me. Any objections to this suggestion?
> > > >>(Would take care of both Chad's problem and the concern that Laura raised)
> > > >>
> > > >>BTW, I also think that a document management might be too much effort
> > > >>right now. An interesting project though for someone who is interested
> > > >>in that topic ..
> > > >>
> > > >>Bertram
> > > >>
> > > >> >
> > > >> > chad
> > > >> >
> > > >> > Laura L. Downey wrote:
> > > >> > > I thought the point was having everything in one place -- which is important
> > > >> > > with a distributed project. At least that is the impression I've gotten
> > > >> > > from Matt.
> > > >> > >
> > > >> > > It would seem that people are "checking out" instead of "updating" with CVS
> > > >> > > because update is much quicker. But I think I remember Dan telling me the
> > > >> > > other day that it is "safer" to check out than to update.
> > > >> > >
> > > >> > > I'm fine with whatever is decided, keeping things together or splitting them
> > > >> > > apart. My only comment is that the more repositories we have and the more
> > > >> > > places we have to go to get and put data (docs, code etc), the more upkeep
> > > >> > > that is for everyone.
> > > >> > >
> > > >> > > Laura L. Downey
> > > >> > > Senior Usability Engineer
> > > >> > > LTER Network Office
> > > >> > > Department of Biology, MSC03 2020
> > > >> > > 1 University of New Mexico
> > > >> > > Albuquerque, NM 87131-0001
> > > >> > > 505.277.3157 phone
> > > >> > > 505.277-2541 fax
> > > >> > > ldowney at lternet.edu
> > > >> > >
> > > >> > >
> > > >> > > -----Original Message-----
> > > >> > > From: kepler-dev-bounces at ecoinformatics.org
> > > >> > > [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
> > > >> > > Sent: Thursday, August 04, 2005 12:02 PM
> > > >> > > To: Chad Berkley
> > > >> > > Cc: Kepler-Dev
> > > >> > > Subject: Re: [kepler-dev] breaking off a kepler-docs repository
> > > >> > >
> > > >> > >
> > > >> > > I think it is a good idea to *not* include the various publications and
> > > >> > > presentations concerning Kepler in the code repository (cvs).
> > > >> > >
> > > >> > > I wonder, however, if having a separate cvs for documents is the way to
> > > >> > > go. Instead, maybe we should consider using a more traditional approach
> > > >> > > like a document management system? I'm sure there are a number of
> > > >> > > open-source/free ones out there (e.g., zope and plone are popular ones,
> > > >> > > the stanford publication server is an older one). Perhaps there are
> > > >> > > also extensions of the wiki for this?
> > > >> > >
> > > >> > >
> > > >> > > -shawn
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > Chad Berkley wrote:
> > > >> > >
> > > >> > >>Hi all,
> > > >> > >>
> > > >> > >>As I sit here checking out kepler (again), waiting forever for the docs
> > > >> > >>directory to finish, it occured to me that it might be ok to have a
> > > >> > >>different cvs repository for kepler docs. there's no reason why a
> > > >> > >>developer should have to checkout out a myriad of .doc and .ppt files
> > > >> > >>everytime you need a new version of kepler. It seems to me that docs
> > > >> > >>that actually go with the kepler software should stay in the kepler
> > > >> > >>repository, but publications, reports and the like could be stashed
> > > >> > >>somewhere else. Anyone have any reasons why this would be a bad idea?
> > > >> > >>
> > > >> > >>thanks,
> > > >> > >>chad
> > > >> > >>_______________________________________________
> > > >> > >>Kepler-dev mailing list
> > > >> > >>Kepler-dev at ecoinformatics.org
> > > >> > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > >> > >
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > Kepler-dev mailing list
> > > >> > > Kepler-dev at ecoinformatics.org
> > > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > Kepler-dev mailing list
> > > >> > > Kepler-dev at ecoinformatics.org
> > > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > >> > _______________________________________________
> > > >> > Kepler-dev mailing list
> > > >> > Kepler-dev at ecoinformatics.org
> > > >> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > >>
> > > >>_______________________________________________
> > > >>Kepler-dev mailing list
> > > >>Kepler-dev at ecoinformatics.org
> > > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > >>
> > > >
> > > > _______________________________________________
> > > > Kepler-dev mailing list
> > > > Kepler-dev at ecoinformatics.org
> > > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> > > _______________________________________________
> > > Kepler-dev mailing list
> > > Kepler-dev at ecoinformatics.org
> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
More information about the Kepler-dev
mailing list