Auto-conf meeting backlogs

July 14 2007

Action items:

• E-mail soc-dev and tell them we'll be participating in the SoC update site
• Create a new project timeline and submit to Remy and Markus for revision
• Add heuristics for finding JREs in Linux
• Move the UI in jreinjector to jrefinder (to fix Bug 196371 )
• Make JREFinder dispatch events when JREs are uninstalled
• Move OS-specific heuristics into fragments

<onnadi3> Good morning, y'all. I seem to be the center of attention ;-)
<lemmy> hi
<onnadi3> How're you doing today?
<rcjsuen> good good
<onnadi3> How long is your holiday?
<lemmy> mine?
<lemmy> until Monday
<onnadi3> Ah...very nice
<lemmy> actually i'd prefer to extend my holiday. but who doesn't? ;o
<rcjsuen> ;p
<lemmy> anyway... 1. Midterm evaluation
<lemmy> remy: are you able to fill out the form on the google page?
<rcjsuen> lemmy: acceptance pending
<lemmy> should i send you the html form and i merge it manually?
<rcjsuen> we could do that i s'pose
<onnadi3> Alrighty. Anything else on this issue?
<lemmy> nope
<onnadi3> Cool.  2. Preferences > Java > Installed JREs > Search (investigate implementation...)
<onnadi3> I looked in the source and I found the code that you added, lemmy, to get the VMInstalls registering correctly
<lemmy> I guess other parts of that code might be of interest too
<onnadi3> I think the fundamental difference is that their search is recursive and ours isn't
<onnadi3> i.e. it checks for JREs in all directories below the one specified
<lemmy> their search isn't very smart
<onnadi3> how so?
<lemmy> but it demonstrates how to work with VMInstall and such
<lemmy> onnadi3: as you said, they simple search recursively.
<lemmy> and it requires user input
<lemmy> our jre finder is supposed to work without user input.
<onnadi3> yeah
<lemmy> btw. do you see remy's and mine discussion regarding 196371
<lemmy> ?
<onnadi3> No, I don't
<lemmy> ok, i will add the important passage as a bug comment
<lemmy> btw. when creating bugs, assign 'em to you instead of soc-inbox. otherwise all mentors and students will receive notifies for that bug
<onnadi3> Oops. Gotcha :-)
<rcjsuen> yeah
<lemmy> onnadi3: when are you going to create the "heuristics" for possible jre locations? with linux discovery doesn't find anything. ;)
* benny`nb_ has joined #eclipse-soc
<onnadi3> True that. I should add it as a bug
<onnadi3> I've been spending all my time trying to get the darn injector working
<onnadi3> (and it still doesn't seem to be working right...)
<onnadi3> Per 196371: Are you saying that jrefinder should contribute to the GUI?
<lemmy> yep
<lemmy> but it might make more sense to have a jrefinder.ui plug-in which handles ui
<lemmy> ui == the button
<onnadi3> So when you click on jrefinder, it finds services and sends them to discovery and then jreinjector listens for these events and inserts the JREs as it finds them?
<lemmy> exactly
<rcjsuen> yes, always split core/ui
<lemmy> the ECF API does send events, right?
<onnadi3> Yes it does
<onnadi3> (its so well-designed)
<lemmy> then this should work
<onnadi3> BTW, do y'all know why the JREFinder won't start when I run the injector GUI?
<lemmy> it is something which we do not really want anyway.
<lemmy> the injector shouldn't know about the finder. hence the dependency in injector needs to be removed.
<onnadi3> Ah
<lemmy> they only communicate via the (well designed) ECF API.
<onnadi3> :-)
<rcjsuen> lemmy: lol
<onnadi3> Good. Then I think we done with that
<lemmy> onnadi3: some day we might use a different finder. if we keep finder/injector separated it is really simple to replace either of them.
<onnadi3> lemmy: Good point
<lemmy> dependencies should be minimal, always.
<onnadi3> hear hear
<rcjsuen> Music to my ears.
<onnadi3> Shall we move on to 3. Dynamic discovery and undiscovery  ?
<lemmy> onnadi3: do you have a timeline when jreinjector will be done?
<onnadi3> Ahem...it was supposed to be done this week :-\
<rcjsuen> ah
<onnadi3> And it works, just apart from getting values from the Finder
<lemmy> i'm more talking about a version for which it is worth being included in the soc update site.
<lemmy> so with "real" heuristics.
<onnadi3> Hmm, do you know when the update site will be going live? Because I should have the code done by then, whenever it is
<rcjsuen> Don't think anyone really has a firm date.
<lemmy> well, we can join the update site later. we don't really need a simultaneous release since all projects are rather independent.
<onnadi3> OK
<lemmy> which doesn't mean it should take forever. ;)
<onnadi3> That reminds me, let's add to the agenda: 7. Reassess project timeline
<onnadi3> I think I need a few deadlines to keep me on my toes
<lemmy> do you want to use some project planing tool? i wouldn't suggest it, but...
<lemmy> with mylyn we can schedule tasks but i'm not sure if they are replicated into the repo.
<onnadi3> Oh no. I just think the timeline I proposed in my proposal is out of date and so we should fix new deadlines and deliverables
<onnadi3> seeing as so much has changed in the project
<lemmy> we should update the high level tasks too. but don't you think we should plan more fine grained?
<onnadi3> Sure
<onnadi3> But, we need a new timeline either way because some of the milestones in the original proposal are no longer valid
<onnadi3> So should we work on that now, or leave that for number 7 in the agenda?
<lemmy> i think it makes more sense if you write the timeline "proposal" and remy and i have a look at it after wards.
<onnadi3> Alrighty!
<rcjsuen> yeah, we can review it later
<onnadi3> 3. Dynamic discovery and undiscovery 
* onnadi3 doesn't know what it means
<lemmy> it means receiving an event if a service is gone.
<rcjsuen> things come and go, like a network connection
<lemmy> for example a jre might be delete for some reason
<onnadi3> Ah. Weren't you and Remy discussing this earlier?
<lemmy> yep, network services are a much better example for dynamic
<lemmy> earlier today?
<onnadi3> Yeah
<onnadi3> "<rcjsuen> suddenly lsoing a jre isn't very fun" :-)
<lemmy> for the filesystem it might be possible to use some native code to get notified once a folder is modified/removed.
<lemmy> that way we wouldn't need to do constant rediscovery.
<onnadi3> So who will be responsible for undiscovery? Us or the Discovery clients?
<onnadi3> i.e. will the have to write a JREUnFinder plugin?
<lemmy> and actually i believe eclispe already uses native code to observe the fs.
<rcjsuen> lemmy: yeah, it does
<rcjsuen> i dunno if jdt puts locks on found jres
<lemmy> technically it doesn't matter if you create a second plug-in. personally i would have used the same one.
<lemmy> i don't see a big advantage of creating a second plug-in.
<onnadi3> True true
<onnadi3> But they'd be responsible for writing the code that detects the removal of the services they found earlier, right?
<lemmy> who is they?
<onnadi3> The people who write things like  JREFinder
<lemmy> yep
<onnadi3> 'key-doke
<onnadi3> In that case, there isn't anything we'd add to Discovery itself. I'd just have to add some "unfinding" code to JREFinder and make sure that the Injector listens for the vents it sends too
<lemmy> yep
<onnadi3> alright
<lemmy> remy: are you familiar with the native fs code?
<rcjsuen> not at all
<rcjsuen> i mean, you're just interacting with core.resources
<lemmy> do you know if this is abstracted out of the workbench?
<rcjsuen> well
<rcjsuen> maybe efs is also using the native code
<rcjsuen> but IResource is only for stuff in the IWorkspace
<rcjsuen> unless you add the damn jre folder as a project...but obviously no
<lemmy> for the moment i can certainly live with doing a rediscovery every once in a while.
<rcjsuen> as long as it's in a _cancellable_ job that's coo
<lemmy> i'd be satisfied if undiscovery of disappeared local services (fs) works
<rcjsuen> yeah
<lemmy> cancellable doesn't need to be wired up the ui imo. Some property is fine for that. In the end we want the smart solution which doesn'T require a property.
<lemmy> at all
<lemmy> a simple background job that triggers rediscovery
<lemmy> keyword: Job API ;)
<rcjsuen> yeah
<onnadi3> lemmy: I didn't really your statements about cancellable
<onnadi3> Do you mean the UI won't have a button letting you cancel the rediscovery?
#eclipse-soc created on Sun Nov 26 01:42:43 2006
<lemmy> i don't see it necessary. if you find it easy to do, just do it. :)
<rcjsuen> onnadi3: when you use Jobs the button will be there
<lemmy> i'm just saying i'd rather spent my time working on the real solution (using native fs code to get notified) instead. :)
<lemmy> only if it is a user job and there is no job to stop the rescheduling.
<lemmy> s/job/button
<rcjsuen> lemmy: in terms of opening streams in efs, they just use FileInputStream
<rcjsuen> really?
<onnadi3> I'm not sure I'm following. What does this all imply for when I'm writing the JREUnFinder?
<rcjsuen> i create many jobs
<rcjsuen> they have the stop button
<rcjsuen> they just run in the background in Progress view
<lemmy> which will terminate the current job. But if it is rescheduled again.
<onnadi3> Aaah
<onnadi3> Jobs API. I think I understand now
<lemmy> :)
<lemmy> Track bugs on the main wiki page?
<lemmy> What's the advantage over bugs.eclipse.org? If there is one...
<onnadi3> I noticed that some other students had fancy links on their homepages that linked to the bugs they were workign on. I was wondering if there was an easy way to do this or if it was all done by hand
<rcjsuen> lemmy: okay, nm, i see what you mean no
<rcjsuen> now
<rcjsuen> probably by hand
<onnadi3> Oh. Then its not worth it. I think we can stick with da 'zilla
<onnadi3> 4. participate in SOC update site?
<onnadi3> +1
<rcjsuen> yes, the project's pluggable for such a thing
<lemmy> onnadi3: participating with the first really usable version of discovery or participate in any case?
<lemmy> to bazar or not to bazar :)
<onnadi3> If we're participating, then it will be made usable if it isn't already 
<onnadi3> (ahem :-) )
<lemmy> k
<lemmy> After the JRE examples are done, what next?
<lemmy> by then we will have a really generic framework with which it will be easy to do the autoconf use case. :)
<onnadi3> autoconf??
<onnadi3> And BTW, don't we already have the framework? I thought we're just working on the use cases now
<lemmy> don't be so picky about the words. ;-)
<onnadi3> ah :-)
<lemmy> jreinjector/jrefinder is indeed the first use cases but also proof of concept.
<onnadi3> So after this, do we move on to sthg like GCCinjector/finder etc.? Should we even be deciding that now?
<lemmy> do you think this needs to be decided right now?
<lemmy> i don't think so.
<lemmy> do you?
<rcjsuen> not really worth it, deciding now and then doesn't really have much of an effect
<onnadi3> rcjsuen: true :-)
<onnadi3> So for now, we just work on polishing jrefinder/injector and we see ow it goes from there
<rcjsuen> same amount of time spent, and as the thing gets refined and all, a more approrpiate choice may surface in terms of "what to try next"
<lemmy> polishing == making it usable? ;-o
<onnadi3> lemmy: Well, let's say more fully featured...and usable :-)
<lemmy> polishing sounds way too much marketing
<lemmy> hehe
<onnadi3> Looks like we cleared that agenda out, guys
* kreismeister has joined #eclipse-soc
<onnadi3> Meeting adjourned?
<rcjsuen> I think so.
<onnadi3> Sweet

July 2, 2007

This was a weekly meeting, but it was held on a Monday instead of Saturday because of a time mixup.

Issues discussed:

1. How to turn a set of plugins into a feature

Use File->Export. Nick Boldt will be writing a tutorial on it soon.

2. Oge worried that Discovery was useless since people (e.g. Aptana) already have auto-configurers that seem to work fine without Discovery.

Discovery allows anyone--not just the developers of the plugins that require the services--to write and publish finders. That is why Discovery is useful.

3. Oge couldn't log in to SoC CVS

Markus noted that the correct repository string is :extssh:mkuppe@soc.eclipse.org:/cvsroot/soc/org.eclipse.soc.discovery

4. Agreed to use a standard directory layout (/doc, /test, /features etc.) when moving code into SoC CVS

5. http://pag.csail.mit.edu/continuoustesting/ is a tool for continuous testing.

6. Markus and Remy banter like they've known each other for years

<lemmy> onnadi3/rcjsuen: so what is it we want to talk about?
<lemmy> How to package and export plugins as a feature
<lemmy> Heuristics for finding a JRE/convenience library for heuristics
<lemmy> is this still active?
<rcjsuen> We can talk now, now would be a good time for me. dunno for you though, lemmy
<rcjsuen> I think Nick might be blogging about how to bundle a featuer
<lemmy> I thought 3pm has been planned as our designated meeting time.
<rcjsuen> lemmy: yes, that's the planned time
<onnadi3> Oh hey, you guys wanna talk now
<rcjsuen> I'm saying "I can talk now too instead of then"
<rcjsuen> "Or we can talk then"
<rcjsuen> Doesn't matter
<onnadi3> I'm fine with now. Markus?
<lemmy> do we have anything on the agenda?
<onnadi3> Yup
<lemmy> the items listed on the meetings wiki page?
<onnadi3> Yup
<onnadi3> 1. How to package and export plugins as a feature
<rcjsuen> You can use the 'Create Ant build file' method I guess
<rcjsuen> there's a build.update.jars method
<rcjsuen> er, ant target, that is
<rcjsuen> I'm _assuming_ it makes jars for the UM to consume
<rcjsuen> Though the whole feature.xml thing's another can o worms
<onnadi3> So I can export it like that, and to test it, simply open the JAR using UM
<rcjsuen> open jars with the update manager?
<rcjsuen> Maybe you can checkout some existing features and see how the files are written. I've never packaged stuff so have no idea I'm afraid.
<lemmy> don't create a build file if you don't need special steps during build.
<rcjsuen> lemmy: you mean just use File Export?
<rcjsuen> That works too.
<lemmy> either use export or use cmdline build. the important thing is to have a bundling feature for the um
<onnadi3> Alrighty, I'll try that
<rcjsuen> Well, Nick and Wassim seems to hate file export, so
<rcjsuen> file export does work though
<rcjsuen> I use it
<onnadi3> A follow up question is:
<rcjsuen> Where to put the update site?
<onnadi3> 1b. What do you want me to have in this midterm feature? What we'd agreed on before or anything more
<onnadi3> (I think Nick mentioned a particular site where teh features would go)
<rcjsuen> Oh, there's a common site, how handy dandy.
<rcjsuen> It's good to know some people know what's going on. ;)
<lemmy> for the feature you'll need to know the site, but not immediately.
<onnadi3> OK
<lemmy> simply create the site, define the included plug-ins and the dependencies the um should check.
<onnadi3> Gotcha
<onnadi3> The last item (its not on the agenda) is something that's been worrying me a bit
<onnadi3> I was looking at Aptana the other day and I noticed that it automatically detects where Ruby is installed as a convenience for the user
<onnadi3> And I thought, if all our Discovery is doing merely providing a framework and the plugin developers still need to write the feature finding themselves, then what good, really, is our project?
<onnadi3> Is it that the auto-discovered items can be shared?
<lemmy> onnadi3: have you had a look at the aptana source?
<onnadi3> No I haven't. That'd be something to check out
<lemmy> and i don't really see why discovery would be useless. there is no discovery for jdt nor cdt.
<rcjsuen> I don't think this is a useless project.
<rcjsuen> Once the framework is in place and has a solid API, you can write as many implementations as you want.
<rcjsuen> It's kinda like ECF. All we have are a bunch of interfaces really.
<rcjsuen> onnadi3: I felt the same way you did. I was like "what do I do with all these interfaces? what's the point?"
<lemmy> exactly. and the aptana stuff is probably something really specific to ruby anyways.
<rcjsuen> have some kinda collection of implementations on your website, whatever you want
<rcjsuen> Oge's JRE finder
<rcjsuen> and maybe someone else writes a JRE locator too
* rcjsuen shrugs.
<onnadi3> I see
<rcjsuen> onnadi3: If Markus and I didn't believe that this project would be useful, we wouldn't be here right now.
* onnadi3 laughs
<onnadi3> Alrighty :-)
<lemmy> rcjsuen: this kinda implies that we are all knowing. ;)
<rcjsuen> well, we'd still be here helping other students, but anyway
<rcjsuen> Well lemmy obviously saw some potential if he decided to mentor you
<onnadi3> Cool, guys. I think the cloud of doubt has passed over me this time
<onnadi3> (it better not come back)
<lemmy> hmm, in contrary to ~194211 i can't find the discovery component.
<onnadi3> in CVS or bugzilla?
<rcjsuen> lemmy: yeah that feature isn't implemented yet, sorry
<rcjsuen> ~194211
<KOS-MOS> See bug 194211 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=194211
<lemmy> onnadi3: also for my day work i'm very interested in discovery. I plan to use it in the RCP i'm writing.
<rcjsuen> and for some reason the bug summary doesn't show up anymore ;(
<lemmy> onnadi3: bugzilla
<rcjsuen> lemmy: i think Denis thought bugzilla?
<rcjsuen> The discovery component has been created.  Markus and Ogechi already have
<rcjsuen> access and Remy will be given access as soon as I receive the go ahead from
<rcjsuen> Eclipse legal.
<rcjsuen> implies some kinda password access
<lemmy> rcjsuen: and bugzilla is exactly what i'm talking about. %)
<rcjsuen> whoops
<rcjsuen> i mean
<rcjsuen> i think he thought cvs
<lemmy> if i try to enter a new bug for soc, there is no discovery component.
<onnadi3> Guys, can any of you access the SoC CVS repository? I still can't
<rcjsuen> I haven't tried tbh.
<lemmy> rcjsuen: hmm, you might be right.
<lemmy> onnadi3: i can. 
<onnadi3> lemmy: did you use your bugzilla username and password, or the ones Wayne sent in the mail?
<lemmy> rcjsuen: I'll reopen the bug and point out that I've meant bugzilla.
<lemmy> onnadi3: your committer password. Mine was sent by matt iirc.
<rcjsuen> lemmy: k
<rcjsuen> yeah i think i got mine from matt
<onnadi3> And are you using ext: or extssh: ?
<lemmy> extssh
<lemmy> :extssh:mkuppe@soc.eclipse.org:/cvsroot/soc
<lemmy> you should be able to paste this into the cvs perspective.
<rcjsuen> tbh I don't even know why they made soc.eclipse.org
<lemmy> but replace my username
<rcjsuen> soc is a Technolgoy project
<rcjsuen> just put it there? jeebus
<lemmy> rcjsuen: i don't know either. it is really annoying because you don'T get access to dev.eclipse.org
<rcjsuen> lemmy: 
<rcjsuen> lemmy: good point
<rcjsuen> maybe that's why
<rcjsuen> Even though with ACLs you can't commit to non-org.eclipse.soc/ areas anyway technically speaking
<lemmy> rcjsuen: but why make a soc mentor a second class citizen?
* rcjsuen shrugs.
<rcjsuen> lemmy: because we _are_ second class citizens
* rcjsuen queues zinger.
<lemmy> rcjsuen: willing to open a bug about it?
<rcjsuen> If they were going to do that they would've done it
<rcjsuen> I think I'll write an email to soc-dev later
<lemmy> anyway, lets get back to the topic at hand.
<lemmy> onnadi3: success with extssh?
<onnadi3> no. Gimme another sec
<onnadi3> Ha!
<onnadi3> Ha!
<onnadi3> They gave me the wrong repository string. You *are* all knowing, Markus
<rcjsuen> what did they give you?
<lemmy> and who is they?
<onnadi3> They, being Matt, gave me soc.eclipse.org:/soc/org.eclipse.soc.discovery
<rcjsuen> ah
<onnadi3> But now it works, and thass all that matters :-)
<lemmy> onnadi3: /cvsroot/soc/org.eclipse.soc.discovery
<onnadi3> Ah, that's what it shoulda been
<lemmy> that's where you should move the content over from eclipse-incub
<onnadi3> Gotcha. So for now I should
<onnadi3> 1. Make JREFinder check in a few places for JREs
<onnadi3> 2. Package it as a feature
<onnadi3> 3. Add to SoC CVS
<lemmy> but wait. let me check if i can move the whole repo including history before you mirror the source to soc.eclipse.org
<onnadi3> oh OK
<lemmy> sf.net seems to be dead currently.
<lemmy> 4. write the "jdt preference injector"
<lemmy> which injects discovered values into the corresponding jdt preferences.
<onnadi3> lemmy: I don't quite follow. What I have is a JREFinder and JREConsumer. The Consumer listens for JRE events and collates allt he locations it hears of
<rcjsuen> lemmy: you basically mean populating the Installed JREs preference page, yes?
<lemmy> onnadi3: write a second consumer which stores the discovered values in the jdt preference page.
<onnadi3> OK
<lemmy> hmm, do we want to adopt the cvs doc/, examples/, plugins/, features/ and test/ layout for discovery?
<rcjsuen> It's probably a good idea.
<lemmy> +1
<rcjsuen> I mean, it's not like, it's a lot of work
<rcjsuen> you just type ten more characters to the repo path
<onnadi3> lemmy: If its a common standard, sure +1
<lemmy> btw. am i the only one with problems connecting to sf.net?
<onnadi3> No problems here
<onnadi3> Connecting to SF CVS
<rcjsuen> I tried sync earlier and was fine IIRC
<lemmy> i cant even connect to www.sourceforge.net
<rcjsuen> loads fine here
<onnadi3> fine here
<onnadi3> rcjsuen/lemmy: BTW, what continuous testing/build tool do you guys use? I'm getting kinda tired of clicking through menus to run my unit tests
<lemmy> parabuild
<rcjsuen> We don't have continuous testing ;p
<lemmy> but i fear parabuild is kind of out of our scope.
<rcjsuen> the releng setup is rather iffy so I haven't set it up for my team yet
<lemmy> onnadi3: use a simple scheduler like cron
* sonnyblack has quit IRC (Read error: 110 (Connection timed out)�)
<onnadi3> Ah. So it'll run the test suite every minute or so, eh? Is there a way to make the results show up in Eclipse or will I have to switch back and forth from the console to Eclipse?
<lemmy> I don't know of a way to make the result show up in eclipse. we use email and rss notification for build problems.
<onnadi3> Alrighty...there goes my belief that Eclipse does everything :-)
<lemmy> well, you could implement a simple scheduler as a side project. shouldn't be too hard starting a Job every n minutes.
<lemmy> but wait, I'm rembering something...
<lemmy> http://pag.csail.mit.edu/continuoustesting/
<lemmy> might need some love to make it compatible with 3.3
<onnadi3> lemmy: That's awesome. Do you think it would work fine on Eclipse 3.2?
<lemmy> onnadi3: if you're still on 3.2, please upgrade to 3.3
<onnadi3> Oh yeah. Europa and all. I *should* upgrade
<rcjsuen> lol
<rcjsuen> 3.2
<rcjsuen> last year's news
<onnadi3> :-)
<onnadi3> Alrighty. I guess I'm all out of questions. Do you guys have anything to add to this illustrious meeting?
<lemmy> true, new year has started on 06/27 in eclipse land. :)