oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David M Woollard <wooll...@jpl.nasa.gov>
Subject Re: couple more pom issues
Date Mon, 26 Jul 2010 18:01:16 GMT
Hey guys,

I'm fine with incremental. I do think its important to consider an organization that puts
all sub-components on par with one-another, but its an equally-valid concern to say that we
should take smaller steps toward reorganization (if we all feel that that is an important
goal).

So, Proposal 2 gets my +1.

-Dave 
 
---------------------------------------------------------
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 23, 2010, at 11:31 PM, Mattmann, Chris A (388J) wrote:

> Hey Guys,
> 
> Of course I'm biased, but my vote would be for proposal 2. I think it's incremental change
towards an eventual move to all oodt-* components, which is proposal 3, which would be nice
to eventually get to. I don't think it's a blocker though (or a requirement) to move to proposal
3 for 0.1-incubating, as we changed quite a few things back in the day on Tika (the move from
the 0.2 series to 0.3 and 0.4, where we totally modularized everything out of the monolithic
tika.jar) based on experience using the code and jars out there in the field. I think we'll
gain the same experience with a couple releases under our belts in OODT and the key in my
mind is syncing up the version #'s (e.g., ${oodt.version}), which should make whether or not
we rename artifacts a lot easier to rapidly implement. Proposal 1 keeps existing users of
OODT at bay and will resemble most closely what they "know" OODT to be, but I think since
we're revamping OODT over here at Apache and trying to also use the revamping as an opportunity
to move forward on a couple things, I think we can safely move beyond proposal 1, implement
proposal 2 as part of 0.1-incubating, and then try and get to proposal 3 in some future 0.1++
release.
> 
> My 2 cents,
> Chris
> 
> P.S. I think this is important to solve before 0.1-incubating goes out the door, but
not a necessity to solve, e.g., before OODT-15, OODT-16, and OODT-3 get wrapped up. So, let's
keep pressing forward on those, trying to keep the build as stable as possible for the 3 issues,
so we can close them out, get ready to roll 0.1-incubating, and then make the decision then.
> 
> 
> On 7/23/10 11:01 PM, "David M Woollard" <woollard@jpl.nasa.gov> wrote:
> 
> 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: Chris.Mattmann@jpl.nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 
> 
> 
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: Chris.Mattmann@jpl.nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 


Mime
View raw message