Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Auto-conf meeting backlogs3
31 May 2007
The first review of my submitted code. This was also where the name org.eclipse.discovery was decided.
onnadi3> lemmy: you want me to walk you through my code?
<lemmy> a second
<onnadi3> alrighty
<lemmy> I see that you use Java5...
<rcjsuen> AhtiK: no no no, don't worry about what's in eclipse-incub
<onnadi3> yeah. Doesn't everyone? :-)
|<-- AhtiK has left freenode ("Ex-Chat")
<lemmy> rcjsuen: Do you want to talk about EEs?
<lemmy> And foundation
-->| AhtiK (n=ahtik@194.204.31.19) has joined #eclipse-soc
<rcjsuen> yes, I do
<rcjsuen> I care about EEs because I do a lil' eRCP hack-age
<rcjsuen> onnadi3: So do you know what Execution Environments are?
<rcjsuen> onnadi3: And actually, most of Eclipse is still written with pre-1.5 APIs.
<rcjsuen> onnadi3: http://wiki.eclipse.org/index.php/Execution_Environments
<onnadi3> uh...not really
<AhtiK> what's the onnadi3 project?
<AhtiK> there are eclipse projects that REQUIRE java5
<AhtiK> at eclipse.org
<rcjsuen> AhtiK: yes, that's correct
<rcjsuen> and i think apt has JavaSE-1.6 requirements
<onnadi3> AhtiK: its eclipse-autoconf in CVS
<rcjsuen> onnadi3: Basically, it's a constraint at the plug-in level to mandate the APIs that can be used.
<rcjsuen> Although this isn't forced directly, although you can set incompatible EEs as warnings.
<rcjsuen> Equinox (or maybe OSGi in general?) will read a plug-in's Execution Environment and determine whether it can be started or not if it needs to be started.
<rcjsuen> So if I only have J2SE-1.4 installed, it reads a J2SE-1.5 EE in some MANIFEST.MF
<rcjsuen> That plug-in will NOT be started.
<rcjsuen> This saves us from weird problems like NoClassDefFoudnError
<onnadi3> Ah. So I should write my code in Java1.4 style, right?
<rcjsuen> or that minor/major version issue
<rcjsuen> Actually, we are considering making it even smaller
<rcjsuen> So that it can be used in the embedded space
<rcjsuen> So this would be a CDC-1.0/Foundation-1.0 profile.
<AhtiK> rcjsuen: ahh ok, Now I see what you meant by bad example. true, we discovered already last year that every project should have just ONE directory instead of these three I made :) these should have been under wordwrap dir..
<rcjsuen> A lot of Eclipse plug-ins are actually at that level.
<rcjsuen> AhtiK: ;)
<AhtiK> we didn't care to clean up because moved to soc.e.o, if I remember correctly :)
<onnadi3> rcjsuen: Huh. Is there a way to get eclipse to flag code that I write that is not in a particular EE?
<rcjsuen> yeah, I think so
<rcjsuen> I am not aware of this feature.
<onnadi3> I'm not sure I can tell what differentaites Java 1.3 from 1.4
<rcjsuen> you get warnings if the jre isn't the right match
<rcjsuen> That's why you install a smaller JRE on your computer and use that for your project
<rcjsuen> is how that would work
<rcjsuen> to prevent you from using 1.5 APIs or 1.4 APIs or whatever
<onnadi3> aaaaah
<rcjsuen> lemmy: so we do want to set a low constraint of f-1.0?
<lemmy> Do you see a reason to use a higher level? I don't
<onnadi3> :-O 1.0!!
<onnadi3> That's old school. This will be fun
<lemmy> We can always move upwards
<rcjsuen> onnadi3: CDC-1.0/Foundation-1.0 is a subset of J2SE-1.3.
<rcjsuen> lemmy: that's correct
<rcjsuen> ~wiki J9
<KOS-MOS> Check out this wiki article - http://wiki.eclipse.org/index.php/J9
<rcjsuen> With F-1.0, you lose things like
<rcjsuen> URI
<rcjsuen> and String's split method
<rcjsuen> and Exception chaining
<rcjsuen> but you'll probably extend CoreException
<rcjsuen> so don't worry about that latter bit
<onnadi3> Could you please explain Exception chaining?
<rcjsuen> you know like
<rcjsuen> throw new IOException(e);
<rcjsuen> rather
<rcjsuen> you catch an IOException
<rcjsuen> then throw a more specific one to yours
<rcjsuen> throw new MyNewException(e);
<rcjsuen> the concept of passing an Exception (or Throwable I guess?) to another one so that it keeps chaining/propgating is introduced in 1.4
<rcjsuen> but anyway, with CoreException don't worry about it, same thing
<rcjsuen> we did the same thing with ECF
<rcjsuen> had ECFException extend CoreException instead of Exception
<lemmy> onnadi3: a reason to use foundation 1.0 is because provisioning seems to be interested in using autoconf.
<rcjsuen> lemmy: lol, good call
<rcjsuen> i totally jus tforgot about that and just explained EEs ;p
<rcjsuen> sorry ;(
<onnadi3> who's provisioning?
<rcjsuen> Provisioning is an incubator project for Equinox.
<lemmy> Remy: that's what makes a good team. ;)
<rcjsuen> http://www.eclipse.org/equinox/incubator/provisioning/proposal.php
<lemmy> onnadi3: being utilized by provisioning is something to feel proud about.
<lemmy> ;)
<onnadi3> Alright! Just one week on the job and the higher-ups are already taking notice :-)
<rcjsuen> ^about J9, you will download J9 as your JRE
<onnadi3> rcjsuen: OK. Is that what you use to do Eclipse dev?
<rcjsuen> yes, i have that installed on my machine for working with ecf and ercp
<AhtiK> come on guys :P don't you want to use normal programming constructs like generics and enums?:)
<lemmy> onnadi3: two more things besides the EE. We should create a CVS structure much like ecf-bittorrent and your projects/plugins should start with org.eclipse.
<lemmy> This also applies for plugin names
<onnadi3> I'm checking out ecf.bittorrent right now
<lemmy> package structure inside the plug-in should follow the name of the plug-in or the other way around. bottom line, they should be aligned.
<onnadi3> Very nice. So is it okay to use org.eclipse.autoconf or should we get a better name?
-->| pombreda (n=pombreda@c-71-198-189-95.hsd1.ca.comcast.net) has joined #eclipse-soc
<lemmy> One last thing... classes which are not supposed to be used by other plug-ins are to be "locked away" in the *.internal.* name space
<lemmy> onnadi3: do we have a better name yet
<onnadi3> lemmy: ach. How do I place things in the "internal" namespace?
<lemmy> org.eclipse.discovery?
<lemmy> onnadi3: it's as regular package. :)
<onnadi3> So, all private classes should be placed in the org.eclipse.internal package?
<lemmy> Actually it isn't official JAVA standard although people have started to talk about the inclusion. Something like an access modifier for projects.
<lemmy> org.eclipse.autoconf.internal
<onnadi3> lemmy: (I like org.eclipse.discovery. What do you think rcjsuen?)
<lemmy> plug-in.name.space.internal.*
<rcjsuen> discovery works
<rcjsuen> where's that doc on the wiki
<rcjsuen> onnadi3: http://wiki.eclipse.org/index.php/Naming_Conventions
<lemmy> as long as we ain't be sued by discovery channel. ;o
<onnadi3> I'm so going to make a discoverer for a "Channel" plugin so I can have org.eclipse.discovery.channel
<lemmy> In Germany the former federal telecommunication company tried to get a trademark on the "T".
<onnadi3> Holy moley! All this documentation. I'm gonna be reading the Eclipse wiki all weekend :-)
|<-- slewis2 has left freenode (Read error: 110 (Connection timed out))
<lemmy> Last but not least... IMO we should target Eclipse 3.3 instead of 3.2
<onnadi3> lemmy: were they allowed to copyright, "T"?
<lemmy> onnadi3: AFAIK it was denied. :)
<onnadi3> Huh? Shouldn't it be Eclipse 3.1 or lower?
<ijuma> or lower?
<ijuma> that would be quite nasty ;)
<lemmy> < 3.1 makes nearly no sense. It isn't based on OSGi
<onnadi3> Oh. I thought it was a general principle to allow as many Eclipses to use a plugin as possible
<lemmy> Let me elaborate on this one. for org.eclipse.discovery.jdt we should target 3.3 whereas for org.eclipse.discovery itself, we should try to keep our dependencies as minimal as possible. If possible just org.osgi.
<rcjsuen> lemmy: 3.0 is OSGi no?
<rcjsuen> but technically if provisioning wants this, 3.3 is no biggie
<lemmy> rcjsuen: IIRC 3.1 has been the first OSGi based version, though they started porting with 3.0
<rcjsuen> o
<rcjsuen> I tried writing 3.0 plug-ins using 3.2
<rcjsuen> wow, that was painful
<lemmy> software history :)
<rcjsuen> I think I ended up coding in 3.0 instead
<lemmy> which is also painful.
<onnadi3> How exactly would I target Eclipse 3.3? Simply setting the minimum version to 3.3 in org.eclipse.discovery.jdt?
<rcjsuen> You'd just use 3.3 as your target platform in the pde prefs
<onnadi3> OK
<onnadi3> I think I got it. Code in Java1.0. Set org.eclipse.dioscovery's min version to 3.1, and set org.eclipse.discovery.jdt's min version to 3.3
<rcjsuen> Well, you're not actually using Java 1.0.
<rcjsuen> Believe me it's not as painful as it sounds. CDC-1.0/Foundation-1.0 is pretty big imo.
-->| soulreaper (i=soul@p54a648b6.dip.t-dialin.net) has joined #eclipse-soc
|<-- jburd has left freenode (Read error: 60 (Operation timed out))
<onnadi3> uh. Sorry if I missed it earlier but what is "CDC-1.0/Foundation-1.0"? Is it provisioning?
<lemmy> onnadi3: for org.eclipse.discovery.drools (name will probably differ), we will probably need a different EE anyway.
<rcjsuen> onnadi3: that's the name of the execution environment
<rcjsuen> This is what 1.1 looks like http://java.sun.com/javame/reference/apis/jsr218/
<rcjsuen> I could never find 1.0, it's stupid.
<onnadi3> Ah. Aaaah. Bytecode. It all makes sense
<onnadi3> CDC is just a set of classes that I should use instead of those in J2SE v.5
<onnadi3> Alright. I'm glad we cleared this all up.
-->| benny`work (n=benny@eclipse/developer/Technology/bennywork) has joined #eclipse-soc
<lemmy> Nothing left for Saturday. ;)
<lemmy> Hi Benny
<onnadi3> :-)
<rcjsuen> lemmy: ;)
<benny`work> hi lemmy
<onnadi3> lemmy, rcjsuen: have you looked at the plugin.xml files? Is there anything I'm obviously missing?
<rcjsuen> i haven't had a chance, this project at work is taking up most/all of my time
<rcjsuen> onnadi3: In the Overview tab you can specify your execution environment tho
<rcjsuen> by can i mean you _ should_ ;)
<rcjsuen> whenever i see ppl that don't use EEs, I file them a bug right away
<onnadi3> Rcjsuen: Oh yeah. Sorry. I forgot you're at work
<rcjsuen> well, Markus goes to work too ;)
<onnadi3> But he's at home now...aren't you Markus?
<lemmy> Remy hopes to get the EE-police award next year at EclipseCon. %)
<onnadi3> hahahaha
<lemmy> Actually I'm already lying in bed.
<rcjsuen> I rarely use my notebook on a bed
<rcjsuen> always the table
<lemmy> Don't worry, I'm not naked.
<onnadi3> hahahahhahaaha
<onnadi3> Well, I think making all the changes you guys recommended will take up a lot of time already. Plus, I gotta read all the standards docs
<lemmy> hmm, org.osgi for org.eclipse.discovery would rule out extension points
<ijuma> ok, so there are 2 things rcjsuen feels strongly about, EE and bandwidth
<rcjsuen> ijuma: quite so
<onnadi3> lemmy: how so?
<lemmy> onnadi3: better do it early. with each new line of code it gets more painful.
<onnadi3> lemmy: I meant, what did your statement mean? Am I going to be importing any org.osgi stuff?
<onnadi3> Right now my plugin just depends on Eclipse
<lemmy> onnadi3: org.eclipse.core.runtime
<lemmy> You're importing org.osgi indirectly already.
<rcjsuen> does it depend on runtime?
<rcjsuen> i mean using extensions
<lemmy> AFAIK it does.
<onnadi3> Uh...yeah. It uses extension points
<lemmy> Platform.getExtensionRegistry()
<rcjsuen> don't have to do that
<rcjsuen> can use services
<lemmy> That's my point
<rcjsuen> i mean
<rcjsuen> don't have to depend on runtime
<rcjsuen> can get extension registry without using Platform
<lemmy> though services are kind of unusual for high level plug-ins like JDT.
<rcjsuen> yeah
<lemmy> I guess it all depends on how much we are willing to go into the direction of provisioning.
<onnadi3> Whew. I'm a little confused here. lemmy: does the "Developing Eclipse plug-ins" book talk about the difference between the two? I have a copy arriving from Amazon
<lemmy> Going down that road doesn't mean we will loose JDT or CDT. It only makes it slightly harder.
<lemmy> onnadi3: I don't know the TOC out of my head. Maybe it doesn't but there is enough of good org.osgi.services doc out there.
<lemmy> http://www.eclipsezone.com/articles/extensions-vs-services/
<lemmy> The amount of reading material must be frightening. :o
<onnadi3> Oh! Oh!! I get it. Eclipse uses OSGi
<lemmy> :)
<onnadi3> It all makes sense!!
<onnadi3> But wait! Why should we use org.osgi?
<onnadi3> Is it just for org.eclipse.discovery.jdt?
<lemmy> org.eclipse.discovery should have minimal dependencies, which means ideally it would depend only on org.osgi.
<onnadi3> Gotcha
<ijuma> when I read that article a while ago, it seemed to me that osgi services on their own are a bit of a pain. DS makes them nicer, but with the possibility of spring-osgi becoming part of the standard there's a bit of uncertainty
<lemmy> org.eclipse.discovery.jdt acts as the connector between the "high level" JDT (org.eclipse...) and the low level org.osgi.
<onnadi3> Hmm, so on a previous point, that means that I can use enums and iterators in my code as long as all the classes involved can be found in CD1.0, right?
<lemmy> ijuma: haven't used DS yet. My main concern with Extension points is, that they don't have versions and that a plug-in defining an extension points is a singleton.
<ijuma> right
<lemmy> who needs 1.5 enums anyway? just syntactical sugar.
<lemmy> And I'm definitely not talking about "public static final int..." This topic is my EE. ;)
<onnadi3> Well, I don't use them personally, but what I meant to ask is, the syntactical sugar is just that, right? I could use it or not even with J9, right?
<lemmy> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_compilation_env.htm
<lemmy> CDC-1.0/Foundation-1.0 source: 1.3 target: 1.1
<onnadi3> I get it now. So I can use all syntax up to 1.3. Good
28 May 2007
Conversation b/w lemmy and LeNettoyeur on some architectural issues.
<LeNettoyeur> well it seems that you went of a path where plugins like JDT, CDT, etc would have to be modified <lemmy> true <lemmy> Actually I would prefer not to change existing code but I don't see a way to avoid it. <LeNettoyeur> I believe that the auto conf plug-in should provide a headless discovery facilities <lemmy> I totally agree with headless <LeNettoyeur> this plug-in would then have extension, contributed by jdt and the others <LeNettoyeur> and these jdt.autoconf would know which value to set into jdt prefs (or whatever other mechanism) <LeNettoyeur> so you end up with 3 plugins. <LeNettoyeur> org.eclipse.autoconf provides basic infrastructure for discovery and has an extension point <LeNettoyeur> org.eclipse.jdt... stays unchanged <LeNettoyeur> org.eclipse.jdt.autoconf (depends on org.eclipse.autoconf) registers an extension to the autoconf extension point to describe the rules. The execution of an autoconf query returns values that are then being injected into the proper prefs <LeNettoyeur> This last plugin may have an optional dependency on UI to contribute a pref page. <lemmy> If the consumer obtains information via some other API call, we would miss it. <LeNettoyeur> if they are stored in a pref, the jdt.autonf should store it there, if it is from a config file somewhere else, it should be in it <lemmy> in the long run however, I see the ownership of jdt.autoconf at the jdt. <LeNettoyeur> I Agree and this is why I think you can rely on prefs and other internal formats of JDT <lemmy> the only problem i see is, if jdt.autoconf doesn't get accepted by JDT. but it's still better than having a bunch of patches. <LeNettoyeur> Another scary thing "rediscover the JREs whenever a project is being created"... This is scary because if you browse the file system everytime. <lemmy> rediscovery is indeed something that should only be done on demand. we are aware of the problem that it might require a lot of resources. <LeNettoyeur> If you look at mylar that's how it works. Reach into the guts of controls... it does not use APIs. <lemmy> another thing we're currently thinking about is if we go and try to validate our findings. it definitely raises security concerns. <lemmy> Suppose someone want's us to discover javac. We might find a binary called javac. But do you really want to execute it with something like "javac -version". <LeNettoyeur> This decision should be left to the user <LeNettoyeur> and the rules should be splitted such that there is a purely static discovery where no discovered code is ran <LeNettoyeur> and another part which is more "validation" of the discovered pieces <lemmy> either that or some kind of verification that doesn't come with a security problem. something like a checksum for a given bin might work, but probably adds to much of maintenance. <lemmy> yep, validation is something optional. <LeNettoyeur> I see checksum as just another way to discover <lemmy> good point <LeNettoyeur> and if it is the way that one has decided to identify its thing then that's it <lemmy> which is definitely a good example why discovery shouldn't happen each time a project gets created. <lemmy> nobody know how expensive those rules can get. <lemmy> very valuable input, thx. :)
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 ;-)
15 May 2007
Gmail chat
10:41 AM markus: Hi me: Hello, Markus Howdy? markus: How are you? me: I'm fine, thank you You still in India, I see 10:42 AM markus: Yep, I am, but only for another month. 10:43 AM Beginning with June it will be easier to schedule meetings. me: Excellent 10:44 AM markus: I'll log this session so Remy gets to know what we decided. me: Alrighty So, the main things I wanted to know were 10:45 AM 1) Shall we stick to the scope of the project as somewhat defined on the wiki? and 2) Where can I find good free Eclipse learning material? 10:46 AM markus: Remy brought up the idea to prefer CDT use cases since those fall into the area where we get the most questions in newsgroups and irc. 10:47 AM me: Ah. Good choice 10:48 AM markus: But once you got discovery in the local file system working, discovery of jdk or php shouldn only be a matter of adding just another "rule". -n me: Yup 10:49 AM BTW, for CDT we'd need to discover things like the compiler, Make, maybe subversion or CVS etc.? markus: GCC, any other compiler... 10:50 AM With GCC being the test case? me: test case? Do you mean starting point? markus: Basically it comes down to discovering a binary in the local fs and making sure it's the right one. me: Yeah 10:51 AM markus: by generically specifying discovery heuristics. 10:52 AM Do you have an idea on how to verify that it's indeed the correct binary? Just calling the bin might be dangerous. 10:53 AM me: That's a good point. Hadn't thought about malicious bins markus: Might also be slightly expensive to call several binaries. me: I'm thinking... :) What do you mean expensive? 10:54 AM markus: performance 10:55 AM something like "aBinary --version" shouldn't be too expensive but we can't be sure of the side effects. On the other hand using something like a checksum might be too strict and I don't know of a fuzzy checksum. ;o 10:56 AM me: 1 possibility, which isn't very flexible, would be to rely on the registry or environment variables But of course sometimes, the program isn't registered 10:57 AM markus: This would require the user to setup the environment or the tool to register appropriately. But the environment, registry,... could still be used to gather knowledge about the system. 10:58 AM me: I understand the danger of calling random binaries but perhaps its not so much of a problem since other programs out there do it all time when they "auto-detect" the location of your JDK or some other program 11:00 AM markus: Well, lets leave the verification open for the moment but lets not forget about it either. 11:01 AM me: Yeah. That was a very good point you brought up 11:02 AM markus: In regards of free documentation for eclipse eclipse.org/articles wiki.eclipse.org help system eclipsezone news.eclipse.org 11:03 AM I found http://www.amazon.com/Eclipse-Building-Commercial-Quality-Plug-ins-2nd/dp/032142672X/ref=sr_1_1/102-0371229-4118559?ie=UTF8&s=books&qid=1179241370&sr=8-1 to be very helpful too. You might find it in a library. Otherwise those $43 are worth it. 11:04 AM me: ah. I'll check out the articles first and then probably pick up the book too. Someone else blogged about using that same book 11:05 AM markus: I think it's the most comprehensive book on plug-in development. Though with 3.3 it is slightly outdated, but not much. 11:06 AM me: okey-doke markus: Have you thought about a way to describe the heuristics? 11:07 AM me: I've been reading about Drools and it seems like it might save me from having to invent a mini-language for heuristics 11:08 AM markus: Great you picked the idea up. :) me: :) yup It sounded like you'd worked on it a bit 11:09 AM howdja get into it? markus: I read a thesis about rules engines and drools in particular. And I can contact the author if necessary. 11:10 AM me: oh wow. What was the thesis about? markus: using rules engines for implementing business logic in applications. unfortunately its written in german. 11:11 AM me: ah... I gotta hurry up on them Lektions :) 11:12 AM markus: Next Saturday you won't be in town? But the one thereafter?! 11:13 AM me: Yeah Actually... I think I'll have access to internet where I'm going (I'll be at a graduation which is onthe Monday after) 11:14 AM markus: But it isn't your graduation, is it? me: Oh no no no markus: otherwise you might face problems with payment. ;) 11:16 AM me: <sigh> I'd love to meet then but I won't even know where I might end up that Saturday (since Friday will be a big party for all the graduates and their friends) (and I might not be sober by then :) ) markus: I guess i understand. ;) 11:17 AM me: So for now, I guess the project can be condensed to: An implementation of a rule engine for detectin binaries on an FS ? *detecting 11:18 AM markus: With the detection part being as generic as possible so it won't be hard to extend it beyond the local fs. me: yup 11:19 AM markus: So more like: A framework based on a rules engine to detect "services" with an exemplary local fs implementation. 11:20 AM me: Ah yes. I like that :) markus: Btw any news in regards to the paperwork? me: No. I sent mine in yesterday, though 11:21 AM markus: The Google or the Eclipse ones? me: Could you please tell me where I can find the buttons that say whether they've been received? oh ah. um the google ones 11:22 AM markus: Tbh I don't know of any button. You might want to ask other students either on #eclipse-soc, soc-dev@eclipse.org or the official google ml. Might be best to sent a question to soc-dev. Other might search for the same button. ;) 11:23 AM me: True true. Although the topic was beaten to death a few weeks ago...while I wasn't looking for the button And so I didn't join it then I'm gonna be so hated :) Anyway... 11:24 AM markus: I haven't seen anything on this topic on the soc-dev ml. %) me: oh. Sorry, I meant the Google ml You're right. I'm hitting up soc-dev BTW, should I put our chat logs on on the wiki? 11:25 AM markus: IRC or this one? IIRC for IRC the group agreed on not putting the up. 11:26 AM them me: Well, the IRC...and all the "official" meetings I thought it'd be nice to have em all in one place fore reference markus: Currently there is some discussion ongoing on how we wanna "monitor" the projects. 11:27 AM Either inside the wiki, the mailinglist or with bugs in bugzilla. Or even blog posts. me: About that, isn't monitoring projects via bugs kind of an abuse of the system? 11:28 AM I mean, isn't bugzilla meant for bugs? just wondering markus: The eclipse development process makes heavy use of bugzilla for all kind of issues so I don't think it would be a problem. chatlogs could go in as attachments. 11:29 AM me: OK So I guess the answer is to wait until y'all decide the means we should use to track our discussions, eh? 11:30 AM markus: I guess so me: 'key-doke 11:31 AM One last question: How do you manage to be so enthusiastic about Eclipse all the time? Whenever I talk to you or Remy, I just get all fired up with Eclipse-coding-passion 11:32 AM markus: Well, I spent nearly all day working with Eclipse. In the evening I'm not that enthusiastic anymore. ;) But working here in India is more exhausting than back home.
21 April 2007
*** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc *** 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 *** Topic set by pombreda [Sun Apr 15 18:10:57 2007] *** onnadi3 faern arhan pombred1 benny`patchslut rcjsuen kynes soulreaper lemmy Pookzilla zx KOS-MOS ijuma *** Channel created on Sun Nov 26 00:42:43 2006 <onnadi3> rcjsuen, lemmy: sorry, people. I'd been waiting in #eclipse_soc ... <rcjsuen> onnadi3: oh, sorry I was not clear <lemmy> Hi Ogehi <lemmy> +c <onnadi3> Hello, Markus <onnadi3> rcjsuen: nah, its my fault. I've been here before :-) <onnadi3> What's been happening in SoC, today? <lemmy> do we have a log? <onnadi3> Ach, I'm using a web client that doesn't support logging... <onnadi3> Can you log? <lemmy> yep, i'll log our conversations. <onnadi3> Good. Thanks <onnadi3> rcjsuen, lemmy: Shall we get down to business? <lemmy> later i'll try to setup logging which redirects to html. <lemmy> onnadi3: sure :) <rcjsuen> Yes, I'm here. <onnadi3> Excellent! <lemmy> remy: you got my email with the proposed agenda? <onnadi3> Yup. <rcjsuen> lemmy: yeah <onnadi3> Quick question before we start: does Eclipse have a "find in files" function? <rcjsuen> in my INBOX <rcjsuen> too <lemmy> ok, wasn't sure if it got caught in the spam filter again. %) <rcjsuen> onnadi3: if you use the search it'll search all open projects, dunno about specifying specific files <rcjsuen> lemmy: wel-, i am sure everyone is busy (except me), let's get started? <onnadi3> rcjsuen: alrighty. Thanks <onnadi3> Sure, let's start <lemmy> do we consider the channel log our meetings minutes? <onnadi3> Sounds fine <rcjsuen> fine by me <lemmy> has either of you anything to add to the agenda? <onnadi3> Nope <rcjsuen> seems ok <rcjsuen> if something comes up i will say something <lemmy> ok, so lets get started with "project documentation". <lemmy> i guess the wiki is a good place to keep general text. <lemmy> but what about diagrams and such, do we wanna use UML? do we need it? <lemmy> Ogechi: are you familiar with UML? <rcjsuen> I've never used UML outside of school, so I am fine if we don't use it <rcjsuen> and that was for like...one term <onnadi3> lemmy: I know of it but haven't used it. It'll be useful if we get're building a boatload of classes <onnadi3> lemmy: I think we should start with prose first and get into UML as the need arises <lemmy> fine with me, lets try to limit the new things in this project. <lemmy> s/things/technology <rcjsuen> lemmy: agreed <onnadi3> agreed <lemmy> so for the project we will work with written text. <onnadi3> For documentation, we'll basically need inline comments, and perhaps a "how to hack" document, right? <onnadi3> lemmy: yup <rcjsuen> yes, the atter is extremey important <rcjsuen> there goes my keys again <lemmy> what do you guys understand under a "how to hack"? <rcjsuen> for there to be users, you need to have a good howto guide <rcjsuen> because we are a-- -azy and woud rather not try to figure out how to use a too- <onnadi3> "how-to-hack: A doc describing how a program was built to aid other developers in modifying it later" <onnadi3> rcjsuen: been typing too long? ;-) <rcjsuen> onnadi3: maybe, dunno, oh wel- <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. <lemmy> i guess this tool isn't targetted on end users, hence an isv might be appropriate. <rcjsuen> true <onnadi3> what is an ISV? <rcjsuen> embedded in ec-ipse -ike what p-atform does? <rcjsuen> something software vendor i think it is <rcjsuen> independent maybe <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 <onnadi3> not in WEB, of course <lemmy> maybe we should divide it. we need documentation for people working with the code base and also for people using the codebase. <lemmy> for the latter the typical eclipse documentation for extensionpoints... would probably be the best. for the former i would choose uml. ;p <onnadi3> lemmy: by, people using the codebase, do you mean end-users? <lemmy> onnadi3: yep <lemmy> but i suppose such end-users would be developer too. <lemmy> +s <onnadi3> Yeah, so the "how to hack" will be targetted to developers, and the end-user docs can ba called the user manual <lemmy> makes sense to me <onnadi3> (good point about needing separte docs) <lemmy> anything to add in regards to doc? <rcjsuen> newp <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> 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> onnadi3: is this your first eclipse plug-in you write? <onnadi3> ahem...yeah <onnadi3> :-) <lemmy> no problem :) <rcjsuen> no worries, a lot of ppl last year never wrote a plug-in <lemmy> onnadi3: do you have eclipse open atm? <onnadi3> I'm opening it right now <lemmy> ok, i'll grab a new cup of coffee. <rcjsuen> That means he hasnt gone over to the dark side yet. <onnadi3> oh boy... :-) <lemmy> with the dark side being? <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? <rcjsuen> if you have eclipse open all the time even when you don't really need it <onnadi3> (Eclipse is up!) <lemmy> for me the general plan is enough atm. <onnadi3> okey-dokey <rcjsuen> as the project (and its scope) is defined (and refined), the details will hash themselves out I think <lemmy> i just want to make sure, we agree on the same thing. :) <onnadi3> rcjsuen: glad to see the fire of your Eclipse youth is not out ;) <onnadi3> lemmy: alrighty <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> certainly not that big though <onnadi3> Ah. I see and understand <onnadi3> That's some pretty documentation <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> 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> "source plugin"? <rcjsuen> onnadi3: something that includes the java source code of the binary jar that you distribute <rcjsuen> lemmy: yes good question <onnadi3> Hell yeah, I'd continue. This is my first shot at real fame und fortune :) <rcjsuen> onnadi3: many students from the previous year, if you wi-- move on as we--, that is not an issue <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> though it is desirable. <onnadi3> Very desirable. You never know when I might get run over by a bus <lemmy> lets hope not at all. ;o <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? <lemmy> you mean something written in tex? i must confess, i don't know the tex documentation. <onnadi3> Oh no no. I mean, the documentation of TeX <lemmy> s/must/have to <onnadi3> http://tex.loria.fr/tex-source/tex-source.html <onnadi3> You'll need a dvi previewer to view it <onnadi3> Basically, I'm just thinking of documentation as detailed as that so that someone can easily understand the source <rcjsuen> if you can go a-- out, that wou-d be great <lemmy> i like detailed. ;) <onnadi3> Deal <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> what i usually miss the most in terms of project documentation, is the big picture and the major design. <rcjsuen> onnadi3: i think so <lemmy> i don't need a class that contains more javadoc than code. <lemmy> yep, enough for the documentation. ;) <lemmy> s/for the/with <lemmy> the next topic i'd like to see going into the project doc. ;) <lemmy> "Define some terms/Narrow down or extend the scope" <lemmy> i think we should try to come up with a clear understanding of what a service can and cannot be. <lemmy> this will most certainly influence the scope of the project. <lemmy> i could imagine using the wiki page (where i already created a section for it) ;) <lemmy> what is a service? what identifies a service... <lemmy> is the term service even approriate... <rcjsuen> maybe not <lemmy> the current use cases lead to something that i won't really call a service. <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> lemmy: you want jdk autodetection, i don't think one woud really call a java runtime a esrvice <rcjsuen> service is something i shou-d be ab-e to restart through /etc/init.d <rcjsuen> and whatever that thing in Win32 is <lemmy> rcjsuen: or via the osgi console ;) <lemmy> maybe we should do the use cases before we define the term? <onnadi3> lemmy: perhaps. May we start with some from the proposal? <lemmy> sure :) <rcjsuen> markus: good idea <onnadi3> BTW, rcjsuen, do you have access to a copy of the proposal? <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> markus: yes <onnadi3> Well, one case is like lemmy said, JDK, or gcc, or PERL detection <rcjsuen> lemmy: you need to change your name to start with a key that i dont -ose ha-fway <onnadi3> :-) <lemmy> rcjsuen: maybe you should get yourself a new keyboard instead. ;) <rcjsuen> it sounds -ike we are detecting binaries <rcjsuen> nuh-uh! :( <onnadi3> Well, the logic for detecting binaries is exactly the same needed to find a Webserver on port 80 <onnadi3> (well, kinna the same) <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? <onnadi3> lemmy: Could you please point me to the page you created? <lemmy> until then i think we should postpone the remaining technical agenda items. <lemmy> http://wiki.eclipse.org/index.php/An_auto-configuration_plugin_for_Eclipse <onnadi3> Alrighty! So, on to the organizational items, eh? <lemmy> rcjsuen: btw. i'll ask phillipe to grant you mentor rights in code.google.com. <lemmy> onnadi3: unless you have something technical to add. :) <onnadi3> lemmy: BTW, thanks for putting that page up <onnadi3> lemmy: nope, I'm ready to get orgnanized :) <lemmy> nah, don't mention it. that's what i'm here for. <lemmy> ok, "weekly status meetings". <lemmy> however, normally i prefer daily standup meetings, but this seems to be a problem timezone-wise. <lemmy> at least for me. you two live in the same tz. <onnadi3> oh we do? <onnadi3> rcjsuen: where are you? <onnadi3> *where do you live? <rcjsuen> onnadi3: canada <onnadi3> excellent <lemmy> onnadi3: and he's normally on irc 24/7 ;) <onnadi3> hehehe <onnadi3> I think we should have one weekly meeting, any weekday except Friday <lemmy> for the moment i'd suggest to use this timeslot for our weekly meetings?! <onnadi3> ahh... <lemmy> is it too early= <lemmy> ? <rcjsuen> ten am is fine with me <onnadi3> Could we push it back an hour or so. This waking up on a Saturday thing... :-D <rcjsuen> considering i wake up before seven sometimes <rcjsuen> yes, i just said i wake up before seven sometimes <onnadi3> Even in the summer?? <rcjsuen> yes <rcjsuen> rather, even on the weekends <onnadi3> <cringes> you're strong :) <lemmy> maybe we can move it to sunday then? <rcjsuen> sunday is sti-- a weekend ;p <lemmy> the nightclubs in india close around 1:30 <onnadi3> hahahahahhaa <lemmy> then i'm fine with 11:00am EST/8:30pm IST. <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