You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oodt.apache.org by David M Woollard <wo...@jpl.nasa.gov> on 2010/07/23 00:52:38 UTC
couple more pom issues
In addition to the jug/s problem Sean found, I have noticed that in two cases components (curator and crawler) depended on a filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-incubating.jar. I have changed these over for the time being (see r966887 and r966889), but I wanted those more knowledgeable of these three components know.
-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
Re: couple more pom issues
Posted by "Woollard, David M (388J)" <Da...@jpl.nasa.gov>.
No worries... Just encouraging discussion.
Sent from my iPhone
On Jul 22, 2010, at 7:50 PM, "Chris Mattmann" <chris.a.mattmann@jpl.nasa.gov
> wrote:
> Guys the artifact ids make sense. I'll send a longer rely shortly
> but please don't change them yet.
>
> Cheers,
> Chris
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: "Woollard, David M (388J)" <Da...@jpl.nasa.gov>
> Date: Thu, 22 Jul 2010 19:43:14
> To: oodt-dev@incubator.apache.org<oo...@incubator.apache.org>
> Reply-To: "oodt-dev@incubator.apache.org" <oodt-dev@incubator.apache.org
> >
> Subject: Re: couple more pom issues
>
> Ah.. Yeah, I could be missing out on irc discussions... The one thing
> I can say is that the currect maven org doesn't reflect either
> discision, so there is still some work to do ;).
>
> Dave
>
> Sent from my iPhone
>
> On Jul 22, 2010, at 7:40 PM, "Sean Kelly" <ke...@apache.org> wrote:
>
>> I mentioned in our chat room before how if we really did need to
>> impose some kind of organization then it ought to be done with the
>> namespace feature already provided by Java: the package declaration.
>> I can't recall why that idea fell out of favor, though.
>>
>> I'm +1 for dropping the prefixes.
>>
>>
>> On 2010.Jul.22, at 9.13p, David M Woollard wrote:
>>
>>> 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.
>>>
>>> Anyone else have an opinion on the subject?
>>>
>>> -Dave
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/OODT-5
>>>
>>>
>>> On Jul 22, 2010, at 5:10 PM, Sean Kelly wrote:
>>>
>>>> I believe the overall goal is to have two part names for all
>>>> modules:
>>>>
>>>> — cas-* for catalog/archive components
>>>> — grid-* for traditional oodt profile & product components
>>>> — oodt-* for common components
>>>>
>>>> So the correct dependency is cas-filemgr and the correct version
>>>> should be ${oodt.version}, aka 0.1-incubating.
>>>>
>>>> I think.
>>>>
>>>>
>>>>> In addition to the jug/s problem Sean found, I have noticed that
>>>>> in two cases components (curator and crawler) depended on a
>>>>> filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-
>>>>> incubating.jar. I have changed these over for the time being (see
>>>>> r966887 and r966889), but I wanted those more knowledgeable of
>>>>> these three components know.
>>>>
>>>
>>
Re: couple more pom issues
Posted by Chris Mattmann <ch...@jpl.nasa.gov>.
Guys the artifact ids make sense. I'll send a longer rely shortly but please don't change them yet.
Cheers,
Chris
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: "Woollard, David M (388J)" <Da...@jpl.nasa.gov>
Date: Thu, 22 Jul 2010 19:43:14
To: oodt-dev@incubator.apache.org<oo...@incubator.apache.org>
Reply-To: "oodt-dev@incubator.apache.org" <oo...@incubator.apache.org>
Subject: Re: couple more pom issues
Ah.. Yeah, I could be missing out on irc discussions... The one thing
I can say is that the currect maven org doesn't reflect either
discision, so there is still some work to do ;).
Dave
Sent from my iPhone
On Jul 22, 2010, at 7:40 PM, "Sean Kelly" <ke...@apache.org> wrote:
> I mentioned in our chat room before how if we really did need to
> impose some kind of organization then it ought to be done with the
> namespace feature already provided by Java: the package declaration.
> I can't recall why that idea fell out of favor, though.
>
> I'm +1 for dropping the prefixes.
>
>
> On 2010.Jul.22, at 9.13p, David M Woollard wrote:
>
>> 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.
>>
>> Anyone else have an opinion on the subject?
>>
>> -Dave
>>
>>
>> [1] https://issues.apache.org/jira/browse/OODT-5
>>
>>
>> On Jul 22, 2010, at 5:10 PM, Sean Kelly wrote:
>>
>>> I believe the overall goal is to have two part names for all
>>> modules:
>>>
>>> — cas-* for catalog/archive components
>>> — grid-* for traditional oodt profile & product components
>>> — oodt-* for common components
>>>
>>> So the correct dependency is cas-filemgr and the correct version
>>> should be ${oodt.version}, aka 0.1-incubating.
>>>
>>> I think.
>>>
>>>
>>>> In addition to the jug/s problem Sean found, I have noticed that
>>>> in two cases components (curator and crawler) depended on a
>>>> filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-
>>>> incubating.jar. I have changed these over for the time being (see
>>>> r966887 and r966889), but I wanted those more knowledgeable of
>>>> these three components know.
>>>
>>
>
Re: couple more pom issues
Posted by "Woollard, David M (388J)" <Da...@jpl.nasa.gov>.
Ah.. Yeah, I could be missing out on irc discussions... The one thing
I can say is that the currect maven org doesn't reflect either
discision, so there is still some work to do ;).
Dave
Sent from my iPhone
On Jul 22, 2010, at 7:40 PM, "Sean Kelly" <ke...@apache.org> wrote:
> I mentioned in our chat room before how if we really did need to
> impose some kind of organization then it ought to be done with the
> namespace feature already provided by Java: the package declaration.
> I can't recall why that idea fell out of favor, though.
>
> I'm +1 for dropping the prefixes.
>
>
> On 2010.Jul.22, at 9.13p, David M Woollard wrote:
>
>> 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.
>>
>> Anyone else have an opinion on the subject?
>>
>> -Dave
>>
>>
>> [1] https://issues.apache.org/jira/browse/OODT-5
>>
>>
>> On Jul 22, 2010, at 5:10 PM, Sean Kelly wrote:
>>
>>> I believe the overall goal is to have two part names for all
>>> modules:
>>>
>>> — cas-* for catalog/archive components
>>> — grid-* for traditional oodt profile & product components
>>> — oodt-* for common components
>>>
>>> So the correct dependency is cas-filemgr and the correct version
>>> should be ${oodt.version}, aka 0.1-incubating.
>>>
>>> I think.
>>>
>>>
>>>> In addition to the jug/s problem Sean found, I have noticed that
>>>> in two cases components (curator and crawler) depended on a
>>>> filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-
>>>> incubating.jar. I have changed these over for the time being (see
>>>> r966887 and r966889), but I wanted those more knowledgeable of
>>>> these three components know.
>>>
>>
>
Re: couple more pom issues
Posted by Sean Kelly <ke...@apache.org>.
I mentioned in our chat room before how if we really did need to impose some kind of organization then it ought to be done with the namespace feature already provided by Java: the package declaration. I can't recall why that idea fell out of favor, though.
I'm +1 for dropping the prefixes.
On 2010.Jul.22, at 9.13p, David M Woollard wrote:
> 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.
>
> Anyone else have an opinion on the subject?
>
> -Dave
>
>
> [1] https://issues.apache.org/jira/browse/OODT-5
>
>
> On Jul 22, 2010, at 5:10 PM, Sean Kelly wrote:
>
>> I believe the overall goal is to have two part names for all modules:
>>
>> — cas-* for catalog/archive components
>> — grid-* for traditional oodt profile & product components
>> — oodt-* for common components
>>
>> So the correct dependency is cas-filemgr and the correct version should be ${oodt.version}, aka 0.1-incubating.
>>
>> I think.
>>
>>
>>> In addition to the jug/s problem Sean found, I have noticed that in two cases components (curator and crawler) depended on a filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-incubating.jar. I have changed these over for the time being (see r966887 and r966889), but I wanted those more knowledgeable of these three components know.
>>
>
Re: couple more pom issues
Posted by David M Woollard <wo...@jpl.nasa.gov>.
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" <wo...@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
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
Re: couple more pom issues
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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" <wo...@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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: couple more pom issues
Posted by David M Woollard <wo...@jpl.nasa.gov>.
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
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
Re: couple more pom issues
Posted by Sean Kelly <ke...@apache.org>.
Good argument, Chris.
Yeah, there are plenty of people out there who don't use Maven and who will blithely toss any set of files together into a directory in order to avoid changing java.ext.dirs, classpath, etc.
I'm convinced. +1 to toss in some prefixes on artifact names.
Thanks for setting us straight.
--k
Re: couple more pom issues
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: couple more pom issues
Posted by David M Woollard <wo...@jpl.nasa.gov>.
Sean, all,
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.
Anyone else have an opinion on the subject?
-Dave
[1] https://issues.apache.org/jira/browse/OODT-5
On Jul 22, 2010, at 5:10 PM, Sean Kelly wrote:
> I believe the overall goal is to have two part names for all modules:
>
> — cas-* for catalog/archive components
> — grid-* for traditional oodt profile & product components
> — oodt-* for common components
>
> So the correct dependency is cas-filemgr and the correct version should be ${oodt.version}, aka 0.1-incubating.
>
> I think.
>
>
>> In addition to the jug/s problem Sean found, I have noticed that in two cases components (curator and crawler) depended on a filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-incubating.jar. I have changed these over for the time being (see r966887 and r966889), but I wanted those more knowledgeable of these three components know.
>
Re: couple more pom issues
Posted by Sean Kelly <se...@mac.com>.
I believe the overall goal is to have two part names for all modules:
— cas-* for catalog/archive components
— grid-* for traditional oodt profile & product components
— oodt-* for common components
So the correct dependency is cas-filemgr and the correct version should be ${oodt.version}, aka 0.1-incubating.
I think.
> In addition to the jug/s problem Sean found, I have noticed that in two cases components (curator and crawler) depended on a filemgr-1.9-dev.jar rather than the cas-filemgr-0.1-incubating.jar. I have changed these over for the time being (see r966887 and r966889), but I wanted those more knowledgeable of these three components know.