Difference between revisions of "Auto-configuration meeting logs"

Latest revision as of 11:15, 26 May 2007

<onnadi3> Two things: <lemmy> unfortunately I had no time to send out an agenda. <onnadi3> 1. Weekly meeting times <onnadi3> 2. Agenda for this coming month, or at least the next few weeks <onnadi3> 3. Perhaps all get on the same page about hte project's objective <onnadi3> (that's not 3, I know :-) ) <rcjsuen> I'm not sure when Philippe will send out an email for weekly meetings. <rcjsuen> Since the program starts on Monday is it? <onnadi3> yup <lemmy> About 1. I'll be back in Germany 11th of June which should allow us for more flexible meeting times. <rcjsuen> I can't do weekday meetings since I have a full-time (internship) job. <lemmy> I'm rather busy through the week myself and would prefer meetings on the weekend too. <onnadi3> Alright. Should we perhaps stick with this time until we find a better time? <rcjsuen> Saturday mornings are no problem with me. <lemmy> Sounds like a plan to me. <onnadi3> Alrighty! Next up, 2. Agenda for this coming month, <lemmy> We definitely need to setup SCM. <lemmy> onnadi3: Have you started the Eclipse IP process already? <onnadi3> I thought, the eclipse-dev folks were going to send out an e-mail to all of us en masse <lemmy> Lets check the soc bug again... <rcjsuen> wizEpit: Hi wizEpit, don't think I've seen you around, are you a student? <rcjsuen> yeah, It's been a while, I don't really remember the details <rcjsuen> Can always just use SF for now. <rcjsuen> we all did so last yr anyway ;p <lemmy> We should get the process started anyway. Don't you agree that the code might end up in Eclipse? <onnadi3> Yes yes yes <rcjsuen> I'm not sure which project would consume it though. <lemmy> It will be easier if the code is already at eclipse.org i guess. <lemmy> Do you have a SF id ogechi? <rcjsuen> lemmy: Right <rcjsuen> I think I added him already <onnadi3> No. But I have a google id and I have used Google's project hosting before <onnadi3> Its really easy <rcjsuen> okay i guess not the n;p <lemmy> I would prefer to use SF. Eclipse GSoC has a project set up already. <lemmy> And GSoC doesn't require us to use their facilities. <lemmy> http://sourceforge.net/projects/eclipse-incub <onnadi3> lemmy: so all the past GSoC projects are held in SF under one source tree? <rcjsuen> not "all" <rcjsuen> some...didn't ;p <rcjsuen> http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/ <rcjsuen> by some i mean lots <onnadi3> :-) <rcjsuen> I don't know how strict pombreda is going to be this year though ;) <rcjsuen> It's just easier for the populace to find GSOC code. <rcjsuen> If they're all in one place, naturally. <onnadi3> OK. THat makes sense. <onnadi3> So once I get an SF id, I can e-mail rcjsuen to get added to the incub project? <lemmy> you can email either remy or me. <lemmy> or both of us and see who acts fiirst. ;) <rcjsuen> We all have admin rights actually. <rcjsuen> You can just speak up here. <rcjsuen> Someone with free time will do it. <lemmy> What about CVS vs SVN? <onnadi3> SVN, unless someones has a strong opposition to it... <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 ;-)