Chris, Sean, Good point on name-spacing in the artifacts. When I was suggesting simplicity, my initial view was that the separation of components into oodt vs. cas vs. grid could be confusing to the external community.
From Sean's original reply on the subject, proposal one is: — cas-* for catalog/archive components — grid-* for traditional oodt profile & product components — oodt-* for common components From Chris' response, proposal 2 is: — cas-* for catalog/archive components — oodt-* for profile & product components and common components One way to look at it is that all components are under the egis of OODT, so to call some components oodt and other something else could be confusing. Also, IMHO calling some components grid and other something else could also be confusing considering the cas components are really computational grid. I would also throw in a third suggestion that we prefix everything with oodt. It solves the artifact naming problem that Chris I think rightly points out could be a real annoyance but it couple be a little simpler to understand. If others feel more strongly on separating the components into multiple namespaces then I think I would rather go with proposal 2 than 1. Thoughts? --------------------------------------------------------- David M. Woollard, Software Engineer Data Management Systems and Technologies Group (388J) NASA Jet Propulsion Laboratory, Pasadena, CA, 91109, USA Office: 171-243D Phone: (818) 354-4291 "Anybody who wants to make a revolution shouldn't grab a gun. Just go and start working to change the world by using science and technology." -Stanford Ovshinsky On Jul 22, 2010, at 11:35 PM, Mattmann, Chris A (388J) wrote: > Hey Dave, Sean, > > OK well since I am stuck in Houston tonight I finally found time to reply to > this, so here goes. Sean and I did have some conversations about this over > IM that boiled down to my feeling that we should keep the cas-*, and oodt-* > prefixes on the artifact IDs for the jars we produce. Why you ask? Well, let > me for the record state that I agree with Sean's perspective that we should > leverage namespacing to handle things and if we agree on that, why do we > need to include the namespacing in the artifacts? Well it boils down to > this: > > * jar dependencies as included in physical files on disk, e.g., in a lib > directory, in downstream software that uses OODT. > > Let's take a concrete example. Let's say we strip off the namespacing on the > oodt-commons project, and we produce the jar artifact > commons-0.1-incubating.jar, which is published by the org.apache.oodt group, > and therefore, as a Maven dependency (or Ivy dependency), we are perfectly > fine in allowing folks downstream of OODT to inherit and use this > functionality in their code. What happens though when someone wants to grab > commons-0.1-incubating and drop it in their lib folder of say, a server > project like filemgr or workflow? So, they take it and they put it in: > > /usr/local/filemgr/lib > > Where there are a ton of other jar files, let's say some of them named: > > commons-lang-2.4.jar > commons-io-1.4.jar > > Etc etc. The user could easily get confused, seeing: > > commons-0.1-incubating.jar > > In the lib dir there? Is this a commons jar? If it is, what specific commons > functionality does it provide? See, the answer is really missing there. > > So, it's for that reason, and for the reason that I see a ton of other > Apache projects have to fall prey to this same thing, that I believe we > should keep the namepsacing in the artifact IDs, *with one caveat*. We threw > out the edm-* namepsacing b/c it made zero sense. It was a renaming effort > for OODT back in the early 2000s that ultimately failed. In reality, we > have: oodt-* and cas-* and I think we are totally good with those. oodt-* > jars implement the information integration side of OODT and cas-* implement > the computational grid and processing side. > >> >> I think this view conflicts with OODT-5 [1]. For my own two cents, I think >> simplicity should trump previous historical organization, so I would rather >> see the prefixes removed. > > I could see how you would think that, reading over the isssue, but let me > tell you as the issue creator what my original intent was. My original > intent was simply to remove this prefixing on the *directory names* in SVN, > not on the jars themselves. > > Cheers, > Chris > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >
