oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: couple more pom issues
Date Fri, 23 Jul 2010 06:35:11 GMT
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Mime
View raw message