Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Auto-conf meeting logs"

(→‎August 19 2007)
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
===26 May 2007===
+
The final meeting.
 +
 
 +
===August 19 2007===
 +
The final meeting.
 +
 
 +
<pre>
 +
<onnadi3> Good day, lemmy, rcjsuen
 +
<rcjsuen> onnadi3: Hi
 +
<lemmy> Hi
 +
<lemmy> Do we have an agenda?
 +
<onnadi3> Wwe need to figure out what I should do to round up before the submission date
 +
<onnadi3> Which is tomorrow, I believe
 +
<lemmy> Yep, tomorrow is pencils down
 +
<onnadi3> 1. Upload my code to code.google.com
 +
<onnadi3> 2. Make the changes you guys suggested to the documentation
 +
<onnadi3> No. 3 would be post on my blog about the wonders of Discovery, but you guys haven't commented on the draft I put up
 +
<onnadi3> Should we just skip it?
 +
<lemmy> we should stick to the plan and try to get as much pr as possible.
 +
<onnadi3> okey-doke
 +
<rcjsuen> yup, I agree
 +
<lemmy> and the comment is still on my todo list.
 +
<onnadi3> :-)
 +
<rcjsuen> onnadi3: I left a one sentence comment like 10 minutes ago
 +
<onnadi3> Hmm, perhaps bugzilla was still down, then
 +
<rcjsuen> It was synchronizing this mornign.
 +
<lemmy> 1. Upload my code to code.google.com. Is there anything to arrange for?
 +
<onnadi3> Not really. They just want to see what you've done all summer.
 +
<onnadi3> rcjsuen: I don't see any need to mention SoC. It was just a vehicle for achieving our ends :-)
 +
<benny`work> onnadi3, do you know where to upload the stuff? can't find anything about where to do it
 +
<onnadi3> benny`work: This article explains everything http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2
 +
<benny`work> onnadi3, thanks
 +
<onnadi3> lemmy, rcjsuen: Anything else you'd like me to do before pencils down?
 +
<rcjsuen> Don't think so.
 +
<rcjsuen> maybe generate API docs but I don't know where to host that
 +
<onnadi3> cool
 +
<kynes> pombreda, ping
 +
<onnadi3> Well, I think that's all that's on the agenda
 +
<onnadi3> IS there any need for us to meet tomorrow?
 +
<rcjsuen> I don't think so.
 +
<onnadi3> Alrighty. I'll shoot y'all an e-mail when I've uploaded everything
 +
Aug 19 13:45:58  onnadi3 is sad that it's all over
 +
<rcjsuen> onnadi3: Thank you for all your hard work.
 +
<onnadi3> rcjsuen: Thank *you* for lurking on IRC all the time and answering all questions :-)
 +
<rcjsuen> Just trying to pay back to the Eclipse community ;)
 +
<rcjsuen> onnadi3: I see you approached the occasional straggler also, thanks
 +
<onnadi3> :-)
 +
<onnadi3> Well, I better finish rounding up my SoC. Markus, Remy, I'll talk to you all later
 +
<lemmy> ttyl
 +
</pre>
 +
 
 +
===August 14 ===
 +
Action items
 +
* E-mail Alex Blewitt to see if SoCers can post articles to EclipseZone about their projects
 +
* Write an article on Discovery and post it as many places as possible
 +
* Write documentation for Discovery in docbook format
 +
* Check out how Mac Eclipse does their JRE discovery
 +
 
 +
<pre><onnadi3> I've got meeting items here http://wiki.eclipse.org/Auto-conf_meeting_agenda
 +
<lemmy> ok, lets get started: How to get Discovery into the Eclipse Platform
 +
<lemmy> what do you mean by that?
 +
<onnadi3> Well, I would like my work to be used by other projects
 +
<lemmy> do you mean how to make discovery part of the eclipse sdk?
 +
<onnadi3> Yeah :-)
 +
<onnadi3> Is there a process for it?
 +
<lemmy> that is something we cannot enforce. we rather have to hope for adoption. surely we can promote discovery with blog posts and examples. but at the end of the day, the platform team will decide.
 +
<onnadi3> okay
 +
<onnadi3> That kinna leads into the second item
 +
<lemmy> exactly. ;)
 +
<onnadi3> zx suggested making a screencast
 +
<rcjsuen_> yeah, item 1 really goes down to PR and usability
 +
<lemmy> i've never done a screencast. you're talking something like a flash movie?
 +
<onnadi3> Yeah...
 +
<onnadi3> Perhaps an article would suffice. Can anyone post on Eclipsezone?
 +
<lemmy> at best we would have both. personally I don't like screencasts, i rather like to read normal text.
 +
<onnadi3> Me too
 +
<lemmy> we can ask alex blewit
 +
<lemmy> +t
 +
<lemmy> he is the "editor in chief".
 +
<onnadi3> ah, that guy
 +
<onnadi3> Does he lurk here?
 +
<lemmy> what about http://www.eclipse.org/articles/ ?
 +
<rcjsuen_> Nope, he doesn't.
 +
<onnadi3> Hello Remy :-)
 +
<lemmy> we should write him an email. maybe in the name of all soc projects.
 +
<onnadi3> That'd be great
 +
<onnadi3> I think  Eclipse corner will be easy enough
 +
<onnadi3> Oops. "hat is, articles that contain time-sensitive material or are likely to expire in a relatively short period of time do not belong on Eclipse Corner"
 +
<rcjsuen_> Depends what "short" means.
 +
<onnadi3> True, but isn't beta software the definition of time-sensitive material? :-)
 +
<onnadi3> Doh. We don't need to belabor this point. We can always post on Planet Eclipse. That's got mad readership
 +
<rcjsuen_> yeah
 +
<rcjsuen_> you could just paste some simple code
 +
<rcjsuen_> then include a zip
 +
<rcjsuen_> with the full thing
 +
<rcjsuen_> or whatever
 +
<onnadi3> So I guess, the bottom line is 1) E-mail Blewitt, and 2) post to Planet Eclipse
 +
<lemmy> onnadi3: are you going to write an email to alex? otherwise i can do it too.
 +
<onnadi3> lemmy: Well, if its going to be in the name of all of SoC then you should prob'ly do it. Otherwise I will
 +
<lemmy> onnadi3: i don't think i'm a better suited represent for soc... but ok, i'll write the email.
 +
<onnadi3> Oh, you don't know him personally?
 +
<onnadi3> Sorry, I thought you did
 +
<onnadi3> I can write it, in that case
 +
<lemmy> yeah, simply cc soc-dev
 +
<onnadi3> No problem
 +
<rcjsuen_> Don't think anyone in here really knows him that well.
 +
<lemmy> for agenda item #3 i suggest http://www.eclipse.org/articles/article.php?file=Article-Authoring-With-Eclipse/index.html
 +
<lemmy> although for a basic how to hack the wiki might be fine too.
 +
<onnadi3> Hmm, if DocBook can publish to HTML, then I'll go with it
 +
<lemmy> html, pdf, ...
 +
<onnadi3> good
 +
<lemmy> docbook doesn't contain the layout, just the structure.
 +
<rcjsuen_> DITA also does html / pdf, it can also transform to eclipsehelp, though I'm not familiar with the eclipsehelp bit
 +
<lemmy> for docbook i've done the transformation to html and pdf lately.
 +
<onnadi3> Alrighty. I'll start off with DocBook and switch to DITA if I hit snags
 +
Aug 14 15:27:22 --> jevgeni (n=def@ip50.cab81.tln.starman.ee) has joined #eclipse-soc
 +
<lemmy> he is hard to miss, isn't he? ;o
 +
<lemmy> the British accent is very strong
 +
<lemmy> btw. onnadi3 have you had a look at the mac jre discovery code in 3.4m1?
 +
<rcjsuen_> I didn't even realize there was a 'Search' button.
 +
<rcjsuen_> Maybe it just looks for specific path names
 +
<rcjsuen_> like jre/bin/
 +
<lemmy> rcjsuen_: the search button on the jre page is older. but it isn't a smart search, just recursive.
 +
<rcjsuen_> ic
 +
<onnadi3> From the description, it does exactly what our Discovery does
 +
<onnadi3> Searches a location for JREs
 +
<lemmy> but only on mac osx
 +
Aug 14 15:31:14 --> michaelr (n=no@S010600184d82fd75.cg.shawcable.net) has joined #eclipse-soc
 +
<onnadi3> true :-)
 +
<lemmy> but it is definitely worth to check how they do it.
 +
<onnadi3> okay
 +
<rcjsuen_> I wonder how it works
 +
<rcjsuen_> maybe like if (Platform.getOS().equals(Platform.MAC)) or whatever the actual method/field names are
 +
<-- Pookzilla has quit ()
 +
<onnadi3> Well, that's it for the agenda. I'm still mailing the CDT-dev folks to try and get the Make insertion working
 +
<onnadi3> I tried the instructions they gave, but nothing happened
 +
<rcjsuen_> onnadi3: that's nice
 +
<onnadi3> :-)
 +
<-- jevgeni has quit ("Bye!")
 +
<Ali> could you please send me a link to the sourceforge project for that? I didnt see it on teh wiki (I may have missed it though)
 +
<onnadi3> lemmy, rcjsuen_: When do I have to turn in all the code/docs/etc. in so you guys can evaluate?
 +
<rcjsuen_> Ali: eclipse-incub is the name
 +
<rcjsuen_> so sourceforge.net/projects/eclipse-incub
 +
<lemmy> as early as possible. continuous evaluation. ;)
 +
<rcjsuen_> onnadi3: dunno, let's see
 +
<rcjsuen_> probably next Friday
 +
<rcjsuen_> http://code.google.com/support/bin/answer.py?answer=60325&topic=10729
 +
<onnadi3> Alright, as soon as possible but before Friday, it is :-)
 +
<onnadi3> So our final meeting will be on Monday, the 20th, then?
 +
<lemmy> do we want to have an additional meeting in between?
 +
<Ali> thanks a lot. Is there any information on what is left to be implemented, what features have ben implemented and such?
 +
<onnadi3> lemmy: If we do, I'd rather it be between friday and sunday inclusive. That way I'd have stuff for y'all to comment on
 +
<Ali> I saw a comment at the bottom of the wiki regarding RSE
 +
<Ali> I am glad to see things are moving forward there :-)
 +
<lemmy> onnadi3: so we leave the precise date open but target the weekend?
 +
<onnadi3> Sure thing
 +
<onnadi3> Are there any other items to discuss today?
 +
<lemmy> not from my side
 +
<lemmy> ok, ttytomorrow
 +
<rcjsuen_> bye
 +
<onnadi3> alrighty. Bye :-)
 +
</pre>
 +
    ===August 6 2007===
 +
Markus explained how to use OS-specific fragments.
 +
<pre>
 +
Aug 06 11:35:44 <onnadi3> I still haven't figured out how to incorporate code from OS-specific fragments
 +
Aug 06 11:35:54 <onnadi3> I haven't worked on that bug since I posted it
 +
Aug 06 11:36:04 <onnadi3> ~196660
 +
Aug 06 11:36:42 <lemmy> bugzilla is probably still down
 +
Aug 06 11:37:13 <onnadi3> I can access it just fine. (why didn't KOS-MOS autocomplete?)
 +
Aug 06 11:37:59 <lemmy> bugzilla was down earlier today. maybe KOS-MOS needs a restart?!
 +
Aug 06 11:38:15 <onnadi3> strange
 +
Aug 06 11:39:14 <KOS-MOS> See bug 196660 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=196660
 +
Aug 06 11:39:20 <onnadi3> yay!
 +
Aug 06 11:40:21 <onnadi3> So, have you ever written OS-specific fragments before?
 +
Aug 06 11:40:40 <lemmy> yep
 +
Aug 06 11:41:13 <onnadi3> Could you send me the fragment's manifest or any other code so I can figure out how to do it in Discovery?
 +
Aug 06 11:43:37 <lemmy> onnadi3, swt itself uses fragments.
 +
Aug 06 11:43:46 <lemmy> which are pretty much platform dependent.
 +
Aug 06 11:44:28 <onnadi3> I just can't figure out how to make certain code/classes appear on one OS and not in another
 +
Aug 06 11:44:42 <onnadi3> Perhaps its not too important. We could alway just bundle em all together
 +
Aug 06 11:45:36 <lemmy> we could
 +
Aug 06 11:46:40 <onnadi3> okay
 +
Aug 06 11:46:43 <lemmy> the interfaces of each fragment has to be the same, but the impl might differ. actually i would move the interfaces into the host plug-in and let the fragments implement the interfaces.
 +
Aug 06 11:47:32 <lemmy> making certain classes appear only on a certain os kinda destroys the fragment purpose anyway.
 +
Aug 06 11:47:39 <onnadi3> So, we'd publish a JREFinder-win or JREFinder-osx?
 +
Aug 06 11:47:47 <lemmy> nope
 +
Aug 06 11:48:18 <lemmy> we publish a jrefinder and a jrefinder-win-fragment and a jrefinder-osx-fragment.
 +
Aug 06 11:48:42 <lemmy> a customer deployes all three inside osgi and osgi takes care of loading the right fragment.
 +
Aug 06 11:49:01 <lemmy> osgi checks the platform filter to determine which fragment to load.
 +
Aug 06 11:50:23 <-- moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has left #eclipse-soc
 +
Aug 06 11:50:34 <onnadi3> Hmm, but then we're back at square one because I don't know how to set the OS filter. I've really tried and tried but there seems to be no articles that explain how to do it
 +
Aug 06 11:50:57 <lemmy> swt demonstrates it perfectly. Just extract org.eclipse.swt_3.3.0.vNNNN.jar and org.eclipse.swt.os.ws.arch.NNNN.jar
 +
Aug 06 11:51:26 <lemmy> onnadi3, os filters are explained in the osgi r4 spec. either the compendium or the core.
 +
Aug 06 11:51:37 <onnadi3> oh
 +
Aug 06 11:52:16 <onnadi3> I have the core here. Let me check it again
 +
Aug 06 11:52:17 <lemmy> in our case it is even easier than it is for swt. we don't need to care about arch and ws. we only need to care about os.
 +
Aug 06 11:52:38 <lemmy> (& (osgi.os=linux) (osgi.arch=x86))
 +
Aug 06 11:53:04 <lemmy> it's a ldap style "query".
 +
Aug 06 11:56:00 <onnadi3> Hmm, I found a small section in core about fragments. I think once I look through that and then through the jars (I didn't think of looking there), I'll be able to get this figured out
 +
Aug 06 11:56:44 <lemmy> in our case the platform filter will probably look just like "(osgi.os=linux)" and "(osgi.os=win32)"...
 +
Aug 06 11:58:03 <onnadi3> cool
 +
Aug 06 11:59:58 <onnadi3> Ah, I'm beginning to understand it now. The section on filters is hidden in the "Service Layer" section. That's how come I'd never seen it before
 +
</pre>
 +
 
 +
===July 30 2007===
 
<pre>
 
<pre>
−
<onnadi3> Two things:
+
<lemmy> So what is on our agenda?
−
<lemmy> unfortunately I had no time to send out an agenda.
+
<rcjsuen_> k we're good
−
<onnadi3> 1. Weekly meeting times
+
<rcjsuen_> i 'm outside the lab right now >_>
−
<onnadi3> 2. Agenda for this coming month, or at least the next few weeks
+
<onnadi3> All that was left was to decide what we're to do about CDT i.e. to go ahead and discover whether Make exists on a system or not
−
<onnadi3> 3. Perhaps all get on the same page about hte project's objective
+
<lemmy> the other stuff is already done?
−
<onnadi3> (that's not 3, I know :-) )
+
<onnadi3> Well...I've implemented it and it compiles
−
<rcjsuen> I'm not sure when Philippe will send out an email for weekly meetings.
+
<rcjsuen_> lol
−
<rcjsuen> Since the program starts on Monday is it?
+
<onnadi3> But I'm getting synchronization errors
−
<onnadi3> yup
+
<onnadi3> (I dread Concurrency)
−
<lemmy> About 1. I'll be back in Germany 11th of June which should
+
<rcjsuen_> synchronization?
−
allow us for more flexible meeting times.
+
<rcjsuen_> ah
−
<rcjsuen> I can't do weekday meetings since I have a full-time (internship) job.
+
<onnadi3> I'm working on it. I hope it won't be a big deal
−
<lemmy> I'm rather busy through the week myself and would prefer
+
<onnadi3> So, Markus, do you still think we should go ahead with just finding make on a system?
−
meetings on the weekend too.
+
<lemmy> yes, as it will help us to understand what we can generalize and refactor.
−
<onnadi3> Alright. Should we perhaps stick with this time until we
+
<onnadi3> That's true
−
find a better time?
+
<rcjsuen_> yes
−
<rcjsuen> Saturday mornings are no problem with me.
+
<lemmy> for example the rule set/heuristics should come from a xml file. I don't want to touch code/recompile if I add a new location.
−
<lemmy> Sounds like a plan to me.
+
<onnadi3> Hmm, but the IFinder.refresh() can't be specified declaratively
−
<onnadi3> Alrighty! Next up,  2. Agenda for this coming month,
+
<lemmy> Why not?
−
<lemmy> We definitely need to setup SCM.
+
<onnadi3> Well, for instance in JREFinder, refresh() needs to call Platform and then run a loop in order to pick out the the right VMType to do the testing with
−
<lemmy> onnadi3: Have you started the Eclipse IP process already?
+
<onnadi3> If you're going to have loops, then its no longer really declarative, is it?
−
<onnadi3> I thought, the eclipse-dev folks were going to send out an
+
<lemmy> I don't get why this renders a xml file impossible.
−
e-mail to all of us en masse
+
<onnadi3> Well, it doesn't make it impossible but it doesn't seem to be worth the trouble of avoiding recompilation if we'll end up writing loops and conditionals in XML
−
<lemmy> Lets check the soc bug again...
+
<lemmy> conditional xml? why?
−
<rcjsuen> wizEpit: Hi wizEpit, don't think I've seen you around, are
+
<-- rcjsuen has quit (Read error: 110 (Connection timed out))
−
you a student?
+
<onnadi3> If you can, please look at JREFinder.isJREDirectory(). It makes use of loops and an if-statement
−
<rcjsuen> yeah, It's been a while, I don't really remember the details
+
<lemmy> btw. i'm still missing the jrefinder.ui plug-in
−
<rcjsuen> Can always just use SF for now.
+
<onnadi3> Oh? I committed that
−
<rcjsuen> we all did so last yr anyway ;p
+
<lemmy> I'm talking about JREFinder.find() and the potentialJRELocations getting filled.
−
<lemmy> We should get the process started anyway. Don't you agree that
+
<lemmy> This could be done with a simple/non conditional xml.
−
the code might end up in Eclipse?
+
Jul 30 11:46:39 --> moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has joined #eclipse-soc
−
<onnadi3> Yes yes yes
+
<lemmy> there is no jrefinder.ui plug-in. :o
−
<rcjsuen> I'm not sure which project would consume it though.
+
<onnadi3> Yeah. But what I'm saying is that IFinder also needs a refresh() method which uses relatively complex constructs that would not be suitable for XML. So we have to decide if we really want discovery plugin writers to have to separate their IFinder code into a Java part and an XML part
−
<lemmy> It will be easier if the code is already at eclipse.org i guess.
+
<lemmy> Yes, because the xml changes independently of the refresh and more frequently.
−
<lemmy> Do you have a SF id ogechi?
+
<onnadi3> Hmm...
−
<rcjsuen> lemmy: Right
+
<onnadi3> That's true, too :-)
−
<rcjsuen> I think I added him already
+
<onnadi3> (BTW, I named the ui plugin wrongly and that's why it isn't showing up...yet)
−
<onnadi3> No. But I have a google id and I have used Google's project
+
Jul 30 11:51:52 --> rcjsuen (i=rcjsuen@nat/ibm/x-d827998b15814402) has joined #eclipse-soc
−
hosting before
+
<onnadi3> lemmy: should we enforce the XML rule or  just let plugin writers use XML if they see fit?
−
<onnadi3> Its really easy
+
<lemmy> I don't see a reason to enforce it.
−
<rcjsuen> okay i guess not the n;p
+
<onnadi3> oh OK. So you meant use XML for JREFinder, then?
−
<lemmy> I would prefer to use SF. Eclipse GSoC has a project set up already.
+
Jul 30 11:56:06 --> soulreaper_ (i=soul@p54A66704.dip.t-dialin.net) has joined #eclipse-soc
−
<lemmy> And GSoC doesn't require us to use their facilities.
+
<lemmy> onnadi3, yep
−
<lemmy> http://sourceforge.net/projects/eclipse-incub
+
<lemmy> btw. newer swallow Exceptions.
−
<onnadi3> lemmy: so all the past GSoC projects are held in SF under
+
<lemmy> try { ... } catch(Exception e) { // do nothing } is really bad.
−
one source tree?
+
<lemmy> JREFinder.readLInes()
−
<rcjsuen> not "all"
+
<onnadi3> But the silly BufferedReader throws exceptions when it hits EOF. I couldn't think of another way to test for EOF
−
<rcjsuen> some...didn't ;p
+
<onnadi3> And the API doesn't have an isEndOfFile() method
−
<rcjsuen> http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/
+
<lemmy> What kind of exception does it throw in that case?
−
<rcjsuen> by some i mean lots
+
<-- rcjsuen_ has quit (Read error: 110 (Connection timed out))
−
<onnadi3> :-)
+
<onnadi3> **ahem** an IOException. I'll put that in right away :-)
−
<rcjsuen> I don't know how strict pombreda is going to be this year though ;)
+
<rcjsuen> it shouldn't
−
<rcjsuen> It's just easier for the populace to find GSOC code.
+
<rcjsuen> you're calling reader.readLine()?
−
<rcjsuen> If they're all in one place, naturally.
+
<onnadi3> Yeah
−
<onnadi3> OK. THat makes sense.
+
<rcjsuen> If it's done
−
<onnadi3> So once I get an SF id, I can e-mail rcjsuen to get added to
+
<rcjsuen> it should return null
−
the incub project?
+
<lemmy> onnadi3, the problem with catching Exception is, that it catches all RuntimeException. And somebody might be interested in certain RuntimeExceptions
−
<lemmy> you can email either remy or me.
+
<onnadi3> Ah. Null. I didn't see that...
−
<lemmy> or both of us and see who acts fiirst. ;)
+
<onnadi3> Good call, Markus. Will change it
−
<rcjsuen> We all have admin rights actually.
+
<-- soulreaper has quit (Read error: 110 (Connection timed out))
−
<rcjsuen> You can just speak up here.
+
<onnadi3> Alright. Bottom line: we should get JREFinder to use a an external representation (e.g. XML) for storing the potential JRE locations
−
<rcjsuen> Someone with free time will do it.
+
<onnadi3> lemmy, rcjsuen: I don't think there's anything else left to discuss; Do y'all?
−
<lemmy> What about CVS vs SVN?
+
<rcjsuen> I don't think so off hand.
−
<onnadi3> SVN, unless someones has a strong opposition to it...
+
<onnadi3> okey-dokey. I'll do some more bug hunting and update bugzilla once this undiscovery thing is done, then
−
<rcjsuen> You're supposed to use CVS.
+
−
<rcjsuen> lol
+
−
<onnadi3> oops
+
−
<lemmy> Says pombreda ?
+
−
<rcjsuen> Says pombreda alright.
+
−
<lemmy> Eclipse.org offers SVN, so does SF.
+
−
<onnadi3> I thought so , too
+
−
<rcjsuen> We picked CVS because of the lower barrier of entry.
+
−
<rcjsuen> That was my vote +1 for CVS.
+
−
<rcjsuen> Even though I would gladly -infinity to CVS.
+
−
<lemmy> Barrier for who?
+
−
<rcjsuen> Since I can't stand 1.x version numbers.
+
−
<rcjsuen> lemmy: Fora nyone
+
−
<lemmy> I'm fine with both and with pombreda  opting for CVS lets use CVS then.
+
−
<onnadi3> <sigh> CVS it is, I guess  :-)
+
−
<rcjsuen> Sorry
+
−
<lemmy> rcjsuen: No need to be sorry. CVS is fine for us.
+
−
<onnadi3> Except for creating directories *ahem*
+
−
<onnadi3> :-)
+
−
<lemmy> Who cares if a file history is broken. ;)
+
−
<onnadi3> :-)
+
−
<onnadi3> Well, now that that is settled, should we move into my goals
+
−
for the next meeting?
+
−
<lemmy> sure
+
−
<rcjsuen> sounds good
+
−
<onnadi3> I was thinking I'd draw out different scenarios in which the
+
−
plugin would be used
+
−
<onnadi3> e.g.
+
−
<onnadi3> 1. Let's say you dl the autoconf plugin then download the
+
−
C++ plugin, the autoconf plugin will automatically determine what the
+
−
C++ plugin needs and try to find them
+
−
<lemmy> onnadi3: the autoconf plugin refers to your plugin?
+
−
<onnadi3> Yeah
+
−
<lemmy> do you want the autoconf plugin to know about cdt?
+
−
<rcjsuen> That'd require some identical plug-in ID + version magic
+
−
<onnadi3> Well, I think it would be beneficial, from the user
+
−
standpoint, to have the autoconf plugin keep as large a db as feasible
+
−
of plugins and their requirements
+
−
<lemmy> actually I don't think autoconf should know about it consumers.
+
−
<onnadi3> that way, it looks like magic to the user
+
−
<onnadi3> Of course, we would also want to provide an API for the
+
−
autconf plugin so that newer plugins can make their requirements
+
−
autconfable
+
−
<lemmy> IMO autoconf should only provide the framework to discover
+
−
"services".  consumers then provide autoconf with rules to discover
+
−
actual servies.
+
−
<rcjsuen> It'd be tough to maintain since I'm assuming those plug-ins
+
−
mark a lot of preferences stuff as internal.
+
−
<lemmy> remy: that's why i don't like the idea of shipping discovery
+
−
rules with autoconf
+
−
<lemmy> btw. autoconf is a working title? ;)
+
−
<rcjsuen> I guess
+
−
<onnadi3> Sounds fine to me :)
+
−
<onnadi3> Hmm, of course our main aim won't be collating all the
+
−
requirements for every single plugin, but I think it would be useful
+
−
to allow the capability so that the more common older plugins are
+
−
autoconfable
+
−
<lemmy> sure, provide a few exemplary rules like jdk, gcc, ... but
+
−
nothing specific.
+
−
<lemmy> It's a nice vision to allow for older plug-ins to benefit from
+
−
autoconf though.
+
−
<onnadi3> So, should we go through the other scenarios now or is that
+
−
something I should flesh out more during the week?
+
−
<lemmy> tbh lets try to get a strong and fairly generic framework
+
−
running before we concentrate on creating a big database.
+
−
<rcjsuen> Agreed.
+
−
<onnadi3> Agreed
+
−
<lemmy> A database is something that could live from contributions.
+
−
<rcjsuen> Very true, services / extensions.
+
−
<onnadi3> So another scenario would be when the C++ plugin has already
+
−
been installed and then the autoconf plugin is installed afterwards
+
−
<onnadi3> In that case, the user would have to click a button or
+
−
something to request that the C++ requirements be found
+
−
<onnadi3> I could do sketches of what this would look like during the week
+
−
<rcjsuen> yes, that seems reasonable
+
−
<rcjsuen> like if they installed a new JRE and it's the new JAVA_HOME
+
−
<rcjsuen> could possibly update that or whatever
+
−
<lemmy> It seems if I have a slightly different vision for autoconf. I
+
−
see it more like a fundamental service without a real UI.
+
−
<onnadi3> ah
+
−
<onnadi3> So perhaps we should focus on the service first, and then if
+
−
there's any time left, work on prettifying?
+
−
<rcjsuen> lemmy: You mean someone else will code the UI?
+
−
<lemmy> rcjsuen: I don't see the need for a UI.
+
−
<lemmy> CDT and JDT will use the autoconf facilities to discover their
+
−
dependencies.
+
−
<lemmy> We could provide patches for CDT and JDT.
+
−
<rcjsuen> If there's no UI then the user cannot intervene with the
+
−
autodetection.
+
−
<lemmy> Basically CDT and JDT use OSGi preference service to obtain a
+
−
service by some identifier. autoconf takes care of filling up the
+
−
preference. either at startup or on demand.
+
−
<lemmy> rcjsuen: since we can't be sure of the result of autoconf
+
−
anyway, a user will always have to verify the results.
+
−
<rcjsuen> That's true.
+
−
<lemmy> Something like: A new JAVA project gets created. JDT asks
+
−
preference for JDK, autoconf tries to discover JDK. JDT shows the
+
−
rules to the user in the project creation wizard.
+
−
<rcjsuen> Sounds reasonable.
+
−
<lemmy> One thing is missing in this however.
+
−
<onnadi3> Shouldn't it be: JDT is installed. autoconf discovers JDK.
+
−
JDT then shows the rules to the user during the installation process
+
−
<lemmy> Who provides the discovery rule. I think those should also
+
−
come from JDT.
+
−
<onnadi3> I'd originally thought this could be done by the community
+
−
as well, but I think that raises security concenrs
+
−
<lemmy> Generally speaking a consumer configures autoconf to discover
+
−
a given service id by a given rule.
+
−
<lemmy> onnadi3: About which installation process  are you talking?
+
−
<onnadi3> the plugin "installation" process
+
−
<lemmy> onnadi3: I wouldn't care so much for the installation of JDT
+
−
or CDT. Discovering a certain service is something which is needed
+
−
when a new project gets created...
+
−
<onnadi3> lemmy: But won't the same rule suffice for any other Java
+
−
project (in the case of JDT)?
+
−
<lemmy> I don't get the question, sorry.
+
−
<onnadi3> So if you discovered, say, the JDK while starting one Java
+
−
project. Won't that same JDK suffice for any other Java project that
+
−
you start?
+
−
<lemmy> each project can depend on a different jdk.
+
−
<onnadi3> I see
+
−
<rcjsuen> yeah, there's a workspace setting, but projects can also
+
−
pick their own
+
−
<onnadi3> It just seems to me like it would be annoying to have to
+
−
have to select a JDK for every project since (I'm guessing) most
+
−
times, you'd want to use the same JDK
+
−
<onnadi3> However, you have an excellent point that people mihgt need
+
−
per project settings and so we need to provide that functionality
+
−
<lemmy> onnadi3: normally you manually add several jdks to your
+
−
workspace. each time you create a new project in that workspace, you
+
−
get to choose from that list.
+
−
<rcjsuen> Depends on the projects, PDEs have the Execution Environment concept.
+
−
<lemmy> true
+
−
<lemmy> but it's just another layer on top of jdks.
+
−
* lemmy feels the need for a whiteboard
+
−
<onnadi3> Ah. I think lemmy is right in that the autoconfplugin finds
+
−
all JDKs every time a  new project is started (in case a new one was
+
−
installed since the last autodetect) and then the user has the choice
+
−
of picking a JDK from a list or using the default
+
−
<lemmy> onnadi3: Discovery could either be triggered from the new
+
−
project wizard or in the workspace wide "installed jdks" preference
+
−
page.
+
−
<rcjsuen> yeah
+
−
<rcjsuen> I guess wherever it has some kinda Viewer that calls like
+
−
getInstalledJREs()
+
−
<lemmy> This pretty much applies to CDT, PDT,...
+
−
<rcjsuen> it should do a rediscover
+
−
<lemmy> getInstalledJREs(boolean rediscover) ;)
+
−
<lemmy> discovery might be expensive
+
−
<onnadi3> yup
+
−
<lemmy> Unfortunately I don't see a way around touching JDT/CDT/... code.
+
−
<lemmy> Except maybe with some AOP magic.
+
−
<onnadi3> And, for instance, in the Ruby plugin, you don't have the
+
−
option of choosing runtimes. So if autodiscovery takes even a few
+
−
extra seconds, folk might get pissed off that this autocofn plugin is
+
−
slowin g their  Eclipse
+
−
<lemmy> But I don't think we should go that road. It would rely on
+
−
internal stuff.
+
−
<lemmy> +down
+
−
<rcjsuen> yeah
+
−
<lemmy> Thinking about it... I guess its more like
+
−
getService(DiscoveryRule rule, ServiceID id)
+
−
<lemmy> and getService(ServiceID id)
+
−
<onnadi3> So for now, we stick with the original plan of filling a
+
−
table of services and then slowly converting other plugins to use the
+
−
autoconf API
+
−
<onnadi3> ?
+
−
<lemmy> onnadi3: I guess for the moment converting means providing patches.
+
−
<rcjsuen> heheh
+
−
<lemmy> But why not, that's the usual way anyway.
+
−
<onnadi3> yup. Unless the plugins allow their prefs to be publicly written
+
−
<onnadi3> But I don't know if lossa plugins do that
+
−
<lemmy> We would provide patches for the big players like JDT and CDT.
+
−
Others will write their own patches later.
+
−
<onnadi3> or if its good form anyway
+
−
<onnadi3> okay
+
−
<lemmy> onnadi3: you can't even be sure that plug-ins store their
+
−
prefs with the normal preference API.
+
−
<onnadi3> true that
+
−
<lemmy> Overwriting those "tables" would definitely mean accessing internal API.
+
−
<onnadi3> So it will have to be by patching the plugins themselves
+
−
<onnadi3> Which, hopefully, won't be immensely difficult :-)
+
−
<lemmy> onnadi3: Its tedious work anyway. Just adding a couple of
+
−
buttons and some calls to the autoconf api.
+
−
<onnadi3> Hmm, so maybe for our next meeting, I should make a skeleton
+
−
plugin and define the API?
+
−
<lemmy> I find it far more interesting designing the a generic discovery engine.
+
−
<onnadi3> Or I coul dinstead work on defining rules in DRools to see
+
−
how it works...
+
−
<lemmy> It would start with drools to get a feeling how the external
+
−
API needs to look like.
+
−
<onnadi3> lemmy: do you mean, designing the heuristics that will find
+
−
any binary given an ID or name? (per your previous comment)
+
−
<lemmy> Start with something simple. A list of possible locations for a JDK.
+
−
<onnadi3> Ah OK. So it comes down to:
+
−
<onnadi3> 1. Play with Drools and see how it works
+
−
<zx> the EE concept was moved to JDT remmy, no longer in PDE
+
−
<onnadi3> 2. Write heuristics for finding where the JDK lives ina system
+
−
<rcjsuen> zx: one less thing for you to worry about?
+
−
<lemmy> Familiarize yourself with PDE. Create the initial plug-in. Get
+
−
a working environment. :)
+
−
<rcjsuen> zx: you need to use like 'update classpath' to stop those
+
−
annoying warnings though
+
−
<onnadi3> lemmy: what do you mean by working environment?
+
−
<rcjsuen> get Eclipse setup and all that good stuff
+
−
<lemmy> zx: why not downwards in the direction of OSGi?
+
−
<zx> lemmy, well, EE is in the spec
+
−
<rcjsuen> lemmy: an interesting proposition
+
−
<zx> JDT provides the tooling around EE
+
−
<lemmy> onnadi3: configure your Eclipse for plug-in development...
+
−
<onnadi3> okey-dokey
+
−
<zx> need to start packing for my flight that leaves in 6 hours
+
−
<onnadi3> lemmy, rcjsuen: Whew! I think we got quite a bit hashed out
+
−
today.  Thanks for your great ideas
+
−
<lemmy> If there is a compilable plug-in in the cvs repository next
+
−
Saturday that takes a collection of possible fs locations and returns
+
−
a collection of jdks...
+
−
<onnadi3> lemmy: gotcha :-)
+
−
<lemmy> No need for fancy API or UI yet. JUnit tests do great.
+
−
<rcjsuen> yay unit tests :)
+
−
<lemmy> And it's ok if they fail :)
+
−
<rcjsuen> So true.
+
−
<onnadi3> hahaha I'll make a few fail just for you :-)
+
−
<lemmy> which reminds me. I missed Wayne's test driven webcast.
+
−
<lemmy> Fortunately it's recorded somewhere. :)
+
−
<lemmy> onnadi3: are you fine with it if i send this chat log to the
+
−
soc-dev mailing list, so others get to know what we're up to?
+
−
<onnadi3> I'm all for it. Let 'em know we been working hard ;-)
+
 
</pre>
 
</pre>
  
−
===21 April 2007===
+
===July 28 2007===
 +
*Weekly meetings moved to 11:30am EDT/7:30pm CST
 +
*Designed the interface IFinder that all finders will share. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121 Bug 198121]
  
 
<pre>
 
<pre>
−
*** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc
+
<onnadi3> rcjsuen, lemmy: Should we go ahead and get started?
−
*** Topic is: SOC 2007 @ Eclipse is on! http://code.google.com/soc - Get help with ~help - List of accepted applications: http://code.google.com/soc/eclipse/about.html  - Find information here: http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007 - Be patient and stick around for an answer - Subscribe to the mailinglist https://dev.eclipse.org/mailman/listinfo/soc-dev
+
<lemmy> sure
−
*** Topic set by pombreda [Sun Apr 15 18:10:57 2007]
+
<rcjsuen> yes, let's do that
−
*** onnadi3 faern arhan pombred1 benny`patchslut rcjsuen kynes soulreaper lemmy Pookzilla zx KOS-MOS ijuma
+
<onnadi3> I would like us to go over the outstanding bugs so I can get an idea for fixing them
−
*** Channel created on Sun Nov 26 00:42:43 2006
+
<rcjsuen> before my teammates come in ;p
−
<onnadi3> rcjsuen, lemmy: sorry, people. I'd been waiting in #eclipse_soc ...
+
<onnadi3> 1. Improve configuration of new Discovery Finders
−
<rcjsuen> onnadi3: oh, sorry I was not clear
+
<onnadi3> ~198121
−
<lemmy> Hi Ogehi
+
<KOS-MOS> See bug 198121 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121
−
<lemmy> +c
+
<rcjsuen> query https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPEN
−
<onnadi3> Hello, Markus
+
<rcjsuen> ED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
−
<onnadi3> rcjsuen: nah, its my fault. I've been here before :-)
+
<rcjsuen> or not
−
<onnadi3> What's been happening in SoC, today?
+
<rcjsuen> i see it got mangled
−
<lemmy> do we have a log?
+
<onnadi3> rcjsuen: how'd you get to that page?
−
<onnadi3> Ach, I'm using a web client that doesn't support logging...
+
<rcjsuen> what page
−
<onnadi3> Can you log?
+
<rcjsuen> the query?
−
<lemmy> yep, i'll log our conversations.
+
<onnadi3> yeah
−
<onnadi3> Good. Thanks
+
<rcjsuen> i just constructed one from bugzilla
−
<onnadi3> rcjsuen, lemmy: Shall we get down to business?
+
<onnadi3> could you give me the parameters? I've tried it unsuccessfully before
−
<lemmy> later i'll try to setup logging which redirects to html.
+
<lemmy> why does find() return null? why not make the method abstract?
−
<lemmy> onnadi3: sure :)
+
<rcjsuen> I guess this one is better ;) https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
−
<rcjsuen> Yes, I'm here.
+
<rcjsuen> even tho we see the other bugs but anyway
−
<onnadi3> Excellent!
+
<onnadi3> lemmy: It returns null because I haven't yet implemented it. I should have noted that
−
<lemmy> remy: you got my email with the proposed agenda?
+
<onnadi3> Let me give the sequence of calls to Finder
−
<onnadi3> Yup.
+
<rcjsuen> yeah that's what i figured
−
<rcjsuen> lemmy: yeah
+
<rcjsuen> so i didn't say anything there
−
<onnadi3> Quick question before we start: does Eclipse have a "find in files" function?
+
<onnadi3> a. You construct the Finder
−
<rcjsuen> in my INBOX
+
<onnadi3> b. You call find() whenever you want the service discovered
−
<rcjsuen> too
+
<onnadi3> c. You call unfind() whenever you want the service undiscovered. There is also a separate thread that monitors the found service and calls unfind() at regular intervals
−
<lemmy> ok, wasn't sure if it got caught in the spam filter again. %)
+
<onnadi3> that's it
−
<rcjsuen> onnadi3: if you use the search it'll search all open projects, dunno about specifying specific files
+
<lemmy> "You" is who in the JRE scenario?
−
<rcjsuen> lemmy: wel-, i am sure everyone is busy (except me), let's get started?
+
<onnadi3> "You" is the person subclassing Finder e.g. JREFinder, MakeFinder etc.
−
<onnadi3> rcjsuen: alrighty. Thanks
+
<lemmy> That I don't get
−
<onnadi3> Sure, let's start
+
<lemmy> Let me put it this way, who calls this methods during runtime?
−
<lemmy> do we consider the channel log our meetings minutes?
+
<onnadi3> The JREFinder plugin, for example
−
<onnadi3> Sounds fine
+
<rcjsuen> In its start method?
−
<rcjsuen> fine by me
+
<lemmy> Doesn't the JREFinder implement the Finder?
−
<lemmy> has either of you anything to add to the agenda?
+
<rcjsuen> onnadi3: Query for all discovery bugs https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&component=org.eclipse.soc.discovery query for open ones https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=org.eclipse.soc.discovery
−
<onnadi3> Nope
+
<lemmy> s/implement/extend
−
<rcjsuen> seems ok
+
<rcjsuen> lemmy: you mean who instantiates it and calls find(), right?
−
<rcjsuen> if something comes up i will say something
+
<onnadi3> That is one way. The other would be to expose the Finder class and have it called whenever the user clicks a button. That is how the JREFinder plugin is built right now actually
−
<lemmy> ok, so lets get started with "project documentation".
+
<lemmy> rcjsuen: yep
−
<lemmy> i guess the wiki is a good place to keep general text.
+
<onnadi3> I guess we should use "finder plugin" for the plugin and "JREFinder" for the class. And yes, JREFinder implements Finder
−
<lemmy> but what about diagrams and such, do we wanna use UML? do we need it?
+
<lemmy> So the finder plug-in calls find() on JREFinder and passes the result to the ECF discovery API?
−
<lemmy> Ogechi: are you familiar with UML?
+
<onnadi3> lemmy: Actually, how I described it was that calling find() would automatically pass the result to the ECF Discovery API
−
<rcjsuen> I've never used UML outside of school, so I am fine if we don't use it
+
<onnadi3> rcjsuen: thanks for the links
−
<rcjsuen> and that was for like...one term
+
<rcjsuen> so what exactly is the Collection for?
−
<onnadi3> lemmy: I know of it but haven't used it. It'll be useful if we get're building a boatload of classes
+
<rcjsuen> Or wait the Colection is what's been found or?
−
<onnadi3> lemmy: I think we should start with prose first and get into UML as the need arises
+
<lemmy> so find() passes it to the PluginDiscoveryService ds instance?
−
<lemmy> fine with me, lets try to limit the new things in this project.
+
<onnadi3> rcjsuen: the Collection is not strictly necessary. I thought it would be nice to have a list of what was found
−
<lemmy> s/things/technology
+
<rcjsuen> ah kk
−
<rcjsuen> lemmy: agreed
+
<lemmy> I would separate it into find() and populate().
−
<onnadi3> agreed
+
<lemmy> populate() passes the find() result to ds
−
<lemmy> so for the project we will work with written text.
+
<onnadi3> lemmy: Shouldn't we have instead, find(), populate() and findAndPopulate()?
−
<onnadi3> For documentation, we'll basically need inline comments, and perhaps a "how to hack" document, right?
+
<onnadi3> So that plug-in writers don't have to do populate(Finder.find())
−
<onnadi3> lemmy: yup
+
<rcjsuen> onnadi3: if we go that route i'd prefer a find() and a find(boolean populate) for populating, I don't like findAndPopulate ;p
−
<rcjsuen> yes, the atter is extremey important
+
<lemmy> rcjsuen: this look so c-ish
−
<rcjsuen> there goes my keys again
+
<onnadi3> okey-dokey :-)
−
<lemmy> what do you guys understand under a "how to hack"?
+
<lemmy> looks
−
<rcjsuen> for there to be users, you need to have a good howto guide
+
<rcjsuen> lemmy: funny, beacuse I don't know C at all
−
<rcjsuen> because we are a-- -azy and woud rather not try to figure out how to use a too-
+
<rcjsuen> except hello world
−
<onnadi3> "how-to-hack: A doc describing how a program was built to aid other developers in modifying it later"
+
<rcjsuen> and how to make a struct
−
<onnadi3> rcjsuen: been typing too long? ;-)
+
<rcjsuen> I think that's about it
−
<rcjsuen> onnadi3: maybe, dunno, oh wel-
+
<lemmy> Why have a parameter to change the behavior of a method? make two methods out of it. :)
−
<lemmy> to me this sound a little bit too generic. i'd like to narrow it down, so we all expect the same from it.
+
<onnadi3> But wouldn't it just be simpler to have the one method that find()s, populate()s and returns the found services?
−
<lemmy> i guess this tool isn't targetted on end users, hence an isv might be appropriate.
+
<rcjsuen> lemmy: I'm just applyign the same idea from JFace viewers refresh/update and SWT widgets layout methods
−
<rcjsuen> true
+
<lemmy> rcjsuen: they are pretty c-ish too. ;o
−
<onnadi3> what is an ISV?
+
<rcjsuen> onnadi3: so by that you mean we have a populate() method that's populating _and_ returns the found services, yesA?
−
<rcjsuen> embedded in ec-ipse -ike what p-atform does?
+
<lemmy> Anyway, I still don't get the whole picture...
−
<rcjsuen> something software vendor i think it is
+
<rcjsuen> lemmy: having to call dispose() is pretty C-ish ;)
−
<rcjsuen> independent maybe
+
<onnadi3> rcjsuen: Yeah
−
<onnadi3> For the "how to hack"  what I had in mind was something like the documentation for TeX: sthg. that describes data structures used and mnotivation for it. Is this still, too generic
+
<lemmy> rcjsuen: dispose(*widget) would be c-ish. dispose() is rather c++-ish. .P
−
<onnadi3> not in WEB, of course
+
<onnadi3> rcjsuen: that was a yeah regarding your comment about populating and returning
−
<lemmy> maybe we should divide it. we need documentation for people working with the code base and also for people using the codebase.
+
<rcjsuen> onnadi3: I see.
−
<lemmy> for the latter the typical eclipse documentation for extensionpoints... would probably be the best. for the former i would choose uml. ;p
+
<rcjsuen> true, we're not doing free(this)
−
<onnadi3> lemmy: by, people using the codebase, do you mean end-users?
+
<onnadi3> :-)
−
<lemmy> onnadi3: yep
+
<lemmy> We have the PluginDiscoveryService which acts as the general API for consumers like JREInjector. Consumers get discovery results from the PluginDiscoveryService for a given type.
−
<lemmy> but i suppose such end-users would be developer too.
+
<lemmy> Also we have Finders which report discovery results to PluginDiscoveryService
−
<lemmy> +s
+
<lemmy> reporting results to PluginDiscoveryService is something in the responsibility of the Finders?
−
<onnadi3> Yeah, so the "how to hack" will be targetted to developers, and the end-user docs can ba called the user manual
+
<onnadi3> lemmy: Yes, since there is no one else for them to report to
−
<lemmy> makes sense to me
+
<lemmy> onnadi3: what's with Finders registering themselfs at the PluginDiscoveryService?
−
<onnadi3> (good point about needing separte docs)
+
<lemmy> Then the PluginDiscoveryService would call find() on all registered finders
−
<lemmy> anything to add in regards to doc?
+
<lemmy> registering could be done via OSGi services (but that's just the technical side of it).
−
<rcjsuen> newp
+
<onnadi3> I think its the other way round. The Finder takes a pointer to the PluginDiscoveryService so that it can call registerService()
−
<onnadi3> The user manual will have the usual stuff like "how to install", how to use, how to uninstall etc. while the dev-docs will just describe how to extend the plugin etc.
+
<lemmy> are we talking about registering the finder at the plugindiscoveryservice?
−
<lemmy> since the code will be bundled as plug-ins, we won't need a install/uninstall doc. this is descibed in the osgi/eclipse documentation.
+
<lemmy> that is the basic necessity, if plugindiscoveryservice should be responsible for calling find()...
−
<lemmy> onnadi3: is this your first eclipse plug-in you write?
+
<onnadi3> The reason why we can't have PDS calling find() on all Finders is because you never know when someone will want a service found e.g. in the case of having a GUI button that starts the finding process
−
<onnadi3> ahem...yeah
+
<lemmy> onnadi3: true, but it means also that we cannot issue a global find() on all finders.
−
<onnadi3> :-)
+
<lemmy> question is, what is the main use case.
−
<lemmy> no problem :)
+
<lemmy> PluginDiscoveryService might offer discover() and discover(IServiceType)
−
<rcjsuen> no worries, a lot of ppl last year never wrote a plug-in
+
<onnadi3> what does discover() do? Call find() on all Finders?
−
<lemmy> onnadi3: do you have eclipse open atm?
+
<lemmy> while the first is for issuing a general find() on all finders independent of the type, the latter is for calling find() on specific finders.
−
<onnadi3> I'm opening it right now
+
Jul 28 10:06:01 --> sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
−
<lemmy> ok, i'll grab a new cup of coffee.
+
<rcjsuen> I like that.
−
<rcjsuen> That means he hasnt gone over to the dark side yet.
+
<onnadi3> Doesn't that make what we did with JREFinder impossible then? i.e. have a GUI that initiates the find process. I'm not saying that JREFinder is the best model for structuring finders...
−
<onnadi3> oh boy... :-)
+
Jul 28 10:07:09 --> kreismeister (n=Miranda@eclipse/developer/Eclipse/Kreismeister) has joined #eclipse-soc
−
<lemmy> with the dark side being?
+
<lemmy> onnadi3: The gui would be finder independent.
−
<onnadi3> BTW, (while eclipse loads) are we going to hashout all the details of what will be in the docs, or just the general plan?
+
<onnadi3> Ah yes
−
<rcjsuen> if you have eclipse open all the time even when you don't really need it
+
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
−
<onnadi3> (Eclipse is up!)
+
<rcjsuen> mmm yes
−
<lemmy> for me the general plan is enough atm.
+
<lemmy> If there is no Finder for the given IServiceType registered, nothing would happen.
−
<onnadi3> okey-dokey
+
<lemmy> onnadi3: calling the specific finder directly also has the disadvantage, that you cannot easily have different finders for the same type.
−
<rcjsuen> as the project (and its scope) is defined (and refined), the details will hash themselves out I think
+
<lemmy> imagine a RegistryJREFinder and a FilesystemJREFinder.
−
<lemmy> i just want to make sure, we agree on the same thing. :)
+
<onnadi3> lemmy: jolly good point
−
<onnadi3> rcjsuen: glad to see the fire of your Eclipse youth is not out ;)
+
<lemmy> They both discovery the same IServiceType "JRE"
−
<onnadi3> lemmy: alrighty
+
<lemmy> Finder would then only implement IDiscoveryResult find() and unfind(IDiscoveryResult) maybe renamed to refresh(IDiscoveryResult)
−
<lemmy> onnadi3: if you open the help system, the "JDT plug-in developer guide" might be a good example of what i think would be good end-user doc.
+
<lemmy> But this would leave PluginDiscoveryService responsible for keeping and updating IDiscoveryResults for undiscovery.
−
<lemmy> certainly not that big though
+
<lemmy> I'm not sure if this is a big disadvantage.
−
<onnadi3> Ah. I see and understand
+
<onnadi3> It can always delegate to the Finders, can't it?
−
<onnadi3> That's some pretty documentation
+
<lemmy> All this matches stuff could be handled inside the Finder
−
<rcjsuen> imo one of the first things that should be done in the documentation phase is properly bui-ding a source plug-in + embedded docs as above
+
<lemmy> onnadi3: PluginDiscoveryService will delegate the unfind/refresh of the IDiscvoeryResult to the Finder, but it needs to keep track of IDiscoveryResults.
−
<lemmy> btw. suppose we're all happy with the outcome of the project at the end of summer, could you imagine to continue working on the project?
+
<onnadi3> I believe it already does that
−
<onnadi3> "source plugin"?
+
<lemmy> perfect :)
−
<rcjsuen> onnadi3: something that includes the java source code of the binary jar that you distribute
+
<onnadi3> If we have Finders registering with PluginDiscoveryService through extension points, how will (for instance) the GUI be able to initiate a find()?
−
<rcjsuen> lemmy: yes good question
+
<rcjsuen> isn't that the discovery(IServiceType.JRE) thing?
−
<onnadi3> Hell yeah, I'd continue. This is my first shot at real fame und fortune :)
+
<lemmy> The GUI will need to get the PluginDiscoveryService instance and call discover() on it.
−
<rcjsuen> onnadi3: many students from the previous year, if you wi-- move on as we--, that is not an issue
+
<lemmy> rcjsuen: exactly
−
<lemmy> onnadi3: the question aims at the "internal" documentation. if you're still around to answer questions, we don't need a thoroughly doc.
+
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
−
<lemmy> though it is desirable.
+
<lemmy> Getting the PluginDiscoveryService reference in the GUI can be done via OSGi.
−
<onnadi3> Very desirable. You never know when I might get run over by a bus
+
<-- sonnyblack has quit (Read error: 110 (Connection timed out))
−
<lemmy> lets hope not at all. ;o
+
Jul 28 10:21:18 * sonnyblack_ is now known as sonnyblack
−
<onnadi3> So I think we're good for the user docs. For the dev docs, are y'all fine with something like the TeX docs?
+
<onnadi3> Aaaaah
−
<lemmy> you mean something written in tex? i must confess, i don't know the tex documentation.
+
<onnadi3> I see
−
<onnadi3> Oh no no. I mean, the documentation of TeX
+
<onnadi3> rcjsuen: Could you please tell us the method names you would have preferred for the Finder class?
−
<lemmy> s/must/have to
+
<rcjsuen> isMatch -> matches
−
<onnadi3> http://tex.loria.fr/tex-source/tex-source.html
+
<lemmy> I've just submitted a IFinder proposal as a bug comment
−
<onnadi3> You'll need a dvi previewer to view it
+
<rcjsuen> dunno about initPotentialMatches(), unfind is pretty weird but dunno if there are better options
−
<onnadi3> Basically, I'm just thinking of documentation as detailed as that so that someone can easily understand the source
+
<rcjsuen> lemmy: to 198121?
−
<rcjsuen> if you can go a-- out, that wou-d be great
+
<lemmy> yep
−
<lemmy> i like detailed. ;)
+
<onnadi3> lemmy: what is the boolean in refresh() supposed to be?
−
<onnadi3> Deal
+
<rcjsuen> now bugzila worked
−
<onnadi3> So that'll be all the documentation we need for this project right? Are we ready to move on to the next poin in the agenda?
+
<lemmy> onnadi3: pretty much what unfind() did.
−
<lemmy> what i usually miss the most in terms of project documentation, is the big picture and the major design.
+
<rcjsuen> Eh?
−
<rcjsuen> onnadi3: i think so
+
<onnadi3> Sorry, I meant what is the return value of refresh()?
−
<lemmy> i don't need a class that contains more javadoc than code.
+
<lemmy> but IFinder is stateless. I doesn't keep track which IDiscoveryResults have been found before.
−
<lemmy> yep, enough for the documentation. ;)
+
<lemmy> boolean
−
<lemmy> s/for the/with
+
<lemmy> valid
−
<lemmy> the next topic i'd like to see going into the project doc. ;)
+
<lemmy> is the given IDiscoveryResult still valid or not
−
<lemmy> "Define some terms/Narrow down or extend the scope"
+
<rcjsuen> hm
−
<lemmy> i think we should try to come up with a clear understanding of what a service can and cannot be.
+
<rcjsuen> validate(IDR) maybe? ;p
−
<lemmy> this will most certainly influence the scope of the project.
+
<rcjsuen> that's kinda like refresh
−
<lemmy> i could imagine using the wiki page (where i already created a section for it) ;)
+
<rcjsuen> we're validating it again
−
<lemmy> what is a service? what identifies a service...
+
<rcjsuen> or maybe not
−
<lemmy> is the term service even approriate...
+
<lemmy> true :)
−
<rcjsuen> maybe not
+
<rcjsuen> maybe validate implies a shortop
−
<lemmy> the current use cases lead to something that i won't really call a service.
+
<rcjsuen> whereas refresh is a longop?
−
<onnadi3> Well, a service can be anything that can be identified with URI...but for this Summer, my goal was only to write finders for services on the local machine
+
<rcjsuen> hm
−
<rcjsuen> lemmy: you want jdk autodetection, i don't think one woud really call a java runtime a esrvice
+
Jul 28 10:29:45 * rcjsuen rubs his chin.
−
<rcjsuen> service is something i shou-d be ab-e to restart through /etc/init.d
+
<-- kreismeister has quit (Read error: 104 (Connection reset by peer))
−
<rcjsuen> and whatever that thing in Win32 is
+
<onnadi3> Shouldn't we also have a method that refreshes all the previously found IDiscoveryResults?
−
<lemmy> rcjsuen: or via the osgi console ;)
+
<rcjsuen> like a validateAll()?
−
<lemmy> maybe we should do the use cases before we define the term?
+
<onnadi3> Yeah
−
<onnadi3> lemmy: perhaps. May we start with some from the proposal?
+
<rcjsuen> hm
−
<lemmy> sure :)
+
<lemmy> onnadi3: IFinder.refreshAll()?
−
<rcjsuen> markus: good idea
+
<onnadi3> And it could return a Collection of still valid IDRs
−
<onnadi3> BTW, rcjsuen, do you have access to a copy of the proposal?
+
<lemmy> but this implies that IFinder knows about previously discovered IDiscoveryResults.
−
<lemmy> should this be our homework assignment to write down the use cases on the wiki page? we could even ask other people to add theirs.
+
<rcjsuen> Maybe take a Collection and pass back a Collection of valid ones?
−
<rcjsuen> markus: yes
+
<onnadi3> Oh!!! I see your point, Markus. PDS is already keeping track of IDRs
−
<onnadi3> Well, one case is like lemmy said, JDK, or gcc, or PERL detection
+
<lemmy> well, this is just convenient API then.boolean validate(IDiscoveryResult) is the minimum.
−
<rcjsuen> lemmy: you need to change your name to start with a key that i dont -ose ha-fway
+
<lemmy> Well, one problem arises with IFinder not keeping track of IDiscoveryResults. PDS needs to know by which specific IFinder instance the IDiscoveryResult has been found earlier.
−
<onnadi3> :-)
+
<lemmy> The RegistryJREFinder probably cannot verify an IDR discovered by the FilesystemJREFinder
−
<lemmy> rcjsuen: maybe you should get yourself a new keyboard instead. ;)
+
<onnadi3> Akk! This means that PluginDiscoveryService will have to handle polling when it comes to undiscovery
−
<rcjsuen> it sounds -ike we are detecting binaries
+
<lemmy> The IDS instance could store the IFinder by which is has been found.
−
<rcjsuen> nuh-uh! :(
+
<lemmy> polling? PDS certainly is responsible for refreshing IDS and hence needs to ask the various IFinders regularly.
−
<onnadi3> Well, the logic for detecting binaries is exactly the same needed to find a Webserver on port 80
+
<lemmy> Btw validate sounds more like verification of an IDS. I tend to refresh
−
<onnadi3> (well, kinna the same)
+
Jul 28 10:37:39 --> kreismeister (n=Miranda@p57AB7FBA.dip.t-dialin.net) has joined #eclipse-soc
−
<lemmy> onnadi3: lets collect use cases until the next meeting. then we choose some of them which make the most sense and compile the deliverables out of it?
+
<lemmy> verification in terms of "is this IDS really a Sun JRE 1.4"...
−
<onnadi3> lemmy: Could you please point me to the page you created?
+
<onnadi3> lemmy: what is IDS?
−
<lemmy> until then i think we should postpone the remaining technical agenda items.
+
<rcjsuen> I'm fine with refresh
−
<lemmy> http://wiki.eclipse.org/index.php/An_auto-configuration_plugin_for_Eclipse
+
<lemmy> s/IDS/IDR
−
<onnadi3> Alrighty! So, on to the organizational items, eh?
+
<onnadi3> okey-dokey. So i guesswe're pretty much done with this bug, apart from naming?
−
<lemmy> rcjsuen: btw. i'll ask phillipe to grant you mentor rights in code.google.com.
+
<rcjsuen> yeah
−
<lemmy> onnadi3: unless you have something technical to add. :)
+
<onnadi3> Bug no.2: Decide on the CDT tools to provide discovery for
−
<onnadi3> lemmy: BTW, thanks for putting that page up
+
<lemmy> I got a question, ca we move our meeting permanently to monday afternoon ~17:30pm?
−
<onnadi3> lemmy: nope, I'm ready to get orgnanized :)
+
<onnadi3> Sure, if it works with Remy
−
<lemmy> nah, don't mention it. that's what i'm here for.
+
<rcjsuen> What time is that
−
<lemmy> ok, "weekly status meetings".
+
<lemmy> 11:30
−
<lemmy> however, normally i prefer daily standup meetings, but this seems to be a problem timezone-wise.
+
<rcjsuen> ooo, that collides directly with my weekly meeting
−
<lemmy> at least for me. you two live in the same tz.
+
<rcjsuen> Although that meeting isn't that important
−
<onnadi3> oh we do?
+
<rcjsuen> cuz we can bring our notebooks
−
<onnadi3> rcjsuen: where are you?
+
<rcjsuen> it's an informal status update
−
<onnadi3> *where do you live?
+
<rcjsuen> I think it's fine
−
<rcjsuen> onnadi3: canada
+
<lemmy> perfect, so next meeting is 07/30 11:30am EDT
−
<onnadi3> excellent
+
<onnadi3> ALrighty
−
<lemmy> onnadi3: and he's normally on irc 24/7 ;)
+
<rcjsuen> ok
−
<onnadi3> hehehe
+
<onnadi3> So,  Bug no.2: Decide on the CDT tools to provide discovery for
−
<onnadi3> I think we should have one weekly meeting, any weekday except Friday
+
<onnadi3> ~197885
−
<lemmy> for the moment i'd suggest to use this timeslot for our weekly meetings?!
+
<KOS-MOS> See bug 197885 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=197885
−
<onnadi3> ahh...
+
<onnadi3> (I like doing that :-))
−
<lemmy> is it too early=
+
<onnadi3> Shall we be sticking with CDT?
−
<lemmy> ?
+
<lemmy> I'm still +1 for CDT even if it means we only do discovery of make
−
<rcjsuen> ten am is fine with me
+
<rcjsuen> yeah
−
<onnadi3> Could we push it back an hour or so. This waking up on a Saturday thing...  :-D
+
<rcjsuen> i never see people complain about setting up pdt
−
<rcjsuen> considering i wake up before seven sometimes
+
<rcjsuen> (well install is hard)
−
<rcjsuen> yes, i just said i wake up before seven sometimes
+
<onnadi3> So, we need to test if make is in the PATH, and if it is not, find where it is installed on the system
−
<onnadi3> Even in the summer??
+
<lemmy> well, we wan't to discover all installations ofmake and not just the one in make.
−
<rcjsuen> yes
+
<lemmy> s/make/path
−
<rcjsuen> rather, even on the weekends
+
<onnadi3> The thing is the CDT interface doesn't really have a drop-down list like JDT does
−
<onnadi3> <cringes> you're strong :)
+
<onnadi3> All it has is a text box where you can enter the name of the make command you want to use
−
<lemmy> maybe we can move it to sunday then?
+
<lemmy> postponed until Monday? The other bug will keep you busy anyway, right?
−
<rcjsuen> sunday is sti-- a weekend ;p
+
Jul 28 10:57:21 --> sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
−
<lemmy> the nightclubs in india close around 1:30
+
<onnadi3> sure :-)
−
<onnadi3> hahahahahhaa
+
<onnadi3> Sweet meeting y'all
−
<lemmy> then i'm fine with 11:00am EST/8:30pm IST.
+
<onnadi3> See ya soon
−
<onnadi3> Alright. Saturdays, 11am EST/8:30pm IST starting from May 28?
+
−
<lemmy> Sundays, 11am EST/8:30pm IST
+
−
<rcjsuen> we are actua--y EDT, but okay ;p
+
−
<rcjsuen> if we are fo--owing -ast yr-s schedu-e
+
−
<onnadi3> Hmm, could we move it back to Saturday? 11am is kinna smack in the middle of church time
+
−
<onnadi3> on Sundays, that is
+
−
<rcjsuen> probab-y a week-y soc meeting on thursdays
+
−
<onnadi3> rcjsuen: I second that
+
−
<lemmy> rcjsuen: which time?
+
−
<rcjsuen> lemmy: last year the whole group met on 1200 EDT and, er
+
−
<rcjsuen> twenty-one hundred?
+
−
<lemmy> yep
+
−
<rcjsuen> Two meetings are held every Thursday:
+
−
<rcjsuen>    1. 0900 PDT - 1200 EDT - 1600 UTC
+
−
<rcjsuen>   2. 1600 PDT - 1900 EDT - 2300 UTC
+
−
<rcjsuen> newp, nineteen hundred
+
−
<rcjsuen> we had two to compensate time zone things
+
−
<rcjsuen> (and commitments, of course, work/school/wahtever)
+
−
<rcjsuen> dunno what is philippe's plan this yr
+
−
<rcjsuen> hello my L key!
+
−
<rcjsuen> oh nm its dead again ;(
+
−
<onnadi3> aww
+
−
<onnadi3> The Ls were nice :)
+
−
<lemmy> I won't make 2300 utc for sure.
+
−
<lemmy> 1600 will be hard too, considering that the day starts early in india. but i guess i don't have an option.
+
−
<onnadi3> So, we'll be meeting on Thursdays and Saturdays, eh?
+
−
<lemmy> rcjsuen: how long do those meetings usually last?
+
−
* rcjsuen coughs.
+
−
<rcjsuen> er, we--
+
−
<rcjsuen> we have doub-e the students this round ;p
+
−
<rcjsuen> sometimes they go over an hr
+
−
<lemmy> onnadi3: for saturday 10:30am EDT/8:00pm IST as a compromise? ;o
+
−
<rcjsuen> anyway, this is un-ike-y to be set in stone
+
−
<rcjsuen> since pom wou-d want to get a fee- for what students agree on this yr
+
−
<onnadi3> lemmy: sure. (their clubs must be *really* good ;) )
+
−
<lemmy> onnadi3: it's better than being home alone. ;)
+
−
<rcjsuen> lemmy: i'm home alone all the time
+
−
<lemmy> rcjsuen: you're still young.
+
−
<onnadi3> hahahahha
+
−
* lemmy doesn't want to die alone. ;)
+
−
<lemmy> so, saturdays 10:30am EDT/8:00pm IST it is?
+
−
<rcjsuen> fine by me
+
−
<onnadi3> fine by me
+
−
<onnadi3> And this is starting from May 28?
+
−
<lemmy> i don't mind if you have your breakfast while typing. ;)
+
−
<lemmy> onnadi3: that depends on you. if it were for me, we could start right away.
+
−
<onnadi3> lemmy: I'd love to start too but I'll be out of town three out of the coming four Saturdays
+
−
<lemmy> just the saturdays or the whole week?
+
−
<onnadi3> Just the weekends
+
−
<onnadi3> So, I *could* work and send you updates by e-mail or whenever I catch you on IRC
+
−
<rcjsuen> either would work
+
−
<lemmy> rcjsuen: i suppose we won't start with the regular thursday meetings before the official gsoc beginning?
+
−
<rcjsuen> un-ike-y
+
−
<rcjsuen> the fact that not many ppl are here means something ;)
+
−
<onnadi3> Cool, so I guess that's meeting schedules done with
+
−
<onnadi3> Next up: deliverables?
+
−
<lemmy> lets postpone it. currently everything is too vague to actually write it down.
+
−
<rcjsuen> yes
+
−
<lemmy> also for the milestones/road map
+
−
<rcjsuen> yeep
+
−
<onnadi3> On the topic of project housing, does Eclipse still use CVS for legacy reasons?
+
−
<lemmy> eclipse.org offers svn as well as cvs.
+
−
<rcjsuen> cvs works so we stick with cvs i spose
+
−
<lemmy> onnadi3: you're familiar with svn?
+
−
<onnadi3> Yup...and I love it
+
−
<onnadi3> So, if we could use it instead of cvs... ;)
+
−
<lemmy> I'm fine with svn too. If it is technically possible, we should you is. But first we need to talk about the license you want to choose for the code.
+
−
<lemmy> this is important if we can or cannot use eclipse.org
+
−
<lemmy> onnadi3: do you have a license model in mind?
+
−
<rcjsuen> There is also the issue of 3rd party libs
+
−
<rcjsuen> to factor into the equation, if any
+
−
<onnadi3> um...I'm a big fan of "Do as you damned well please, just don't give it the same name as mine"
+
−
<lemmy> rcjsuen: maybe you like to elaborate on this topic?
+
−
<onnadi3> Is there a license for that?
+
−
<rcjsuen> we--, licenses ilke those would probably be compatible with the ep
+
−
<rcjsuen> epl
+
−
<rcjsuen> onnadi3: for these super-lax licenses, you probaby want to -ook at mit or bsd
+
−
<rcjsuen> http://www.opensource.org/osi3.0/licenses/bsd-license.php and http://www.opensource.org/osi3.0/licenses/mit-license.php
+
−
<onnadi3> And those could still be added to the Eclipse source??
+
−
<lemmy> onnadi3: if we want to see the code included in eclipse someday, the easiest would be to choose epl.
+
−
<lemmy> but there is also the possibility of cross-licensing
+
−
<rcjsuen> they can be committed to cvs but afaik, no one _works_ on the code that is under a different license at eclipse.org
+
−
<rcjsuen> like we distribute ant with eclipse, but of course, ant development is done by Apache
+
−
<onnadi3> ah. Then I probably want EPL.
+
−
<rcjsuen> yes, dual-tri-multi-licensing schemes work too, as lemmy points out
+
−
<rcjsuen> last yr i dual-ed mine
+
−
<onnadi3> what licenses didja use?
+
−
<rcjsuen> but when it came time to throw it on eclipse, i just removed the dual references
+
−
<rcjsuen> i used MIT/X11 with EPL
+
−
<rcjsuen> but yes, the easiest way out is to pick epl
+
−
<lemmy> just keep in mind that epl and gpl are incompatible.
+
−
<lemmy> it won't be possible to use gpl 3rd party libraries.
+
−
<onnadi3> alrighty
+
−
<lemmy> for drools i've checked already and it's apache license.
+
−
<lemmy> just in case we'll use it.
+
−
<onnadi3> lemmy: what is in the apache license?
+
−
<onnadi3> (and where did you pick up "for drools"? ;) )
+
−
<lemmy> http://www.apache.org/licenses/LICENSE-2.0.html
+
−
<onnadi3> Sorry, I meant what were you referring to when  you said "I've checked"?
+
−
<lemmy> drools is a rules engine which might get useful.
+
−
<lemmy> maybe it's overkill though
+
−
<onnadi3> oh...ah...I thought you were using it as a turn of phrase :)
+
−
<lemmy> hehe, no.
+
−
<onnadi3> Alright, so I guess its sorted for now: Eclipse license...unless we really need a library with a different license
+
−
<lemmy> personally i think epl makes sense since i see this code going into eclipse at some point.
+
−
<rcjsuen> yes, I think some of the projects will find it handy
+
−
<onnadi3> here here
+
−
<lemmy> if we agree on epl, we should get the paperwork rolling. i'll probably take a couple of weeks to get it done.
+
−
<onnadi3> Paperwork?? What do we need to do?
+
−
<rcjsuen> lemmy: paperwork for
+
−
<rcjsuen> ?
+
−
<lemmy> new committer?
+
−
<rcjsuen> lemmy: well, i guess ask pombred1/wayne to get the ball rolling
+
−
<lemmy> rcjsuen: i don't think philippe plans to do it in a batch.
+
−
<lemmy> http://www.eclipse.org/projects/dev_process/new-committer.php
+
−
<rcjsuen> we--, i did not mean -iterally
+
−
<ijuma> conan is the person to ask about drools btw
+
−
<ijuma> he's in #eclipse
+
−
<rcjsuen> batch per se in a way cuz we need to hand in the names when we recreate soc component
+
−
<ijuma> (if there are questions that is)
+
−
<lemmy> ijuma: great, good to know somebody personally. :-)
+
−
<ijuma> it's Mark Proctor btw
+
−
<ijuma> the lead developer
+
−
<lemmy> perfect
+
−
<onnadi3> Does new committer have anythign to do with the license we choose?
+
−
<ijuma> lemmy: yeah, irc is cool :)
+
−
<lemmy> _if_ ogechi chooses to use a rule engine after all. ;)
+
−
<ijuma> well, irc is still cool anyway ;)
+
−
<lemmy> onnadi3: indirectly...
+
−
<rcjsuen> It has to do with
+
−
<rcjsuen> "DO NOT commit non-EPLed code"
+
−
<rcjsuen> :P
+
−
<lemmy> onnadi3: to get a developer account at eclipse.org, you need to go through this new committer process.
+
−
<onnadi3> Ah, I got it
+
−
<lemmy> using eclipse.org infrastructre makes only sense if you choose epl as a license.
+
−
<onnadi3> lemmy: Don't I have to "prove my mettle" by at least writing some code first? That way it'll feel more special :)
+
−
<lemmy> onnadi3: "normally" it is like that. you need to gain "meritocracy points" to be elected as a committer.
+
−
<lemmy> but for soc it is different.
+
−
<lemmy> this bug might make things clearer https://bugs.eclipse.org/bugs/show_bug.cgi?id=143583
+
−
<lemmy> rcjsuen: correct me if i'm wrong, you know far more about this.
+
−
<onnadi3> It does clear things up
+
−
<lemmy> in #eclipse we have our first use case i suppose. ;)
+
−
<onnadi3> in that case, I guess we've covered all possible ground today
+
−
<lemmy> and it only took use 1,5h. ;)
+
−
<rcjsuen> har
+
−
<rcjsuen> but yes, the idea wou-d have been
+
−
<onnadi3> We should probably try to meet up again to clear up the biz about deliverables etc.
+
−
<rcjsuen> keep contributing till you drop
+
−
<rcjsuen> but since it is a "new project
+
−
<rcjsuen> new project has an initial set of committers
+
−
<rcjsuen> so you guys will all be a subset of that set
+
−
<rcjsuen> the other subset would be the mentors
+
−
<lemmy> to wrap things up a litte...
+
−
<lemmy> we'll have two different docs. end-user doc in the eclipse isv format and the internal doc like the tex doc
+
−
<lemmy> until next week we'll write down use cases in the wiki
+
−
<lemmy> the next irc status meeting will be on may 28
+
−
<lemmy> project will be licensed under epl
+
−
<rcjsuen> kk
+
−
<lemmy> regular status meetings will be on saturdays 10:30am EDT/8:00pm IST
+
−
<onnadi3> So, I guess the conversation will continue asynchronously over the wiki...on the issue of use cases
+
−
<lemmy> also we'll have general soc status meetings for which the final timing is still TBA
+
−
<rcjsuen> yes
+
−
<onnadi3> Sounds like a plan y'all
+
−
<lemmy> onnadi3: you can add the wiki page to your watchlist. that way you'll receive emails once somebody modifies the page.
+
−
<rcjsuen> wow that is friggin annoying
+
−
<lemmy> one last thing. onnadi3 do you have a blog?
+
−
<onnadi3> I don't have a blog
+
−
<onnadi3> I thought the wiki was meant for updates on the status of the project etc.?
+
−
<lemmy> idea is to create a blog for the three of us which we use to blog about the project. (eclipse has a vibrant blogging scene)
+
−
<lemmy> http://planet.eclipse.org
+
−
<onnadi3> Can't that be on the wiki page? It would fit nicely there
+
−
<lemmy> it don't think it is technically possible to add a wiki page to the planet.
+
−
<lemmy> also we'd not use it for technical discussion, much rather for PR instead.
+
−
<lemmy> +but
+
−
<lemmy> it's just an idea though. i don't wanna talk you into it.l
+
−
<onnadi3> I'll see about that. I would like to put up general thoughts about the state of the project and all
+
−
<lemmy> in general feel free to stop me/us if we rush things. :)
+
−
<rcjsuen> :)
+
−
<onnadi3> No problem. Things are sauntering by for now so I think I can handle it :)
+
−
<lemmy> if you don't feel comfortable with something, just raise you voice.
+
−
<onnadi3> NO PROBLEM
+
−
<onnadi3> ;)
+
−
<rcjsuen> He probably has a problem with my l key problem.
+
−
<rcjsuen> Why speak of the devil here it is back online
+
−
<rcjsuen> maybe for more than thirty seconds this time
+
−
<lemmy> i think this is the most important point of this meeting. we mentors are meant to support you. we're not your boss.
+
−
<onnadi3> That's good to know. Remy, Markus, thanks a lot for all your help
+
−
<onnadi3> BTW, Remy, are you a he or a she?
+
−
<onnadi3> (if you don't mind)
+
−
<rcjsuen> np, -ooking forward to working with you in the coming months/weeks
+
−
<lemmy> although we have a say in terms of payment. ;p
+
−
<rcjsuen> I am a male. You can even get my mug shot here http://www.eclipsecon.org/2007/index.php?page=sub/&id=3829
+
−
<lemmy> wait a sec, let me find the brain pic...
+
−
<rcjsuen> Markus and I go waaaaaaaaay back....to IRC ;P
+
−
<lemmy> ah next time, it's stored on the usb drive.
+
−
<onnadi3> :-)
+
−
<onnadi3> Alright y'all...I think I shall mosey of now. I've got to please my current employer :) But I'll put up use cases as soon as I get em
+
−
<rcjsuen> onnadi3: np, see you around
+
−
<lemmy> have a nice day/weekend
+
−
<onnadi3> bye bye
+
 
</pre>
 
</pre>

Latest revision as of 19:37, 22 August 2007

The final meeting.

August 19 2007

The final meeting. 

<onnadi3>	Good day, lemmy, rcjsuen
<rcjsuen>	onnadi3: Hi
<lemmy>	Hi
<lemmy>	Do we have an agenda?
<onnadi3>	Wwe need to figure out what I should do to round up before the submission date
<onnadi3>	Which is tomorrow, I believe
<lemmy>	Yep, tomorrow is pencils down
<onnadi3>	1. Upload my code to code.google.com
<onnadi3>	2. Make the changes you guys suggested to the documentation
<onnadi3>	No. 3 would be post on my blog about the wonders of Discovery, but you guys haven't commented on the draft I put up
<onnadi3>	Should we just skip it?
<lemmy>	we should stick to the plan and try to get as much pr as possible.
<onnadi3>	okey-doke
<rcjsuen>	yup, I agree
<lemmy>	and the comment is still on my todo list.
<onnadi3>	:-)
<rcjsuen>	onnadi3: I left a one sentence comment like 10 minutes ago
<onnadi3>	Hmm, perhaps bugzilla was still down, then
<rcjsuen>	It was synchronizing this mornign.
<lemmy>	1. Upload my code to code.google.com. Is there anything to arrange for? 
<onnadi3>	Not really. They just want to see what you've done all summer. 
<onnadi3>	rcjsuen: I don't see any need to mention SoC. It was just a vehicle for achieving our ends :-)
<benny`work>	onnadi3, do you know where to upload the stuff? can't find anything about where to do it
<onnadi3>	benny`work: This article explains everything http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2
<benny`work>	onnadi3, thanks 
<onnadi3>	lemmy, rcjsuen: Anything else you'd like me to do before pencils down?
<rcjsuen>	Don't think so.
<rcjsuen>	maybe generate API docs but I don't know where to host that
<onnadi3>	cool
<kynes>	pombreda, ping
<onnadi3>	Well, I think that's all that's on the agenda
<onnadi3>	IS there any need for us to meet tomorrow?
<rcjsuen>	I don't think so.
<onnadi3>	Alrighty. I'll shoot y'all an e-mail when I've uploaded everything
Aug 19 13:45:58 	onnadi3 is sad that it's all over
<rcjsuen>	onnadi3: Thank you for all your hard work.
<onnadi3>	rcjsuen: Thank *you* for lurking on IRC all the time and answering all questions :-)
<rcjsuen>	Just trying to pay back to the Eclipse community ;)
<rcjsuen>	onnadi3: I see you approached the occasional straggler also, thanks
<onnadi3>	:-)
<onnadi3>	Well, I better finish rounding up my SoC. Markus, Remy, I'll talk to you all later
<lemmy>	ttyl

August 14

Action items

  • E-mail Alex Blewitt to see if SoCers can post articles to EclipseZone about their projects
  • Write an article on Discovery and post it as many places as possible
  • Write documentation for Discovery in docbook format
  • Check out how Mac Eclipse does their JRE discovery
<onnadi3>	I've got meeting items here http://wiki.eclipse.org/Auto-conf_meeting_agenda
<lemmy>	ok, lets get started: How to get Discovery into the Eclipse Platform
<lemmy>	what do you mean by that?
<onnadi3>	Well, I would like my work to be used by other projects
<lemmy>	do you mean how to make discovery part of the eclipse sdk?
<onnadi3>	Yeah :-)
<onnadi3>	Is there a process for it?
<lemmy>	that is something we cannot enforce. we rather have to hope for adoption. surely we can promote discovery with blog posts and examples. but at the end of the day, the platform team will decide.
<onnadi3>	okay
<onnadi3>	That kinna leads into the second item
<lemmy>	exactly. ;)
<onnadi3>	zx suggested making a screencast
<rcjsuen_>	yeah, item 1 really goes down to PR and usability
<lemmy>	i've never done a screencast. you're talking something like a flash movie?
<onnadi3>	Yeah...
<onnadi3>	Perhaps an article would suffice. Can anyone post on Eclipsezone?
<lemmy>	at best we would have both. personally I don't like screencasts, i rather like to read normal text.
<onnadi3>	Me too
<lemmy>	we can ask alex blewit
<lemmy>	+t
<lemmy>	he is the "editor in chief".
<onnadi3>	ah, that guy
<onnadi3>	Does he lurk here?
<lemmy>	what about http://www.eclipse.org/articles/ ?
<rcjsuen_>	Nope, he doesn't.
<onnadi3>	Hello Remy :-)
<lemmy>	we should write him an email. maybe in the name of all soc projects.
<onnadi3>	That'd be great
<onnadi3>	I think  Eclipse corner will be easy enough
<onnadi3>	Oops. "hat is, articles that contain time-sensitive material or are likely to expire in a relatively short period of time do not belong on Eclipse Corner"
<rcjsuen_>	Depends what "short" means.
<onnadi3>	True, but isn't beta software the definition of time-sensitive material? :-)
<onnadi3>	Doh. We don't need to belabor this point. We can always post on Planet Eclipse. That's got mad readership
<rcjsuen_>	yeah
<rcjsuen_>	you could just paste some simple code
<rcjsuen_>	then include a zip
<rcjsuen_>	with the full thing
<rcjsuen_>	or whatever
<onnadi3>	So I guess, the bottom line is 1) E-mail Blewitt, and 2) post to Planet Eclipse
<lemmy>	onnadi3: are you going to write an email to alex? otherwise i can do it too.
<onnadi3>	lemmy: Well, if its going to be in the name of all of SoC then you should prob'ly do it. Otherwise I will
<lemmy>	onnadi3: i don't think i'm a better suited represent for soc... but ok, i'll write the email.
<onnadi3>	Oh, you don't know him personally?
<onnadi3>	Sorry, I thought you did
<onnadi3>	I can write it, in that case
<lemmy>	yeah, simply cc soc-dev
<onnadi3>	No problem
<rcjsuen_>	Don't think anyone in here really knows him that well.
<lemmy>	for agenda item #3 i suggest http://www.eclipse.org/articles/article.php?file=Article-Authoring-With-Eclipse/index.html
<lemmy>	although for a basic how to hack the wiki might be fine too.
<onnadi3>	Hmm, if DocBook can publish to HTML, then I'll go with it
<lemmy>	html, pdf, ...
<onnadi3>	good
<lemmy>	docbook doesn't contain the layout, just the structure.
<rcjsuen_>	DITA also does html / pdf, it can also transform to eclipsehelp, though I'm not familiar with the eclipsehelp bit
<lemmy>	for docbook i've done the transformation to html and pdf lately.
<onnadi3>	Alrighty. I'll start off with DocBook and switch to DITA if I hit snags
Aug 14 15:27:22 -->	jevgeni (n=def@ip50.cab81.tln.starman.ee) has joined #eclipse-soc
<lemmy>	he is hard to miss, isn't he? ;o
<lemmy>	the British accent is very strong
<lemmy>	btw. onnadi3 have you had a look at the mac jre discovery code in 3.4m1?
<rcjsuen_>	I didn't even realize there was a 'Search' button.
<rcjsuen_>	Maybe it just looks for specific path names
<rcjsuen_>	like jre/bin/
<lemmy>	rcjsuen_: the search button on the jre page is older. but it isn't a smart search, just recursive.
<rcjsuen_>	ic
<onnadi3>	From the description, it does exactly what our Discovery does
<onnadi3>	Searches a location for JREs
<lemmy>	but only on mac osx
Aug 14 15:31:14 -->	michaelr (n=no@S010600184d82fd75.cg.shawcable.net) has joined #eclipse-soc
<onnadi3>	true :-)
<lemmy>	but it is definitely worth to check how they do it.
<onnadi3>	okay
<rcjsuen_>	I wonder how it works
<rcjsuen_>	maybe like if (Platform.getOS().equals(Platform.MAC)) or whatever the actual method/field names are
<--	Pookzilla has quit ()
<onnadi3>	Well, that's it for the agenda. I'm still mailing the CDT-dev folks to try and get the Make insertion working
<onnadi3>	I tried the instructions they gave, but nothing happened
<rcjsuen_>	onnadi3: that's nice
<onnadi3>	:-)
<--	jevgeni has quit ("Bye!")
<Ali>	could you please send me a link to the sourceforge project for that? I didnt see it on teh wiki (I may have missed it though)
<onnadi3>	lemmy, rcjsuen_: When do I have to turn in all the code/docs/etc. in so you guys can evaluate?
<rcjsuen_>	Ali: eclipse-incub is the name
<rcjsuen_>	so sourceforge.net/projects/eclipse-incub
<lemmy>	as early as possible. continuous evaluation. ;)
<rcjsuen_>	onnadi3: dunno, let's see
<rcjsuen_>	probably next Friday
<rcjsuen_>	http://code.google.com/support/bin/answer.py?answer=60325&topic=10729
<onnadi3>	Alright, as soon as possible but before Friday, it is :-)
<onnadi3>	So our final meeting will be on Monday, the 20th, then?
<lemmy>	do we want to have an additional meeting in between?
<Ali>	thanks a lot. Is there any information on what is left to be implemented, what features have ben implemented and such?
<onnadi3>	lemmy: If we do, I'd rather it be between friday and sunday inclusive. That way I'd have stuff for y'all to comment on
<Ali>	I saw a comment at the bottom of the wiki regarding RSE
<Ali>	I am glad to see things are moving forward there :-)
<lemmy>	onnadi3: so we leave the precise date open but target the weekend?
<onnadi3>	Sure thing
<onnadi3>	Are there any other items to discuss today?
<lemmy>	not from my side
<lemmy>	ok, ttytomorrow
<rcjsuen_>	bye
<onnadi3>	alrighty. Bye :-)

   ===August 6 2007===

Markus explained how to use OS-specific fragments. 

Aug 06 11:35:44 <onnadi3>	I still haven't figured out how to incorporate code from OS-specific fragments
Aug 06 11:35:54 <onnadi3>	I haven't worked on that bug since I posted it
Aug 06 11:36:04 <onnadi3>	~196660
Aug 06 11:36:42 <lemmy>	bugzilla is probably still down
Aug 06 11:37:13 <onnadi3>	I can access it just fine. (why didn't KOS-MOS autocomplete?)
Aug 06 11:37:59 <lemmy>	bugzilla was down earlier today. maybe KOS-MOS needs a restart?!
Aug 06 11:38:15 <onnadi3>	strange
Aug 06 11:39:14 <KOS-MOS>	See bug 196660 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=196660
Aug 06 11:39:20 <onnadi3>	yay!
Aug 06 11:40:21 <onnadi3>	So, have you ever written OS-specific fragments before?
Aug 06 11:40:40 <lemmy>	yep
Aug 06 11:41:13 <onnadi3>	Could you send me the fragment's manifest or any other code so I can figure out how to do it in Discovery?
Aug 06 11:43:37 <lemmy>	onnadi3, swt itself uses fragments.
Aug 06 11:43:46 <lemmy>	which are pretty much platform dependent.
Aug 06 11:44:28 <onnadi3>	I just can't figure out how to make certain code/classes appear on one OS and not in another
Aug 06 11:44:42 <onnadi3>	Perhaps its not too important. We could alway just bundle em all together
Aug 06 11:45:36 <lemmy>	we could
Aug 06 11:46:40 <onnadi3>	okay
Aug 06 11:46:43 <lemmy>	the interfaces of each fragment has to be the same, but the impl might differ. actually i would move the interfaces into the host plug-in and let the fragments implement the interfaces.
Aug 06 11:47:32 <lemmy>	making certain classes appear only on a certain os kinda destroys the fragment purpose anyway.
Aug 06 11:47:39 <onnadi3>	So, we'd publish a JREFinder-win or JREFinder-osx?
Aug 06 11:47:47 <lemmy>	nope
Aug 06 11:48:18 <lemmy>	we publish a jrefinder and a jrefinder-win-fragment and a jrefinder-osx-fragment.
Aug 06 11:48:42 <lemmy>	a customer deployes all three inside osgi and osgi takes care of loading the right fragment.
Aug 06 11:49:01 <lemmy>	osgi checks the platform filter to determine which fragment to load.
Aug 06 11:50:23 <--	moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has left #eclipse-soc
Aug 06 11:50:34 <onnadi3>	Hmm, but then we're back at square one because I don't know how to set the OS filter. I've really tried and tried but there seems to be no articles that explain how to do it
Aug 06 11:50:57 <lemmy>	swt demonstrates it perfectly. Just extract org.eclipse.swt_3.3.0.vNNNN.jar and org.eclipse.swt.os.ws.arch.NNNN.jar
Aug 06 11:51:26 <lemmy>	onnadi3, os filters are explained in the osgi r4 spec. either the compendium or the core.
Aug 06 11:51:37 <onnadi3>	oh
Aug 06 11:52:16 <onnadi3>	I have the core here. Let me check it again
Aug 06 11:52:17 <lemmy>	in our case it is even easier than it is for swt. we don't need to care about arch and ws. we only need to care about os.
Aug 06 11:52:38 <lemmy>	(& (osgi.os=linux) (osgi.arch=x86))
Aug 06 11:53:04 <lemmy>	it's a ldap style "query".
Aug 06 11:56:00 <onnadi3>	Hmm, I found a small section in core about fragments. I think once I look through that and then through the jars (I didn't think of looking there), I'll be able to get this figured out
Aug 06 11:56:44 <lemmy>	in our case the platform filter will probably look just like "(osgi.os=linux)" and "(osgi.os=win32)"...
Aug 06 11:58:03 <onnadi3>	cool
Aug 06 11:59:58 <onnadi3>	Ah, I'm beginning to understand it now. The section on filters is hidden in the "Service Layer" section. That's how come I'd never seen it before

July 30 2007

<lemmy>	So what is on our agenda?
<rcjsuen_>	k we're good
<rcjsuen_>	i 'm outside the lab right now >_>
<onnadi3>	All that was left was to decide what we're to do about CDT i.e. to go ahead and discover whether Make exists on a system or not
<lemmy>	the other stuff is already done?
<onnadi3>	Well...I've implemented it and it compiles
<rcjsuen_>	lol
<onnadi3>	But I'm getting synchronization errors
<onnadi3>	(I dread Concurrency)
<rcjsuen_>	synchronization?
<rcjsuen_>	ah
<onnadi3>	I'm working on it. I hope it won't be a big deal
<onnadi3>	So, Markus, do you still think we should go ahead with just finding make on a system?
<lemmy>	yes, as it will help us to understand what we can generalize and refactor.
<onnadi3>	That's true
<rcjsuen_>	yes
<lemmy>	for example the rule set/heuristics should come from a xml file. I don't want to touch code/recompile if I add a new location.
<onnadi3>	Hmm, but the IFinder.refresh() can't be specified declaratively
<lemmy>	Why not?
<onnadi3>	Well, for instance in JREFinder, refresh() needs to call Platform and then run a loop in order to pick out the the right VMType to do the testing with
<onnadi3>	If you're going to have loops, then its no longer really declarative, is it?
<lemmy>	I don't get why this renders a xml file impossible.
<onnadi3>	Well, it doesn't make it impossible but it doesn't seem to be worth the trouble of avoiding recompilation if we'll end up writing loops and conditionals in XML
<lemmy>	conditional xml? why?
<--	rcjsuen has quit (Read error: 110 (Connection timed out))
<onnadi3>	If you can, please look at  JREFinder.isJREDirectory(). It makes use of loops and an if-statement
<lemmy>	btw. i'm still missing the jrefinder.ui plug-in
<onnadi3>	Oh? I committed that
<lemmy>	I'm talking about JREFinder.find() and the potentialJRELocations getting filled.
<lemmy>	This could be done with a simple/non conditional xml.
Jul 30 11:46:39 -->	moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has joined #eclipse-soc
<lemmy>	there is no jrefinder.ui plug-in. :o
<onnadi3>	Yeah. But what I'm saying is that IFinder also needs a refresh() method which uses relatively complex constructs that would not be suitable for XML. So we have to decide if we really want discovery plugin writers to have to separate their IFinder code into a Java part and an XML part
<lemmy>	Yes, because the xml changes independently of the refresh and more frequently.
<onnadi3>	Hmm...
<onnadi3>	That's true, too :-)
<onnadi3>	(BTW, I named the ui plugin wrongly and that's why it isn't showing up...yet)
Jul 30 11:51:52 -->	rcjsuen (i=rcjsuen@nat/ibm/x-d827998b15814402) has joined #eclipse-soc
<onnadi3>	lemmy: should we enforce the XML rule or  just let plugin writers use XML if they see fit?
<lemmy>	I don't see a reason to enforce it.
<onnadi3>	oh OK. So you meant use XML for JREFinder, then?
Jul 30 11:56:06 -->	soulreaper_ (i=soul@p54A66704.dip.t-dialin.net) has joined #eclipse-soc
<lemmy>	onnadi3, yep
<lemmy>	btw. newer swallow Exceptions.
<lemmy>	try { ... } catch(Exception e) { // do nothing } is really bad.
<lemmy>	JREFinder.readLInes()
<onnadi3>	But the silly BufferedReader throws exceptions when it hits EOF. I couldn't think of another way to test for EOF
<onnadi3>	And the API doesn't have an isEndOfFile() method
<lemmy>	What kind of exception does it throw in that case?
<--	rcjsuen_ has quit (Read error: 110 (Connection timed out))
<onnadi3>	**ahem** an IOException. I'll put that in right away :-)
<rcjsuen>	it shouldn't
<rcjsuen>	you're calling reader.readLine()?
<onnadi3>	Yeah
<rcjsuen>	If it's done
<rcjsuen>	it should return null
<lemmy>	onnadi3, the problem with catching Exception is, that it catches all RuntimeException. And somebody might be interested in certain RuntimeExceptions
<onnadi3>	Ah. Null. I didn't see that...
<onnadi3>	Good call, Markus. Will change it
<--	soulreaper has quit (Read error: 110 (Connection timed out))
<onnadi3>	Alright. Bottom line: we should get JREFinder to use a an external representation (e.g. XML) for storing the potential JRE locations
<onnadi3>	lemmy, rcjsuen: I don't think there's anything else left to discuss; Do y'all?
<rcjsuen>	I don't think so off hand.
<onnadi3>	okey-dokey. I'll do some more bug hunting and update bugzilla once this undiscovery thing is done, then

July 28 2007

  • Weekly meetings moved to 11:30am EDT/7:30pm CST
  • Designed the interface IFinder that all finders will share. See Bug 198121
<onnadi3>	rcjsuen, lemmy: Should we go ahead and get started?
<lemmy>	sure
<rcjsuen>	yes, let's do that
<onnadi3>	I would like us to go over the outstanding bugs so I can get an idea for fixing them
<rcjsuen>	before my teammates come in ;p
<onnadi3>	1. Improve configuration of new Discovery Finders
<onnadi3>	~198121
<KOS-MOS>	See bug 198121 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121
<rcjsuen>	query https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPEN
<rcjsuen>	ED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
<rcjsuen>	or not
<rcjsuen>	i see it got mangled
<onnadi3>	rcjsuen: how'd you get to that page?
<rcjsuen>	what page
<rcjsuen>	the query?
<onnadi3>	yeah
<rcjsuen>	i just constructed one from bugzilla
<onnadi3>	could you give me the parameters? I've tried it unsuccessfully before
<lemmy>	why does find() return null? why not make the method abstract?
<rcjsuen>	I guess this one is better ;) https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
<rcjsuen>	even tho we see the other bugs but anyway
<onnadi3>	lemmy: It returns null because I haven't yet implemented it. I should have noted that
<onnadi3>	Let me give the sequence of calls to Finder
<rcjsuen>	yeah that's what i figured
<rcjsuen>	so i didn't say anything there
<onnadi3>	a. You construct the Finder
<onnadi3>	b. You call find() whenever you want the service discovered
<onnadi3>	c. You call unfind() whenever you want the service undiscovered. There is also a separate thread that monitors the found service and calls unfind() at regular intervals
<onnadi3>	that's it
<lemmy>	"You" is who in the JRE scenario?
<onnadi3>	"You" is the person subclassing Finder e.g. JREFinder, MakeFinder etc.
<lemmy>	That I don't get
<lemmy>	Let me put it this way, who calls this methods during runtime?
<onnadi3>	The JREFinder plugin, for example
<rcjsuen>	In its start method?
<lemmy>	Doesn't the JREFinder implement the Finder?
<rcjsuen>	onnadi3: Query for all discovery bugs https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&component=org.eclipse.soc.discovery query for open ones https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=org.eclipse.soc.discovery
<lemmy>	s/implement/extend
<rcjsuen>	lemmy: you mean who instantiates it and calls find(), right?
<onnadi3>	That is one way. The other would be to expose the Finder class and have it called whenever the user clicks a button. That is how the JREFinder plugin is built right now actually
<lemmy>	rcjsuen: yep
<onnadi3>	I guess we should use "finder plugin" for the plugin and "JREFinder" for the class. And yes, JREFinder implements Finder
<lemmy>	So the finder plug-in calls find() on JREFinder and passes the result to the ECF discovery API?
<onnadi3>	lemmy: Actually, how I described it was that calling find() would automatically pass the result to the ECF Discovery API
<onnadi3>	rcjsuen: thanks for the links
<rcjsuen>	so what exactly is the Collection for?
<rcjsuen>	Or wait the Colection is what's been found or?
<lemmy>	so find() passes it to the PluginDiscoveryService ds instance?
<onnadi3>	rcjsuen: the Collection is not strictly necessary. I thought it would be nice to have a list of what was found
<rcjsuen>	ah kk
<lemmy>	I would separate it into find() and populate().
<lemmy>	populate() passes the find() result to ds
<onnadi3>	lemmy: Shouldn't we have instead, find(), populate() and findAndPopulate()?
<onnadi3>	So that plug-in writers don't have to do populate(Finder.find())
<rcjsuen>	onnadi3: if we go that route i'd prefer a find() and a find(boolean populate) for populating, I don't like findAndPopulate ;p
<lemmy>	rcjsuen: this look so c-ish
<onnadi3>	okey-dokey :-)
<lemmy>	looks
<rcjsuen>	lemmy: funny, beacuse I don't know C at all
<rcjsuen>	except hello world
<rcjsuen>	and how to make a struct
<rcjsuen>	I think that's about it
<lemmy>	Why have a parameter to change the behavior of a method? make two methods out of it. :)
<onnadi3>	But wouldn't it just be simpler to have the one method that find()s, populate()s and returns the found services?
<rcjsuen>	lemmy: I'm just applyign the same idea from JFace viewers refresh/update and SWT widgets layout methods
<lemmy>	rcjsuen: they are pretty c-ish too. ;o
<rcjsuen>	onnadi3: so by that you mean we have a populate() method that's populating _and_ returns the found services, yesA?
<lemmy>	Anyway, I still don't get the whole picture...
<rcjsuen>	lemmy: having to call dispose() is pretty C-ish ;)
<onnadi3>	rcjsuen: Yeah
<lemmy>	rcjsuen: dispose(*widget) would be c-ish. dispose() is rather c++-ish. .P
<onnadi3>	rcjsuen: that was a yeah regarding your comment about populating and returning
<rcjsuen>	onnadi3: I see.
<rcjsuen>	true, we're not doing free(this)
<onnadi3>	:-)
<lemmy>	We have the PluginDiscoveryService which acts as the general API for consumers like JREInjector. Consumers get discovery results from the PluginDiscoveryService for a given type.
<lemmy>	Also we have Finders which report discovery results to PluginDiscoveryService
<lemmy>	reporting results to PluginDiscoveryService is something in the responsibility of the Finders?
<onnadi3>	lemmy: Yes, since there is no one else for them to report to
<lemmy>	onnadi3: what's with Finders registering themselfs at the PluginDiscoveryService?
<lemmy>	Then the PluginDiscoveryService would call find() on all registered finders
<lemmy>	registering could be done via OSGi services (but that's just the technical side of it).
<onnadi3>	I think its the other way round. The Finder takes a pointer to the PluginDiscoveryService so that it can call registerService()
<lemmy>	are we talking about registering the finder at the plugindiscoveryservice?
<lemmy>	that is the basic necessity, if plugindiscoveryservice should be responsible for calling find()...
<onnadi3>	The reason why we can't have PDS calling find() on all Finders is because you never know when someone will want a service found e.g. in the case of having a GUI button that starts the finding process
<lemmy>	onnadi3: true, but it means also that we cannot issue a global find() on all finders.
<lemmy>	question is, what is the main use case.
<lemmy>	PluginDiscoveryService might offer discover() and discover(IServiceType)
<onnadi3>	what does discover() do? Call find() on all Finders?
<lemmy>	while the first is for issuing a general find() on all finders independent of the type, the latter is for calling find() on specific finders.
Jul 28 10:06:01 -->	sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
<rcjsuen>	I like that.
<onnadi3>	Doesn't that make what we did with JREFinder impossible then? i.e. have a GUI that initiates the find process. I'm not saying that JREFinder is the best model for structuring finders...
Jul 28 10:07:09 -->	kreismeister (n=Miranda@eclipse/developer/Eclipse/Kreismeister) has joined #eclipse-soc
<lemmy>	onnadi3: The gui would be finder independent.
<onnadi3>	Ah yes
<lemmy>	The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
<rcjsuen>	mmm yes
<lemmy>	If there is no Finder for the given IServiceType registered, nothing would happen.
<lemmy>	onnadi3: calling the specific finder directly also has the disadvantage, that you cannot easily have different finders for the same type.
<lemmy>	imagine a RegistryJREFinder and a FilesystemJREFinder.
<onnadi3>	lemmy: jolly good point
<lemmy>	They both discovery the same IServiceType "JRE"
<lemmy>	Finder would then only implement IDiscoveryResult find() and unfind(IDiscoveryResult) maybe renamed to refresh(IDiscoveryResult)
<lemmy>	But this would leave PluginDiscoveryService responsible for keeping and updating IDiscoveryResults for undiscovery.
<lemmy>	I'm not sure if this is a big disadvantage.
<onnadi3>	It can always delegate to the Finders, can't it?
<lemmy>	All this matches stuff could be handled inside the Finder
<lemmy>	onnadi3: PluginDiscoveryService will delegate the unfind/refresh of the IDiscvoeryResult to the Finder, but it needs to keep track of IDiscoveryResults.
<onnadi3>	I believe it already does that
<lemmy>	perfect :)
<onnadi3>	If we have Finders registering with PluginDiscoveryService through extension points, how will (for instance) the GUI be able to initiate a find()?
<rcjsuen>	isn't that the discovery(IServiceType.JRE) thing?
<lemmy>	The GUI will need to get the PluginDiscoveryService instance and call discover() on it.
<lemmy>	rcjsuen: exactly
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
<lemmy>	Getting the PluginDiscoveryService reference in the GUI can be done via OSGi.
<--	sonnyblack has quit (Read error: 110 (Connection timed out))
Jul 28 10:21:18 *	sonnyblack_ is now known as sonnyblack
<onnadi3>	Aaaaah
<onnadi3>	I see
<onnadi3>	rcjsuen: Could you please tell us the method names you would have preferred for the Finder class?
<rcjsuen>	isMatch -> matches
<lemmy>	I've just submitted a IFinder proposal as a bug comment
<rcjsuen>	dunno about initPotentialMatches(), unfind is pretty weird but dunno if there are better options
<rcjsuen>	lemmy: to 198121?
<lemmy>	yep
<onnadi3>	lemmy: what is the boolean in refresh() supposed to be?
<rcjsuen>	now bugzila worked
<lemmy>	onnadi3: pretty much what unfind() did.
<rcjsuen>	Eh?
<onnadi3>	Sorry, I meant what is the return value of refresh()?
<lemmy>	but IFinder is stateless. I doesn't keep track which IDiscoveryResults have been found before.
<lemmy>	boolean
<lemmy>	valid
<lemmy>	is the given IDiscoveryResult still valid or not
<rcjsuen>	hm
<rcjsuen>	validate(IDR) maybe? ;p
<rcjsuen>	that's kinda like refresh
<rcjsuen>	we're validating it again
<rcjsuen>	or maybe not
<lemmy>	true :)
<rcjsuen>	maybe validate implies a shortop
<rcjsuen>	whereas refresh is a longop?
<rcjsuen>	hm
Jul 28 10:29:45 *	rcjsuen rubs his chin.
<--	kreismeister has quit (Read error: 104 (Connection reset by peer))
<onnadi3>	Shouldn't we also have a method that refreshes all the previously found IDiscoveryResults?
<rcjsuen>	like a validateAll()?
<onnadi3>	Yeah
<rcjsuen>	hm
<lemmy>	onnadi3: IFinder.refreshAll()?
<onnadi3>	And it could return a Collection of still valid IDRs
<lemmy>	but this implies that IFinder knows about previously discovered IDiscoveryResults.
<rcjsuen>	Maybe take a Collection and pass back a Collection of valid ones?
<onnadi3>	Oh!!! I see your point, Markus. PDS is already keeping track of IDRs
<lemmy>	well, this is just convenient API then.boolean validate(IDiscoveryResult) is the minimum.
<lemmy>	Well, one problem arises with IFinder not keeping track of IDiscoveryResults. PDS needs to know by which specific IFinder instance the IDiscoveryResult has been found earlier.
<lemmy>	The RegistryJREFinder probably cannot verify an IDR discovered by the FilesystemJREFinder
<onnadi3>	Akk! This means that PluginDiscoveryService will have to handle polling when it comes to undiscovery
<lemmy>	The IDS instance could store the IFinder by which is has been found.
<lemmy>	polling? PDS certainly is responsible for refreshing IDS and hence needs to ask the various IFinders regularly.
<lemmy>	Btw validate sounds more like verification of an IDS. I tend to refresh
Jul 28 10:37:39 -->	kreismeister (n=Miranda@p57AB7FBA.dip.t-dialin.net) has joined #eclipse-soc
<lemmy>	verification in terms of "is this IDS really a Sun JRE 1.4"...
<onnadi3>	lemmy: what is IDS?
<rcjsuen>	I'm fine with refresh
<lemmy>	s/IDS/IDR
<onnadi3>	okey-dokey. So  i guesswe're pretty much done with this bug, apart from naming?
<rcjsuen>	yeah
<onnadi3>	Bug no.2: Decide on the CDT tools to provide discovery for
<lemmy>	I got a question, ca we move our meeting permanently to monday afternoon ~17:30pm?
<onnadi3>	Sure, if it works with Remy
<rcjsuen>	What time is that
<lemmy>	11:30
<rcjsuen>	ooo, that collides directly with my weekly meeting
<rcjsuen>	Although that meeting isn't that important
<rcjsuen>	cuz we can bring our notebooks
<rcjsuen>	it's an informal status update
<rcjsuen>	I think it's fine
<lemmy>	perfect, so next meeting is 07/30 11:30am EDT
<onnadi3>	ALrighty
<rcjsuen>	ok
<onnadi3>	So,  Bug no.2: Decide on the CDT tools to provide discovery for
<onnadi3>	~197885
<KOS-MOS>	See bug 197885 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=197885
<onnadi3>	(I like doing that :-))
<onnadi3>	Shall we be sticking with CDT?
<lemmy>	I'm still +1 for CDT even if it means we only do discovery of make
<rcjsuen>	yeah
<rcjsuen>	i never see people complain about setting up pdt
<rcjsuen>	(well install is hard)
<onnadi3>	So, we need to test if make is in the PATH, and if it is not, find where it is installed on the system 
<lemmy>	well, we wan't to discover all installations ofmake and not just the one in make.
<lemmy>	s/make/path
<onnadi3>	The thing is the CDT interface doesn't really have a drop-down list like JDT does
<onnadi3>	All it has is a text box where you can enter the name of the make command you want to use
<lemmy>	postponed until Monday? The other bug will keep you busy anyway, right?
Jul 28 10:57:21 -->	sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
<onnadi3>	sure :-)
<onnadi3>	Sweet meeting y'all
<onnadi3>	See ya soon
Retrieved from "https://wiki.eclipse.org/index.php?title=Auto-conf_meeting_logs&oldid=47533"

This page was last modified 19:37, 22 August 2007 by oge. Based on work by Markus Alexander Kuppe and Markus Kuppe.

Back to the top