[kepler-dev] breaking off a kepler-docs repository

Fri Aug 5 10:27:06 PDT 2005

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