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" <[email protected]> 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: [email protected]
>> 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: [email protected]
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
