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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
