[VOTE] Apache OODT 0.1-incubating release (rc2)
Hi Folks, After addressing some concerns on the mailing list regarding rc1 (hidden .svn dirs in the release and lack of a release date in the CHANGE.txt file), I have posted a 2nd release candidate for the Apache OODT 0.1-incubating release. The source code is at: http://people.apache.org/~woollard/apache-oodt-0.1-incubating/rc2/ For more detailed information, see the included CHANGES.txt file for details on release contents and latest changes. The release was made using the OODT release process, documented on the Wiki here: http://s.apache.org/05 The release was made from the OODT 0.1-incubating branch (r1026201) at: https://svn.apache.org/repos/asf/incubator/oodt/branches/0.1-incubating Please vote on releasing these packages as Apache OODT 0.1-incubating. The vote is open for the next 72 hours. Only votes from Incubator PMC are binding, but folks are welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. [ ] +1 Release the packages as Apache OODT 0.1-incubating [ ] -1 Do not release the packages because... Thanks! Dave Woollard P.S. Here is my +1.
Re: [VOTE] Apache OODT 0.1-incubating release
Rolling rc2 now... Stay tuned -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 Oct 21, 2010, at 7:56 PM, Mattmann, Chris A (388J) wrote: > Hi Dave (W.), > > Can we roll another release candidate? Sorry for the extra work. Read on > below why. (BTW: my official VOTE here is -1, but it's not that bad: the > release is actually quite good!). > > Signatures verify: (though we need a get a keysign party ;) ) > > vpicu-research:~/apache-oodt-0.1-incubating> gpg --import < > KEYS-0.1-incubating.txt > gpg: directory `/home/cmattmann/.gnupg' created > gpg: new configuration file `/home/cmattmann/.gnupg/gpg.conf' created > gpg: WARNING: options in `/home/cmattmann/.gnupg/gpg.conf' are not yet active > during this run > gpg: keyring `/home/cmattmann/.gnupg/secring.gpg' created > gpg: keyring `/home/cmattmann/.gnupg/pubring.gpg' created > gpg: /home/cmattmann/.gnupg/trustdb.gpg: trustdb created > gpg: key B876884A: public key "Chris Mattmann (CODE SIGNING KEY) > " imported > gpg: key F9D98BFA: public key "Sean Colin-Patrick Kelly (CODE SIGNING KEY) > " imported > gpg: key FF5B0BD5: public key "David Woollard (CODE SIGNING KEY) > " imported > gpg: Total number processed: 3 > gpg: imported: 3 (RSA: 2) > vpicu-research:~/apache-oodt-0.1-incubating> gpg --verify > apache-oodt-0.1-incubating-src.tar.gz.asc > gpg: Signature made Tue 19 Oct 2010 04:51:30 PM PDT using RSA key ID FF5B0BD5 > gpg: Good signature from "David Woollard (CODE SIGNING KEY) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: A128 73FB 4777 CDBC 9515 E94C 1191 1679 FF5B 0BD5 > vpicu-research:~/apache-oodt-0.1-incubating> > > MD5 and SHA1 checkout: > > vpicu-research:~/apache-oodt-0.1-incubating> md5sum --check > apache-oodt-0.1-incubating-src.tar.gz.md5 > apache-oodt-0.1-incubating-src.tar.gz: OK > vpicu-research:~/apache-oodt-0.1-incubating> > > vpicu-research:~/apache-oodt-0.1-incubating> openssl sha1 > apache-oodt-0.1-incubating-src.tar.gz > oodt.sha1 > vpicu-research:~/apache-oodt-0.1-incubating> diff oodt.sha1 > apache-oodt-0.1-incubating-src.tar.gz.sha1 > vpicu-research:~/apache-oodt-0.1-incubating> > > > Nit: CHANGES.txt doesn't include release date (still says Current > Development). Not a blocker, but something to update the release guide on the > Wiki with (volunteers?) :) Since I think we should roll another RC, maybe we > could update this file and add a release date in it. > > I built using mvn install (which runs mvn test): > > I installed the basic filemgr, workflow, and resource components, and ran > through basic acceptance tests for each user guide. I did the same for > crawler and for pushpull. I also stood up a basic XMLPS service + WebGrid and > all is well. > > FANTASTIC JOB. This has been a long time coming. > > Now, here's why I am -1. :) This release includes .svn hidden dirs in it. We > need to "svn export" the release instead of "svn co", which it looks like you > did. I don't think we should push out a release that includes the .svn hidden > dirs. > > Can others please chime in as time permits. Would be great to hear from other > OODT PPMC'ers - guys releasing is what Apache is all about. Please check the > release and VOTE your opinion. (BTW: checking means diff things to diff > people. Some folks might not have time to go through all the guides, etc., > but if you have time to verify the sigs, and verify the checksums, and maybe > run unit tests, that would be great too). > > Dave, I've got time so if you roll another RC quickly, I can even look at it > tonight. > > Thanks much. > > Cheers, > Chris > > > On 10/19/10 6:07 PM, "David M Woollard" wrote: > > Hi Folks, > > I am proud to announce the first candidate for the Apache OODT 0.1-incubating > release. The source code is at: > > http://people.apache.org/~woollard/apache-oodt-0.1-incubating/rc1/ > > For more detailed information, see the included CHANGES.txt file for details > on > release contents and latest changes. The release was made using the
[VOTE] Apache OODT 0.1-incubating release
Hi Folks, I am proud to announce the first candidate for the Apache OODT 0.1-incubating release. The source code is at: http://people.apache.org/~woollard/apache-oodt-0.1-incubating/rc1/ For more detailed information, see the included CHANGES.txt file for details on release contents and latest changes. The release was made using the OODT release process, documented on the Wiki here: http://s.apache.org/05 The release was made from the OODT 0.1-incubating branch (r1024310) at: https://svn.apache.org/repos/asf/incubator/oodt/branches/0.1-incubating Please vote on releasing these packages as Apache OODT 0.1-incubating. The vote is open for the next 72 hours. Only votes from Incubator PMC are binding, but folks are welcome to check the release candidate and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. [ ] +1 Release the packages as Apache OODT [ ] -1 Do not release the packages because... Thanks! Dave Woollard P.S. Here is my +1.
Re: Possible problem with "grid" module
Makes sense to me... onward with the release. -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 Oct 18, 2010, at 4:47 PM, Mattmann, Chris A (388J) wrote: > Hi Dave, > > I¹d say: RC away. It would be great for Dave (K.) to report where in the > list of 13 steps below he is getting an error. Talking with him about this > over Skype, it seems like he is having some sort of environment issue, > though I need to verify that. Either way, Dave (K.) has a work-around and I > don¹t think this should prevent the RC. And, even if Dave (K.) *does* think > it should prevent the RC, he can VOTE -1, and express that :) > > Cheers, > Chris > > > > On 10/18/10 3:22 PM, "David M Woollard" wrote: > >> Hey Guys, >> >> I'm starting work on a RC for 0.1-incubating. I have just been doing some >> basic setup stuff (pgp keys and the whatnot), so I have not yet made a RC >> tag. >> Paul, do you want a little time to work this issue? Sounds like it is not a >> blocker for the release, but I can hold off for a couple hours if you have >> the >> cycles to do it now. >> >> -Dave >> >> On Oct 18, 2010, at 3:15 PM, Ramirez, Paul M (388J) wrote: >> >>> Hey Dave, >>> >>> Thanks for the follow up sounds like we may have a bug in the conversion >>> over >>> to Apache for this component in the way it references the path to the >>> driver. >>> Can you open an issue on this component in essentially using your email and >>> state the environment you are running in. Feel free to assign the issue to >>> me >>> if you have the ability when creating the issue. >>> >>> Thanks, >>> Paul >>> >>> On Oct 18, 2010, at 10:09 AM, David Kale wrote: >>> >>>> Paul, >>>> >>>> Thank you for following up and reminding me to send you guys an update. >>>> No, >>>> Chris' changes and his set of instructions did not help me out. >>>> >>>> Basically what we come down to is the following: I'm using the jtds driver >>>> to connect to a SQL Server. *When I use the web-grid configuration page to >>>> specify the path to the driver jar file in the code bases, I get the "no >>>> suitable driver found" error. If I manually copy the driver jar file into >>>> $TOMCAT/webapps/grid/WEB-INF/lib, it works just fine. *I would further add >>>> that I'm also using the configuration page to point to XMLPS, and that >>>> works >>>> just fine. It's quite bizarre. >>>> >>>> The good news is that I have something working (by manually copying the jar >>>> file), but in the long run, we should try to figure this out, I suppose. >>>> >>>> Also, for XMLPS, there is no need to do compile assembly:assembly. >>>> >>>> Dave >>>> >>>> >>>> >>>> On Mon, Oct 18, 2010 at 7:33 AM, Ramirez, Paul M (388J) < >>>> paul.m.rami...@jpl.nasa.gov> wrote: >>>> >>>>> Hey Dave, >>>>> >>>>> Was taken out by a cold this weekend did Chris' changes resolve your >>>>> issue? >>>>> If not let me know and I'll try to test out an install of webgrid from >>>>> Apache OODT as Chris outlined below. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On Oct 15, 2010, at 4:26 PM, Sean Kelly wrote: >>>>> >>>>>> Colleagues: >>>>>> >>>>>> Thanks for fixing the old jpl.eda references in web-grid. As it was >>>>> neglected in the original import of OODT code from JPL into the Apache >>>>> Incubator, it did not get the rigorous examination that we afforded the >>>>> other components. >>>>>> >>>>>> Warm spal wishes, >>>>>> Er, I mean warm swimming wishes, >>>>>> Oops, I mean take care of your pool, >>>>>> GAH! >>>>>> Just thanks OK!?! >>>>>> >>>>
Re: Possible problem with "grid" module
Hey Guys, I'm starting work on a RC for 0.1-incubating. I have just been doing some basic setup stuff (pgp keys and the whatnot), so I have not yet made a RC tag. Paul, do you want a little time to work this issue? Sounds like it is not a blocker for the release, but I can hold off for a couple hours if you have the cycles to do it now. -Dave On Oct 18, 2010, at 3:15 PM, Ramirez, Paul M (388J) wrote: > Hey Dave, > > Thanks for the follow up sounds like we may have a bug in the conversion over > to Apache for this component in the way it references the path to the driver. > Can you open an issue on this component in essentially using your email and > state the environment you are running in. Feel free to assign the issue to me > if you have the ability when creating the issue. > > Thanks, > Paul > > On Oct 18, 2010, at 10:09 AM, David Kale wrote: > >> Paul, >> >> Thank you for following up and reminding me to send you guys an update. No, >> Chris' changes and his set of instructions did not help me out. >> >> Basically what we come down to is the following: I'm using the jtds driver >> to connect to a SQL Server. *When I use the web-grid configuration page to >> specify the path to the driver jar file in the code bases, I get the "no >> suitable driver found" error. If I manually copy the driver jar file into >> $TOMCAT/webapps/grid/WEB-INF/lib, it works just fine. *I would further add >> that I'm also using the configuration page to point to XMLPS, and that works >> just fine. It's quite bizarre. >> >> The good news is that I have something working (by manually copying the jar >> file), but in the long run, we should try to figure this out, I suppose. >> >> Also, for XMLPS, there is no need to do compile assembly:assembly. >> >> Dave >> >> >> >> On Mon, Oct 18, 2010 at 7:33 AM, Ramirez, Paul M (388J) < >> paul.m.rami...@jpl.nasa.gov> wrote: >> >>> Hey Dave, >>> >>> Was taken out by a cold this weekend did Chris' changes resolve your issue? >>> If not let me know and I'll try to test out an install of webgrid from >>> Apache OODT as Chris outlined below. >>> >>> Thanks, >>> Paul >>> >>> On Oct 15, 2010, at 4:26 PM, Sean Kelly wrote: >>> Colleagues: Thanks for fixing the old jpl.eda references in web-grid. As it was >>> neglected in the original import of OODT code from JPL into the Apache >>> Incubator, it did not get the rigorous examination that we afforded the >>> other components. Warm spal wishes, Er, I mean warm swimming wishes, Oops, I mean take care of your pool, GAH! Just thanks OK!?! On 2010.Oct.15, at 6.16p, Mattmann, Chris A (388J) wrote: > Hi Guys, > > OK I was able to checkout a fresh copy of Apache OODT from Incubator >>> SVN, build Web-Grid, XMLPS and then connect to a local Postgres DB with some >>> dummy data in it on my local machine and do a query and it worked. I did >>> find one (documentation) bug wherein which the example XML mapping file >>> checked in for XMLPS doesn't put the >> file and thus won't parse. I've filed an issue OODT-46 [1] and will commit a >>> fix for that shortly. I also noticed that the Web-Grid pages mention classes >>> that implement the jpl.eda.product... Interfaces rather than >>> org.apache.oodt.product... so I've filed OODT-47 [2] to fix that. Finally I >>> fixed an issue with WildcardLiterals in OODT-48 [3] and have fixed that. > > Here are the steps to reproduce a working Web-Grid with XMLPS: > > > 1. svn co latest OODT from trunk > 2. mvn install from OODT/trunk top level > 3. cd grid > 4. mvn package war:war (builds target/web-grid-0.1-incubating.war) > 5. cd ../xmlps > 6. mvn package assembly:assembly (builds >>> target/oodt-xmlps-0.1-incubating-with-dependencies.jar) > 7. create test area, e.g., /usr/local/xmlpstest and copy >>> oodt-xmlps-0.1-incubating-with-dependencies.jar to it > 8. copy example conf files out of xmlps/src/main/conf >>> (example.db.properties and example-ps.xml) into test area > 9. modify examples for your database (I used a local postgres instance >>> and I created a simple mapping file with 2 fields, one dynamic and one >>> constant that queried 1 database) > 10. copy WAR file to $TOMCAT_HOME/webapps/grid.war > 11. visit http://localhost:8080/grid/ > 12. Configure web-grid after logging in to use XMLPS handler, to >>> reference your JDBC jar file (that you copy into /usr/local/xmlpstest), and >>> to reference XMLPS jar file in /usr/local/xmlpstest > 13. try a query at: http://localhost:8080/grid/prod?q= > > > Would be great to turn the above into some XDOCS for webgrid and for >>> xmlps :) I'll do it later if no one else does, probably after the >>> 0.1-incubating release. > > Cheers, > Chris > > [1] https://issues.apache.org/jira/browse/OODT-46 > [2] https://issues.apache.org/jira/browse/OO
Pending release
Chris, Looks like we are basically ready with your closeout on OODT-22. If I start the process tomorrow AM, will I capture all that you intended for push-pull? -Dave
Re: 0.1 release status . . .
Paul, Thanks for volunteering to be a second person on this. Your comment RE a go minus OODT-22 is my understanding as well. I'm happy to still be the release manager this time even with job stuff, but lets see the actual timing of the release before I make that blanket comment. If it pushes out to end of oct, then lets coordinate and figure out how to make this happen expeditiously. Thanks! 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 Oct 13, 2010, at 6:30 AM, Ramirez, Paul M (388J) wrote: > Hey All, > > Dave I know you are going to be in transition to a new job soon so I was > wondering if you are still going to have the time to be release manager on > version 0.1. If you're not available for this release I don't mind picking up > the shovel but as this point I'm still assuming everything is a go minus > OODT-22. My time should be freeing up at the end of October and I'd like to > help us get over that 0.1 hurdle. Mostly, I'm just bumping this thread for us > to set a date for release. > > Via Con Dios, > Paul > > > On Oct 5, 2010, at 10:40 AM, David Kale wrote: > >> Hooray! >> >> On Mon, Oct 4, 2010 at 6:29 PM, David M Woollard >> wrote: >> >>> Sounds like a good plan to me! >>> >>> -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 Oct 4, 2010, at 6:00 PM, Mattmann, Chris A (388J) wrote: >>> >>>> Let me wrap up the push pull changes I'm doing in OODT-22 (which include >>> not just Apache compliance, but unit tests and ...a user guide based on >>> Brian's original one!), hopefully in the next few days. If all goes well, >>> Dave, I'd like you to call a release and throw out an RC by end of week... >>>> >>>> Cheers, >>>> Chris >>>> >>>> >>>> On 10/4/10 3:55 PM, "Woollard, David M (388J)" < >>> david.m.wooll...@jpl.nasa.gov> wrote: >>>> >>>> Hey Brian, >>>> >>>> Looking at OODT's JIRA issues, there is only one issue unresolved >>>> right now (oodt-22). We should be good to go with a 0.1 release as >>>> soon as this gets resolved or pushed to 0.2. Chris, since you are the >>>> current assignee, what are your thoughts on pushing a release? >>>> >>>> Dave >>>> >>>> Sent from my iPhone >>>> >>>> On Oct 4, 2010, at 3:50 PM, "Brian Foster" wrote: >>>> >>>>> >>>>> hey guys! >>>>> >>>>> just checking in on 0.1 release status . . . i have many >>>>> improvements in JPL branches which i would >>>>> like to start patching into Apache trunk . . . but would rather wait >>>>> until current trunk, which seems pretty >>>>> stable, has been tagged. >>>>> >>>>> thanks! >>>>> -brian >>>> >>>> >>>> >>>> ++ >>>> Chris Mattmann, Ph.D. >>>> Senior Computer Scientist >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>>> Office: 171-266B, Mailstop: 171-246 >>>> Email: chris.mattm...@jpl.nasa.gov >>>> WWW: http://sunset.usc.edu/~mattmann/<http://sunset.usc.edu/%7Emattmann/> >>>> ++ >>>> Adjunct Assistant Professor, Computer Science Department >>>> University of Southern California, Los Angeles, CA 90089 USA >>>> ++ >>>> >>> >>> >
Re: 0.1 release status . . .
Sounds like a good plan to me! -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 Oct 4, 2010, at 6:00 PM, Mattmann, Chris A (388J) wrote: > Let me wrap up the push pull changes I'm doing in OODT-22 (which include not > just Apache compliance, but unit tests and ...a user guide based on Brian's > original one!), hopefully in the next few days. If all goes well, Dave, I'd > like you to call a release and throw out an RC by end of week... > > Cheers, > Chris > > > On 10/4/10 3:55 PM, "Woollard, David M (388J)" > wrote: > > Hey Brian, > > Looking at OODT's JIRA issues, there is only one issue unresolved > right now (oodt-22). We should be good to go with a 0.1 release as > soon as this gets resolved or pushed to 0.2. Chris, since you are the > current assignee, what are your thoughts on pushing a release? > > Dave > > Sent from my iPhone > > On Oct 4, 2010, at 3:50 PM, "Brian Foster" wrote: > >> >> hey guys! >> >> just checking in on 0.1 release status . . . i have many >> improvements in JPL branches which i would >> like to start patching into Apache trunk . . . but would rather wait >> until current trunk, which seems pretty >> stable, has been tagged. >> >> thanks! >> -brian > > > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.mattm...@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: An alternative proposal RE jacorb
Well, never mind. Looks like a moot point. See the legal discuss archive. Thanks Chris for pushing this through. Looks like we are going to be able to cut a release presently! -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 Sep 26, 2010, at 7:18 PM, David M Woollard wrote: > All, > > I am not sure how many of you follow Apache Legal [1], but Chris is currently > leading a discussion on OODT's possible use of jacorb [2] as referenced in > [3]. > > Paul and I were chatting recently and he suggested (and I agree) that, while > the issue is being debated (and the dependency possibly replaced), we might > move forward with the release of 0.1 incubating leaving out the non-grid > product and profile components (which will then be released with > 0.2-incubating). It is my understanding that the grid product and profile are > the more common deployments these days (I for one haven't used CORBA in a > long, long time). > > I thought I might just through this out and see what opinions where out there. > > -Dave > > [1] legal-disc...@apache.org > [2] http://s.apache.org/7Ba > [3] https://issues.apache.org/jira/browse/OODT-25 > > - > 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 > > > > >
An alternative proposal RE jacorb
All, I am not sure how many of you follow Apache Legal [1], but Chris is currently leading a discussion on OODT's possible use of jacorb [2] as referenced in [3]. Paul and I were chatting recently and he suggested (and I agree) that, while the issue is being debated (and the dependency possibly replaced), we might move forward with the release of 0.1 incubating leaving out the non-grid product and profile components (which will then be released with 0.2-incubating). It is my understanding that the grid product and profile are the more common deployments these days (I for one haven't used CORBA in a long, long time). I thought I might just through this out and see what opinions where out there. -Dave [1] legal-disc...@apache.org [2] http://s.apache.org/7Ba [3] https://issues.apache.org/jira/browse/OODT-25 ----- 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: [ANNOUNCE] Welcome David Kale as an OODT Committer
David, Welcome! Thanks for your contributions and please keep 'em coming! ;) -Dave W. - 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 Sep 26, 2010, at 10:22 AM, Mattmann, Chris A (388J) wrote: > Hi Folks, > > A while back I nominated David Kale for OODT committership and PPMC > membership. The VOTE tallies in OODT PPMC-ville and Incubator PMC-ville have > occurred and I'm happy to announce that David is now an OODT committer! > > David, feel free to say a little bit about yourself, and, welcome aboard! > > 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.mattm...@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: [jira] Updated: (OODT-28) OODT use case descriptions
Bruce, There are a number of formats for documentation that are easily integrated into our existing user's guides, website, etc. As mentioned in the comment, one of these formats is xDoc. You can check out this reference [1]. Otherwise, since it is on the mailing list and has an issue, we will try to move on it soon. Though I think Chris thanked you on the mailing list, I'll do it as well. Thanks for the contribution! -Dave [1] http://maven.apache.org/doxia/references/xdoc-format.html ----- 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 Sep 3, 2010, at 8:28 AM, Bruce Barkstrom wrote: > What, if anything do I need to do? > > On Thu, Sep 2, 2010 at 11:48 PM, Chris A. Mattmann (JIRA) > wrote: > >> >>[ >> https://issues.apache.org/jira/browse/OODT-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] >> >> Chris A. Mattmann updated OODT-28: >> -- >> >> Fix Version/s: 0.2-incubating >> >>> OODT use case descriptions >>> -- >>> >>>Key: OODT-28 >>>URL: https://issues.apache.org/jira/browse/OODT-28 >>>Project: OODT >>> Issue Type: New Feature >>> Components: website >>> Reporter: Chris A. Mattmann >>>Fix For: 0.2-incubating >>> >>> >>> Bruce Barkstrom sent a message to the OODT email list [1] including a use >> case that he came up with from OODT. We should figure out a way: >>> 1. to include this use case on the site (convert the ODT file into >> something like Maven XDOC?) >>> 2. include the ODT as a site ersource and link to it >>> Or anything else that folks can think of. We'll track the issue here. >>> [1] http://s.apache.org/9f4 >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >>
Re: Question about RAT blocking the standard build process
Guys,
I might also include in the discussion an email that I found useful in deciding
how to incorporate RAT [1]. I'd invite others, including Ross, to comment as
well, but I think there is great value in knowing immediately if something is
potentially problematic from a licensing perspective.
Some use cases in which I think this is helpful:
1) Vetting a contributed patch. The committer will immediately be informed of
any licensing issues that need to be addressed with the patch.
2) Smaller, incremental additions of new project artifacts. You know when you
have a licensing problem.
Some cases were it is less useful:
3) Porting a larger set of existing artifacts.
To date, we have only included RAT in the build for components that have
already been fully ported from JPL land to Apache and have been vetted for
licensing (see OODT-3 [2]), so this should mainly be applicable to scenarios
one and two.
-Dave
[1]
http://mail-archives.apache.org/mod_mbox/incubator-rat-dev/200911.mbox/%3c61c9bc470911171514u41825c9ud28bd3276ab3b...@mail.gmail.com%3e
[2] https://issues.apache.org/jira/browse/OODT-3
-
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 Sep 1, 2010, at 10:54 AM, Mattmann, Chris A (388J) wrote:
> Hi Andrew and Dave,
>
> Interesting. Yeah I think that RAT shouldn't per se block a build unless we
> specifically ask it to (i.e., where it matters, on releases and
> distribution). That said, I think this can be overcome by commenting out the
> RAT plugin in your xmlps code. Question: the code you are developing with
> xmlps for OODT-29: does that have license info in it? If not, then that's
> likely why RAT is choking, but you're probably already aware of that. If the
> answer there is, the priority is functionality over license stuff before the
> patch, I totally understand and my suggesting would be to just remove the RAT
> parts from the xmlps POM for now, until you're ready to integrate.
>
> HTH,
> Chris
>
>
>
> On 9/1/10 10:29 AM, "Andrew Hart" wrote:
>
> Hey guys,
>
> Can anyone provide me with a little bit of information as to what is
> going on here?
>
> I'm working with Dave Kale to implement OODT-29 (import web-grid into
> apache oodt) and we've recently been frustrated by something which
> appears to be related to RAT being a little (too?) controlling.
>
> We're in the debug stages of OODT-29, we've got a lot of work to do to
> change jpl.eda namespaces, unit tests, etc over to o.a.oodt and, in the
> process, we're attempting to compile and build occasionally as a sanity
> check. The problem is, RAT won't let us do this at the moment:
>
> mvn -e install (from within xmlps)
>
> gives us:
>
> INFO] [rat:check {execution: default}]
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Too many unapproved licenses: 0
> [INFO]
>
> [INFO] Trace
> org.apache.maven.BuildFailureException: Too many unapproved licenses: 0
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
> ...
> Caused by: org.codehaus.mojo.rat.RatCheckException: Too many unapproved
> licenses: 0
> at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:224)
> at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:216)
> at org.codehaus.mojo.rat.RatCheckMojo.execute(RatCheckMojo.java:172)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> [INFO]
>
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Sep 01 09:54:25 PDT 2010
> [INFO] Final Memory: 50M/1132M
> [INFO]
>
>
>
> This didn't seem to be happening on earlier builds.
>
> A warning about licenses would be welcome, but forcing the build to fail
> is maybe excessive? In fact, the jar actually DOES build, the only
> effect this apparently has
Re: Question about RAT blocking the standard build process
Andrew,
I introduced RAT as part of the build process while working toward closing out
OODT-3 [1]. The reason for running RAT as part of the builds for some
components is that we know immediately when we introduce code that is not
compliant with licensing, nor do will build and push out anything that does not
have the correct headers.
To clarify further, RAT is part of the build process for the established
components that have been vetted for licensing issues at this point. If you are
making modifications to one of these components locally, then you have three
choices right now if you're build breaks on RAT.
1) Make sure the files you are including are correctly licensed w/ Apache
headers
2) If the files should not have Apache licenses for some reason (e.g., third
party licensing, test files that much be of a particular format, files that do
not contain any intellectual property), add the files to the RAT exceptions in
the pom file.
3) If you are building locally, you can always comment out RAT (but I would say
that you do so at your own risk in as much as any patch, etc much be rat
compliant eventually)
We can certainly have a discussion on the merits of incorporating RAT via a
target separate from the main build cycle, but I for one see substantial
benefits to incorporating RAT so we all know as soon as we introduce something
incompatible with licensing. Might I ask what you are working on and perhaps
have you submit a patch that currently breaks the build?
-Dave
[1] https://issues.apache.org/jira/browse/OODT-3
On Sep 1, 2010, at 10:29 AM, Andrew Hart wrote:
> Hey guys,
>
> Can anyone provide me with a little bit of information as to what is
> going on here?
>
> I'm working with Dave Kale to implement OODT-29 (import web-grid into
> apache oodt) and we've recently been frustrated by something which
> appears to be related to RAT being a little (too?) controlling.
>
> We're in the debug stages of OODT-29, we've got a lot of work to do to
> change jpl.eda namespaces, unit tests, etc over to o.a.oodt and, in the
> process, we're attempting to compile and build occasionally as a sanity
> check. The problem is, RAT won't let us do this at the moment:
>
> mvn -e install (from within xmlps)
>
> gives us:
>
> INFO] [rat:check {execution: default}]
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Too many unapproved licenses: 0
> [INFO]
>
> [INFO] Trace
> org.apache.maven.BuildFailureException: Too many unapproved licenses: 0
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
> ...
> Caused by: org.codehaus.mojo.rat.RatCheckException: Too many unapproved
> licenses: 0
> at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:224)
> at org.codehaus.mojo.rat.RatCheckMojo.check(RatCheckMojo.java:216)
> at org.codehaus.mojo.rat.RatCheckMojo.execute(RatCheckMojo.java:172)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> [INFO]
>
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Sep 01 09:54:25 PDT 2010
> [INFO] Final Memory: 50M/1132M
> [INFO]
>
>
>
> This didn't seem to be happening on earlier builds.
>
> A warning about licenses would be welcome, but forcing the build to fail
> is maybe excessive? In fact, the jar actually DOES build, the only
> effect this apparently has is that it prevents mvn from copying the jar
> into the local .m2 repository.
>
> I'm interested to know when this behavior became a part of the standard
> build. Given that there are multiple other checkpoints at which RAT is
> run to verify license compliance, I'm curious as to why have this here?
> As an alternative, could we consider making a special build target, i.e.:
>
> "mvn validate install"
>
> that might include the added RAT checks and could be run when we
> explicitly wish to confirm compliance?
>
> - Andrew.
>
>
>
>
Re: Setting the commit bar for OODT?
Chris, I think this is a great enumeration of possible paths. I agree in the end that more people feeling positive about their involvement with OODT is an important factor in developing the external community that we need. I think that a good part of that is commit access. I would be in favor of setting the bar relatively low, but not giving it out "like candy." As long as we are in a position of reviewing patches quickly and getting back to people, why not have the approach be, "give us a patch or two, figure out how to be a good developer on the project by understanding the site, unit tests, etc., and then we will give you access." IMO, this is a relatively low bar (others feel free to chime in). I'm not interested in playing overlord to anyone, nor do I want to be in a position where we have a butch of committers that i don't feel conformable trusting. To that end, I feel like what Chris suggested is enough to give me warm and fuzzy feelings about the potential committer. Of course, things change over time, and if, a year from now, we see people who want to be involved have patches sit around for 6+ months (as is the case on some other projects), then we might need to revisit the issue. -Dave On Aug 16, 2010, at 10:41 PM, Mattmann, Chris A (388J) wrote: > Hey Justin, > > Great thoughts, and great to have the discussion in public. > > I¹ve seen a lot of different models for this, mainly based on criteria like: > > A) time a contributor has to wait > B) complexity of patches submitted by a contributor > C) resistance to contributor's patches by committership/PMC for whatever > reason (business, resistance to personalities, etc.) > D) recognition of support/assistance at the *right time* from contributors > > To me the single most important factor has really been D (which is really > dependent on where the project is in its life). I've seen projects go from > totally healthy to stagnant, and see the bar for committership change based > on that. I remember way back in the Nutch days in 2005, when Hadoop, Tika > and a slew of other projects were all incubating inside of it, the bar for > committership was VERY high. I (and other contributors but not committers) > had something like the httpd/APR experience, but even worse. > > I've seen Nutch go from that in 2005-2007, to stagnating and nearly dying > off, to some fresh new blood coming in, and to us doing some internal gazing > at whether or not we should loosen the bar to encourage those that are > contributing via documentation or emails, or that have contributed even a > few decent patches to be considered for committership, because let's be > honest, it's a honor, and it really does motivate a contributor to be > *rewarded* with a gold Apache badge in the form of an email address and SVN > access. > > I've also seen projects be very open from the get-go, and encouraging of new > contributors which I'd classify as my Tika experience. It's really worked > out, and we usually have folks like Jukka who are great at monitoring who's > helping out even a little bit and who is on our watchlist and things like > that. > > For OODT...I really think we're at a point where my personal belief is to > reward those that show interest, and that are willing to try things like: > > 1. building the website, and updating documentation (Sean Kelly's OODT site > builder rox, it's the perfect combination of Python, Java, Maven, and well a > dozen other technologies I don't really understand). LOL. That said, running > the process here [1] to build the website and test out a new website patch > is a feat in itself and those that have success in doing this even 1x times, > and that submit a patch for it should be considered for committership at > some point soonish. > > 2. fixing bugs - we've had less of these types of patches from outside the > committership, but that's probably a function of just trying to get the > o...@apache code building and the licenses fixed, and all the JPL specific > stuff removed. It's been a huge effort on that part, and we're just now at a > point where the code is really useable. So, a lot of the bugs/etc. patches > that will be coming here in the near future will still likely be folks who > are using OODT in their existing environments, but who have found/fixed bugs > that can be turned around and started to be ported to Apache OODT, which is > what we're asking all existing OODT projects to do. > > 3. running unit tests and helping to get the existing build working and in > tip-top order so we can make a release. This has mostly been a committer > activity so far, but we did get a patch way back when from the CHLA folks > who were trying to help out on this. > > 4. New documentation, graphics, logos. We had some great contributions from > the CHLA folks on these too. > > Of course, the complexity, quality, and timeliness of patches in 1-4 above > will vary *significantly*, but at this stage, my feeling would be
Re: [DISCUSS] OODT Podling Incubator Experiment (was Re: Radical revamp (was: an experiment))
Sorry if I'm late to the party, but my 2 cents... The more I read about this, the more I latch onto Justin's "Observers" notion. As a non-Apache Member, non-IPMC, PPMC member for OODT, I feel like I am qualified to vote on a release in the sense that I am closer to the code than Justin (sorry to pick on you, but I think I'm just parroting what you have been saying), but I also would love to have more experienced hands looking at other aspects (most notably in my mind are the various legal aspects). In the end, I think that it takes both of these types of input to get what I'd call an "informed" vote. But all of this discussion in my mind hinges on the fundamental problems... good mentors and the notion of etiquette, both of which have previously been mentioned on all of these intwined threads. Realistically, as long as an individual podling is open to the entire incubation community, you will find some rules hawk that really believes by invoking article 237 of document XYZ they are helping to instruct in the Apache way. It's in cases where this happens that I would ask a mentor (someone I know who has even a slight investment in my podling's success), to sort the wheat from the chaff. Also MHO, but it strikes me that being part of the community, rather than in some sort of over-lord position, is more in line with the flat structure that is an important part of the Apache way. > If we ran it with the intention that the PMC is there to solely > provide non-technical oversight and that the PPMC does the actual > work, I think that's something I could live with and address my > concerns in the overall process. +1. Being the kind of person who likes to trust people, I'm fine with a informal agreement. If you feel like you can contribute technically, then I would love to hear what you had to say and if you just want to comment on process, I think that's A-OK too. IMO, as long as you have taken some step to be part of the specific podling, then you get to say anything you want (you are part of the community). Like Chris, I would be up for trying something with OODT. Any proposal that we can work, even if just by general agreement, where we can logically divide technical oversight from non-technical and also protect us from random drive-bys gets my vote. -Dave On Aug 16, 2010, at 10:37 PM, Justin Erenkrantz wrote: > On Mon, Aug 16, 2010 at 10:20 PM, Greg Stein wrote: >> You know when to vote and *how* to vote. I see no reason to deny your vote. > > Of course. It's always seemed awkward if you can't contribute > technically to suddenly have a binding vote. I'm sure if I *wanted* > to learn how to build something with Maven, I could. But, why? =) > > So, it makes me leery on being forced to cast a vote on a release - on > par with those who have actually tested it and know something about > the codebase. The standard that I force myself to adhere to on > Subversion and httpd for example would be something that I'd fall > short with in OODT. > >> The (only) problem to arise would be if OODT was at the minimum of (3) >> ASF Members, and your vote was required. With Chris becoming a Member, >> OODT is at 5 Members that could comprise the mini/pseudo TLP that I >> propose. (maybe there are others interested, but I have zero insight >> into this community) > > Sure. It's just that Chris and I have discussed the pain points in > the Incubation process, so we're on the lookout for making it easier > on us. =) Plus, the experience with Subversion also showed me where > things break down too. > >> I'm not sure that I'm reading the above properly, but... whatevs. >> Under my proposed TLP-based approach, the PMC would be comprised of: >> justin, jean, ross, ian, chris. The current committers (who are also >> on the PPMC, presumably) would be invited to the private@ list, but >> would not be on the PMC. Thus, they would have non-binding votes >> across all project decisions. But that should not be a problem as >> those PMC members also understand how to build and listen to >> consensus. If there are issues in the community, then the difference >> between binding and non-binding votes makes *zero* difference. > > If we ran it with the intention that the PMC is there to solely > provide non-technical oversight and that the PPMC does the actual > work, I think that's something I could live with and address my > concerns in the overall process. > > I don't think this is at odds with what you are saying nor would it > run afoul of any corporate structures. It could just be the informal > agreement between the PMC members that the PPMC should be the ones > making the technical decisions. (If some other set of mentors wanted > to run it differently, they could. But, this separation is one I > could live with myself.) > >> The (podling) project/PMC would report directly to the Board. No more >> peanut gallery, or a second-guessing group. > > Right. The listed members of the P
Re: 0.1-incubating release coming soon
Thanks for the help... I assume I will need a lot of it the first time around ;)! On Aug 2, 2010, at 8:48 AM, Mattmann, Chris A (388J) wrote: > Hi Dave, > > +1 for you as an RM. Probably good for someone besides me to do it. > > I'll be happy to help you along the way. > > Cheers, > Chris > > > > On 8/2/10 8:45 AM, "David M Woollard" wrote: > > All, > > Based on the discussions surrounding OODT-3 and OODT-15, it looks like we are > getting very near being able to make our first Apache release (super > excited!). I'd like to volunteer to be release manager this time around so as > to better learn the process and to have a couple of people on the project who > know how to do it. > > I'm expecting to close out OODT-3 with the help of legal in the next week or > so, and, based on Chris' emails, I think he expects OODT-15 and the push-pull > improvements he is working on to be wrapped up in the timeframe as well. I'll > target getting a release candidate together a few days after these issues are > resolved, though if someone has a strong feeling on any other outstanding > issues, please let me know. > > Thanks! > -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 > > > > > > > > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.mattm...@jpl.nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ >
0.1-incubating release coming soon
All, Based on the discussions surrounding OODT-3 and OODT-15, it looks like we are getting very near being able to make our first Apache release (super excited!). I'd like to volunteer to be release manager this time around so as to better learn the process and to have a couple of people on the project who know how to do it. I'm expecting to close out OODT-3 with the help of legal in the next week or so, and, based on Chris' emails, I think he expects OODT-15 and the push-pull improvements he is working on to be wrapped up in the timeframe as well. I'll target getting a release candidate together a few days after these issues are resolved, though if someone has a strong feeling on any other outstanding issues, please let me know. Thanks! -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: Website: TA-DA!
Woot! Woot! I'm continuing work on OODT-3, so I think once we have those two issues resolved, it will be release time... -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 Aug 1, 2010, at 1:15 PM, Mattmann, Chris A (388J) wrote: > thanks to kelly, we've got a website: > > http://incubator.apache.org/oodt/ > > Updates, welcome, but I think it rocks for now and is good enough for an > initial release. I'll focus my efforts now on OODT-15, and wrapping up > integration of pushpull. > > 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.mattm...@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: Prototype Apache OODT website
Rockem Sockem yo! Yep, I think it reads great. Now, to generate more content! -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 28, 2010, at 9:03 AM, Sean Kelly wrote: >> First off, this site is BADA$$! I read through it and I am going to try to >> carve off a little time to augment the CAS page with some more detailed >> descriptions of those components and maybe some organization. > > Thanks and that would be great! Truly, the script to generate the site was > the easy part—it's all the content that's hard! > > The CAS page is in > https://svn.apache.org/repos/asf/incubator/oodt/docs/site/components/cas. Add > graphics if you can. Graphics are sexy. > >> Regarding the logo, I, for one, really like the elements idea. I think the >> only confusing part is that it does not quite read oodt if you are like me >> and never pay 100% attention to anything ;). What if you tried to fade that >> second letter out a little more or make it smaller, or both (or left it >> alone and told me to shut up)? Just some thoughts... > > I likey. See attached for a sample. Feelings? > >
Re: Prototype Apache OODT website
Sean, First off, this site is BADA$$! I read through it and I am going to try to carve off a little time to augment the CAS page with some more detailed descriptions of those components and maybe some organization. Regarding the logo, I, for one, really like the elements idea. I think the only confusing part is that it does not quite read oodt if you are like me and never pay 100% attention to anything ;). What if you tried to fade that second letter out a little more or make it smaller, or both (or left it alone and told me to shut up)? Just some thoughts... -Dave On Jul 28, 2010, at 7:04 AM, Sean Kelly wrote: > OK if no one else objects I'll go ahead and move forward with this. Thanks! > >> P.S. Minor thing, but why Ob and Or instead of O and O on the OO blocks that >> are part of "OODT"? > > Chemistry. Heh. > > The advertising idea: I want it to look like chemical elements from a > periodic table to emphasize OODT's science lineage. But O and O with two > different atomic weights is illogical, and Ob & Or look more like chemical > elements. E.g.: > > Ob₁₂Or₁₆D₃T₂₀ = Apache OODT = something to get you totally baked > > Anyone got a better concept & banner image? I'm not wedded to this concept. > > --k > > PS: Don Draper makes it look so easy on Mad Men. ^_^
unsatisfied dependency for cas-catalog
All,
I have been working on incorporating RAT as part of the build process for maven
built components, and I found that the pom file for cas-catalog had not been
switched over to utilize the apache namespacing, parent pom, and
${oodt.version}. After switching these over, I noticed that the build depends
on an oracle ojdbc jar that does not seem to be publicly available?
Could someone look into this when they get a bit of time?
-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
Questions RE Curator third-party licenses
All, In ongoing efforts to close out OODT-3 [1], I have been looking to understand on the third-party licensing involved in the curator subproject. If you check out the rat report attached the the issue [2], you will see that there are a number of unidentified licenses according to RAT, most of which are now documented in the NOTICES file for the project. A rough breakdown of these files/licenses is a follows: JQuery Licensed Files: ./curator/src/main/webapp/js/jquery-1.3.2.js ./curator/src/main/webapp/js/jquery/jquery.js ./curator/src/main/webapp/js/jquery-treeview/lib/jquery.js (1.2.2b2) ./curator/src/main/webapp/js/jquery-ui/jquery-1.3.2.min.js jQuery UI Licensed Files: ./curator/src/main/webapp/js/jquery/ui.core.js ./curator/src/main/webapp/js/jquery-ui/jquery-ui-1.7.2.custom.min.js ./curator/src/main/webapp/js/jquery-ui/jquery-ui-1.7.2.full.min.js jQuery UI CSS Framework Licensed Files: ./curator/src/main/webapp/js/jquery-ui/css/smoothness/jquery-ui-1.7.2.custom.css jQuery Alert Dialogs Plugin Licensed Files: ./curator/src/main/webapp/js/jquery.alerts.js jQuery PeriodicalUpdater Plugin Licensed Files: ./curator/src/main/webapp/js/jquery.periodicalupdater.js jQuery blockUI Plugin Licensed Files: ./curator/src/main/webapp/js/jquery/jquery.blockUI.js jQuery Cookie Plugin Licensed Files: ./curator/src/main/webapp/js/jquery/jquery.cookie.js ./curator/src/main/webapp/js/jquery-treeview/lib/jquery.cookie.js jQuery Treeview Plugin Licensed Files: ./curator/src/main/webapp/js/jquery-treeview/jquery.treeview.js ./curator/src/main/webapp/js/jquery-treeview/jquery.treeview.async.js jQuery Dynamic Tree View Control Licensed Files: ./curator/src/main/webapp/js/src/jquery.dynatree.js ./curator/src/main/webapp/js/src/jquery.dynatree.min.js Additionally, ./curator/src/main/java/org/apache/oodt/cas/curation/util/HTMLEncode.java is jTidy and an issue has already been filed to replace this with Apache Commons code [3]. Finally, I have questions on a number of files which I will enumerate below: 1) ./curator/src/main/webapp/js/jquery-treeview/jquery.treeview.css - Is this something we developed or is it a file that normally comes with the treeview plugin? 2) ./curator/src/main/webapp/js/jquery-treeview/todo and all files in ./curator/src/main/webapp/js/jquery-treeview/demo/* seem to be superflous. Are they just examples that we do not depend on, and if so, will the license allow us to get rid of them? 3) ./curator/src/main/webapp/js/jquery-ui/index.html - looks like an example usage, so the same question are #2. Could one of the curator developers let me know answers to these questions? Thanks for your help! -Dave [1] https://issues.apache.org/jira/browse/OODT-3 [2] https://issues.apache.org/jira/secure/attachment/12450245/oodt966905rat.txt [3] https://issues.apache.org/jira/browse/OODT-18 - 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
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" 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
Re: couple more pom issues
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.mattm...@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
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: One more licensing issue found
From http://www.apache.org/legal/resolved.html: "How should works for which multiple mutually exclusive licenses are available be handled? When including that work's licensing, state which license is being used and include only the license that you have chosen. Prefer Category A to Category B to Category X. You don't need to modify the work itself if, for example, it mentions the various licensing options in the source headers." MIT + GPL seems OK, then, as MIT is cat A, but I am still unclear as to how to "include only the license that you have chosen." -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 22, 2010, at 3:57 PM, David M Woollard wrote: > I hope everyone has not gotten overly sick of these dependency and licensing > questions at this point... > > It seems that jQuery has a dual license... Since one is GPL, does anyone know > what that means? See below: > > /*! > * jQuery JavaScript Library v1.3.2 > * http://jquery.com/ > * > * Copyright (c) 2009 John Resig > * Dual licensed under the MIT and GPL licenses. > * http://docs.jquery.com/License > * > * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009) > * Revision: 6246 > */ > > -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 > > > > >
One more licensing issue found
I hope everyone has not gotten overly sick of these dependency and licensing questions at this point... It seems that jQuery has a dual license... Since one is GPL, does anyone know what that means? See below: /*! * jQuery JavaScript Library v1.3.2 * http://jquery.com/ * * Copyright (c) 2009 John Resig * Dual licensed under the MIT and GPL licenses. * http://docs.jquery.com/License * * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009) * Revision: 6246 */ -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
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: Third party script in the oodt trunk
I have two more for ya: 1) webapp/workflow/src/main/webapp/js/progress/progress.js /* WebAppers Progress Bar, version 0.2 * (c) 2007 Ray Cheung * * WebAppers Progress Bar is freely distributable under the terms of an Creative Commons license. * For details, see the WebAppers web site: http://www.webappers.com/progressBar/ 2) webapp/workflow/src/main/webapp/js/prototype/prototype.js /* Prototype JavaScript framework, version 1.5.0 * (c) 2005-2007 Sam Stephenson * * Prototype is freely distributable under the terms of an MIT-style license. * For details, see the Prototype web site: http://prototype.conio.net/ -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 22, 2010, at 12:56 PM, Mattmann, Chris A (388J) wrote: > Hmm, OK, well Apache projects can't include GPL software, see here [1]. > > Can we covert the CPP Metadata project to use Xerces CPP? > > Cheers, > Chris > > [1] http://www.apache.org/legal/resolved.html > > > On 7/22/10 2:04 PM, "David M Woollard" wrote: > > All, > > Looks like we have another licensing issue. In the metadata subproject, there > is a Cpp library for parsing xml at: > > /metadata/src/main/cpp/util/xml/XMLUtils.h > /metadata/src/main/cpp/util/xml/XMLUtils.cpp > > Seems GNU GPL: > * Copyright (C) 2005 Dell Inc. > * by Michael Brown > * Licensed under the Open Software License version 2.1 > > -Dave > > On Jul 22, 2010, at 10:28 AM, David M Woollard wrote: > >> All, >> >> In the process of wrapping up OODT-3 (Apache license headers), I came across >> the following third-party script that it looks like we swept into the source: >> >> filemgr/src/main/resources/MysqlToOracleFilter.pl >> >> It's a filter to transform mysql ddl into oracle ddl and it looks to have >> been written by Dennis Box (no licensing info is included with the script). >> Since this is just a convenience script for us, should we just get rid of >> it? >> >> -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 >> >> >> >> >> > > > > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.mattm...@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: Third party script in the oodt trunk
Oops... I managed not to paste the whole header. * Copyright (C) 2005 Dell Inc. * by Michael Brown * Licensed under the Open Software License version 2.1 * * Alternatively, you can redistribute it and/or modify * it under the terms of the GNU General Public License as published * by the Free Software Foundation; either version 2 of the License, * or (at your option) any later version. * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * See the GNU General Public License for more details. */ It's the "alternatively" part that concerned me... -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 22, 2010, at 11:20 AM, Sean Kelly wrote: > It looks like OSI OSL to me; see > http://www.opensource.org/licenses/osl-3.0.php > >> Seems GNU GPL: >> * Copyright (C) 2005 Dell Inc. >> * by Michael Brown >> * Licensed under the Open Software License version 2.1 >
Re: Third party script in the oodt trunk
All, Looks like we have another licensing issue. In the metadata subproject, there is a Cpp library for parsing xml at: /metadata/src/main/cpp/util/xml/XMLUtils.h /metadata/src/main/cpp/util/xml/XMLUtils.cpp Seems GNU GPL: * Copyright (C) 2005 Dell Inc. * by Michael Brown * Licensed under the Open Software License version 2.1 -Dave On Jul 22, 2010, at 10:28 AM, David M Woollard wrote: > All, > > In the process of wrapping up OODT-3 (Apache license headers), I came across > the following third-party script that it looks like we swept into the source: > > filemgr/src/main/resources/MysqlToOracleFilter.pl > > It's a filter to transform mysql ddl into oracle ddl and it looks to have > been written by Dennis Box (no licensing info is included with the script). > Since this is just a convenience script for us, should we just get rid of it? > > -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 > > > > >
Third party script in the oodt trunk
All, In the process of wrapping up OODT-3 (Apache license headers), I came across the following third-party script that it looks like we swept into the source: filemgr/src/main/resources/MysqlToOracleFilter.pl It's a filter to transform mysql ddl into oracle ddl and it looks to have been written by Dennis Box (no licensing info is included with the script). Since this is just a convenience script for us, should we just get rid of it? -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
