Skip to main content
Jump to: navigation, search

Difference between revisions of "Auto-conf meeting logs"

(16 June 2007)
(August 19 2007)
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
===18 June 2007===
+
The final meeting.
This is a discussion I had with Scott Lewis (slewis2) on org.eclipse.ecf.discovery in general, and its overlap with our org.eclipse.iscovery. Bottom line: it overlaps quite a bit and we should consider implementing its interfaces.
+
  
<pre>
+
===August 19 2007===
<rcjsuen> Oge could you discuss with Scott?
+
The final meeting.
<onnadi3> Sure thing
+
<onnadi3> slewis2: I'm trying to understand how
+
  ecf.discovery works. Could you please tell me if my
+
  understanding is correct?
+
<slewis2> have you taken a look at test code?
+
<onnadi3> The one included with jmdns?
+
<slewis2> no...in plugin org.eclipse.ecf.tests.discover
+
  y
+
<slewis2> in tests module of repo
+
<onnadi3> I don't think so
+
<onnadi3> Gimme a minute :-)
+
<slewis2> ok...we can chat too...proceed
+
<onnadi3> It seems like a service provider e.g. a Web
+
  server communicates its presence by generating an
+
  IServiceEvent
+
<onnadi3> Other bundles that require the Web server,
+
  register as IServiceTypeListeners
+
<onnadi3> Once they get the event, tehy can extract
+
  the IServiceInfo and find out thte port and
+
  inetaddress of said server
+
<onnadi3> Is that how ecf.discovery works?
+
<slewis2> essentially that's right...although the
+
  generating of an IServiceEvent is done implicitly
+
  via registerService()
+
<slewis2> RE: receiving the event and IServiceInfo...ye
+
  s...if the port and inetaddress is what's
+
  needed...typically there will be more/other
+
  service-specific info...as properties
+
<onnadi3> what class contains registerService()?
+
<slewis2> you mean impl?
+
<slewis2> (or interface)?
+
<onnadi3> Well, I'm not sure. How are services
+
  registered?
+
<slewis2> the IDiscoveryContainerAdapter has the
+
  interface (discovery API)
+
<slewis2> services are registered via IDiscoveryContain
+
  erAdapter.registerService(IServiceInfo serviceInfo)
+
<slewis2> the jmdns implementation of the IDiscoveryCon
+
  tainerAdapter is in org.eclipse.ecf.provider.discover
+
  y plugin, o.e.e.p.discovery.container.JMDNSDiscoveryC
+
  ontainer class
+
<onnadi3> Sorry, I'm just trying to locate the class
+
<slewis2> np...which one?
+
<slewis2> I can find URLs to src if you like
+
<onnadi3> I'm looking for org.eclipse.ecf.provider.disc
+
  overy.container.JMDNSDiscoveryContainer
+
<onnadi3> A URL would be great, thanks
+
<slewis2> http://dev.eclipse.org/viewcvs/index.cgi/org.
+
  eclipse.ecf/plugins/org.eclipse.ecf.provider.jmdns/sr
+
  c/org/eclipse/ecf/provider/jmdns/container/?root=Tech
+
  nology_Project
+
<onnadi3> Ok. So in the case of a hypothetical Web
+
  server, what would it register its service to?
+
<slewis2> It would a) create an appropriate instance
+
  of IServiceInfo, then call IDiscoveryContainerAdapter
+
  .registerService(svcInfo)
+
<slewis2> then listeners would/will be asynchronously
+
  notified
+
<slewis2> the conventions on type names are different
+
  for different providers (e.g. jmdns has _http._tcp
+
  for example) but the API leaves the service type as
+
  typeless (String) so other providers can use other
+
  conventions
+
<slewis2> and even zeroconf's is just convention
+
<onnadi3> Hmm, so if this Web server didn't exist on
+
  the local machine, I would write a plugin that
+
  polled the server every so often and then registered
+
  or unregistered the WebServerServiceInfo as
+
  necessary, right?
+
<slewis2> you could do that...if you wanted to act as
+
  a discovery 'proxy' for the web server...but it
+
  would be better to just add service registration to
+
  the web server
+
<slewis2> if you can, obviously
+
<onnadi3> Alright! I think I see it now. ecf.discovery
+
  is kinna like a 'protocol' that servers and clients
+
  can use to keep aware of each other
+
<slewis2> it's not a real protocol in the traditional
+
  sense, as there's nothing implied about what goes on
+
  wire between processes, but it is a high-level API
+
  for processes to keep aware of each other...note
+
  there's nothing inherently asymmetric ('server' or
+
  'client') about it...any process can use as 'server'
+
  or 'client'
+
<slewis2> API implies asynch notification between
+
  processes, at level of 'service type'
+
<onnadi3> Excellent. I think this is what I, and
+
  rcjsuen, and lemmy are looking for
+
<onnadi3> Thank you so much for patiently explaining
+
  everything to me
+
<slewis2> great.  Note that although the current impl
+
  is based upon jmdns, that we would like other impls
+
  done...that use other protocols
+
<slewis2> and if generalizations are needed/necessary
+
  for other 'styles' of discovery then we can/will add
+
  them
+
<onnadi3> Well, we're working on the discovery of
+
  services that exist on the local machine, so I think
+
  we'll be able to implement ecf.discovery without
+
  using a protocol like SLP, jmDNS etc.
+
<slewis2> also note: there's a IDiscoveryService
+
  interface that is intended to be an OSGi service
+
<slewis2> onnadi3: so you are discovering/searching
+
  for OSGi services or other manner of service?
+
<onnadi3> Not really. More like, we're discovering
+
  binaries in the filesystem or local ports running
+
  daemons
+
<slewis2> I see
+
<onnadi3> So am I right in saying that we can
+
  implement ecf.discovery without using other
+
  protocols, or IDiscoveryService?
+
<slewis2> yeah, sure...you can create your own impl of
+
  ecf.discovery that does whatever you want
+
<onnadi3> sweet
+
<slewis2> it may be appropriate to include such a
+
  plugin in ECF (as another provider of discovery) if
+
  desired/possible
+
* michaelr has joined #eclipse-soc
+
<slewis2> but just use jmdns as an example...and look
+
  to implement IContainer and IDiscoveryContainerAdapte
+
  r
+
<slewis2> then if you like you can reuse/use the
+
  DiscoveryView in org.eclipse.ecf.discovery.ui...and
+
  your discovered services should show up there
+
<onnadi3> IContainer? I don't see it in the
+
  ecf.discovery source tree
+
<slewis2> It's in the org.eclipse.ecf plugin (core)
+
<slewis2> discovery depends upon it
+
<onnadi3> I see it
+
<slewis2> for ID interfaces, IContainer, ContainerFacto
+
  ry and some util classes
+
<slewis2> IContainer.getAdapter(IDiscoveryContainerAdap
+
  ter.class) is how you get an IDiscoveryContainerAdapt
+
  er instance (or via OSGi service)
+
<onnadi3> We'll probably be using OSGi services, so I
+
  guess we won't need to implement the IContainer
+
<slewis2> in jmdns/plugin.xml you will see that it
+
  defines a namespace and a container factory...you
+
  will probably need to do this too
+
<slewis2> ...or OSGi services...sure
+
<onnadi3> I can't find jmdns/plugin.xml in here:
+
  http://jmdns.cvs.sourceforge.net/jmdns/jmdns/
+
<slewis2> see org.eclipse.ecf.tests.discovery.Activator
+
  .start for the access to discovery as OSGi service
+
  (note that IDiscoveryService is sub-interface of
+
  IDiscoveryContainerAdapter)
+
<slewis2> yeah, it's not in jmdns project...its here...
+
<slewis2> http://dev.eclipse.org/viewcvs/index.cgi/org.
+
  eclipse.ecf/plugins/org.eclipse.ecf.provider.jmdns/?r
+
  oot=Technology_Project
+
<slewis2> we simply use jmdns as a library for jmdns
+
  impl of ecf...it has no knowledge of ECF or Eclipse
+
  concepts (ID, IContainer, adapters, etc)
+
<onnadi3> OK. I have one last question. I noticed in
+
  the IDiscoveryContainerAdapter  Javadoc, it says
+
  that gets are synchronous and  requests are
+
  asynchronous. What is the difference between get and
+
  request and what does it mean for them to be synch
+
  vs. asynch?
+
<slewis2> this is a good thing, as it makes it quite
+
  easy to take other discovery protocols and 'wrap
+
  them' with an ECF-aware bundle
+
<slewis2> requests don't block (and don't have return
+
  values)
+
<slewis2> gets do block (how long determined by
+
  timeout), and return IServiceInfo (or others)
+
</pre>
+
 
+
===16 June 2007===
+
Action items:
+
 
+
1. We should all complete the commiter registration process so we can begin moving our code to dev.eclipse.org
+
 
+
2. Look at org.eclipse.ecf.discovery to see if we can reuse their code
+
 
+
<pre>
+
<onnadi3> Good morning all
+
<lemmy> Lets time today's meeting for one hour? should be
+
  enough, shouldn't it?
+
<lemmy> Hi onnadi3
+
<onnadi3> lemmy: sure thing
+
<lemmy> btw. we could change our meeting time now that i'm
+
  back in cest.
+
<lemmy> I'm fine with the current time though, but i'd not
+
  mind moving it to a later spot so you have time for a
+
  decent breakfast?
+
<onnadi3> Eh, I'm now used to waking up freakishly early
+
  :-)
+
<lemmy> ok, so meeting time will remain as is.
+
<onnadi3> Howdy, rcjsuen
+
<rcjsuen> ogeHi
+
<lemmy> 1. soc.eclipse.org as SCM
+
<lemmy> Remy, I guess the process has been started and the
+
  foundation will contact me and Ogechi.
+
<rcjsuen> Yes
+
<onnadi3> I've been contacted. I can start filling out the
+
  paperwork after the meeting
+
<lemmy> They have contacted you already? that is fast.
+
<onnadi3> Yeah, someone called emo-records@eclipse.org
+
<rcjsuen> More like, that's scary.
+
<rcjsuen> that might be an automated email
+
<rcjsuen> lemmy: did you get anything in your
+
  dev.eclipse.or gemail?
+
<rcjsuen> Or did i fill that in wrong
+
<lemmy> remy, nothing so far
+
<rcjsuen> nope, i used dev.eclipse.org at lemmster de
+
<rcjsuen> should be okay
+
<rcjsuen> oh wel
+
<lemmy> lets wait a day for the email to come and take
+
  actions then.
+
<rcjsuen> yeah
+
<rcjsuen> weekends and all
+
<rcjsuen> give them a business day or two i guess
+
<onnadi3> Should we move to the next item?
+
<rcjsuen> yes, let's
+
<lemmy> I've changed my Bugzilla id and now I can't log
+
  into the wiki anymore.
+
<rcjsuen> i guess we're all looking at http://wiki.eclipse.
+
  org/index.php/Auto-conf_meeting_agenda ?
+
<rcjsuen> although SCM was last instead of #1
+
<onnadi3> yup, I'm looking at it
+
<lemmy> 2. Status common-collections
+
<onnadi3> Well, I eventually didn't need the MultiMap
+
  class so I did not use commons-collections
+
<lemmy> perfect :)
+
<rcjsuen> well then
+
<lemmy> why isn't it necessary anymore? some design change?
+
<onnadi3> Yeah, kinna. I originally thought that
+
  IFinder.find() would return a MultiMap of all the
+
  services it was capable of finding
+
<onnadi3> Hence it would need a MultiMap
+
<onnadi3> But then I realized that we wouldn't want *all*
+
  the services discovered if only 1 was needed
+
<onnadi3> And so the MultiMap class went out the door
+
<lemmy> 3. dynamic discovery and undiscovery of a service
+
<lemmy> a) during runtime a service might appear and
+
  disappear again. Hence we need a way to handle this
+
  scenario.
+
<lemmy> I believe this is a rather important scenario
+
  which should be covered by our design.
+
<onnadi3> Could we perhaps have a field in ServiceID that
+
  denotes when a service is 'volatile'?
+
<onnadi3> In that case, things like services at ports or
+
  sockets could be marked volatile and their discovery
+
  results wouldn't be cached
+
<lemmy> do you have an example for a non volatile service ?
+
<onnadi3> Well, binaries could be non-volatile
+
<lemmy> caching and volatile are different things.
+
<onnadi3> What I mean is that the results from discovering
+
  'volatile' services won't be cached
+
<onnadi3> But those from non-volatile will
+
<lemmy> i might make sense to cache those results too. at
+
  least it should be possible with the cache implementation
+
  .
+
<rcjsuen> some kinda switch to enable/disable i guess
+
<lemmy> and binaries might be volatile as well.
+
<lemmy> imagine a binary on a removable disk.
+
<onnadi3> Ah
+
<lemmy> i suggest to assume all services to be volatile.
+
<rcjsuen> someome might suddenly uninstall gcc!
+
<onnadi3> How does Eclipse handle the locations of  JREs?
+
<lemmy> that's an even better scenario.
+
<rcjsuen> You mean when someone uninstalls a JRE? Hm, I
+
  never thought about that.
+
<lemmy> onnadi3: i'm not sure if jdt checks for existence
+
  and handle this case gracefully.
+
<rcjsuen> I guess you want to look at the implementations
+
  of org.eclipse.jdt.launching.IVIMInstall.
+
<lemmy> but you will probably get some sort of error
+
  message. either low level or high level.
+
<onnadi3> Alrighty. I was just thinking that whatever is
+
  good enough for JDT is good enough for us :-)
+
<lemmy> we need to distinguish between two different
+
  undiscovery events. one that is actively triggered by
+
  some finder (running asynchronously in a Thread) and a
+
  simple rediscovery.
+
<lemmy> we won't have asynchronous Threads for binaries I
+
  guess, but we might have them for network services. For
+
  example jSLP works exactly like this.
+
<lemmy> This Thread would fire an undiscovery event.
+
<rcjsuen> so simple rediscovery you mean as in just
+
  invoking find() again?
+
<lemmy> which brings us to the question if consumers can
+
  register for undiscovery event.s
+
<onnadi3> What do you mean by undiscovery?
+
<lemmy> rcjsuen: excatly
+
<lemmy> undiscovery == service is gone
+
<onnadi3> Hmm, I don't think people will/should be able to
+
  register for undiscovery events since we're not
+
  guaranteeing that they even get discovery events. They
+
  have to call Discovery to find if a service is there
+
<lemmy> For most of the stuff I'm talking about you will
+
  find code in org.eclipse.ecf.discovery.
+
<lemmy> And I suggest that we all have a deeper look into
+
  it. It seems as we might be able to reuse/extend this
+
  codebase.
+
<lemmy> Basically it is a framework for discovery of
+
  remote services. But I don't see a reason why it
+
  couldn't be used for local discovery too.
+
<lemmy> Btw. Scott Lewis is the project lead for ECF and
+
  also a mentor.
+
<onnadi3> what's his IRC handle?
+
<rcjsuen> slewis2
+
<lemmy> Actually he is the one who brought me up to the
+
  idea.
+
<lemmy> It even offers some basic UI to show discovery
+
  results.
+
* rcjsuen coughs.
+
<onnadi3> cool. So we all look at ecf.discovery and decide
+
  whether or not to rearchitect our own Discovery?
+
<lemmy> ?
+
<rcjsuen> I mean, that code ain't great
+
<onnadi3> rcjsuen: :-)
+
<lemmy> rcjsuen: the ui code?
+
<rcjsuen> from what i've seen before
+
<lemmy> rcjsuen: the ui code?
+
<rcjsuen> yeah, that
+
<lemmy> OK, I don't really mind if the UI code is scrap or
+
  not. As long as the framework behind has potential. .)
+
<lemmy> :)
+
<rcjsuen> true
+
<rcjsuen> Well, I haven't looked at the discovery APIs
+
  much.
+
<rcjsuen> Not my area in ECF
+
<onnadi3> So we all look at ecf.discovery and decide
+
  whether or not to rearchitect our own Discovery?
+
<lemmy> My vision is to hook into the ECF discovery
+
  framework and focus on implementing the finders. This
+
  might even answer the question of project housing for
+
  discovery.
+
* zx|work has quit IRC (Read error: 110 (Connection timed
+
out)�)
+
<lemmy> onnadi3: Yep, we should definitely do that. Even
+
  if we later see, that we cannot use it.
+
<onnadi3> Hope we can use it. Less work for all of us
+
<rcjsuen> Quite so.
+
<lemmy> Do we want to have another meeting in two/three
+
  days to discuss our findings?
+
<onnadi3> Sure
+
<rcjsuen> Lemme check my Lotus Notes calendar. >_>
+
<lemmy> Monday 7pm CEST/1pm EDT
+
<lemmy> ?
+
<rcjsuen> I might have a team meeting then, dunno what our
+
  MBA student wants.
+
<lemmy> we could do it an hour later or two.
+
<lemmy> You're free at that time?
+
<rcjsuen> These meetings take a while
+
<lemmy> a while as in the whole day?
+
<rcjsuen> what time frame are you two free in
+
* zx|work has joined #eclipse-soc
+
<onnadi3> All week except Tuesday 10 - 11
+
<lemmy> usually I work until 6pm. I could do it directly
+
  from work so we could start an hour earlier.
+
<rcjsuen> I don't know when he's gnona schedule it
+
<rcjsuen> is the issue
+
<lemmy> lets discuss the meeting time Monday once you know
+
  the meeting time.
+
<rcjsuen> lemmy: if you can do 6pm that'd be great cuz
+
  then i can just do the lunch thing
+
<lemmy> should be possible.
+
<rcjsuen> I won't be in Thursday's SOC meeting btw
+
<rcjsuen> lemmy: but okay, i'll talk to him on Monday to
+
  see when we're having our stat meeting
+
<lemmy> great, anything else to talk about?
+
<onnadi3> Yup, I've got two more items
+
<lemmy> go ahead :)
+
<onnadi3> > 5. Decide on how to specify service versions.
+
<onnadi3> and 6. Should we redesign the Discovery UI (not
+
  GUI)?
+
<onnadi3> I guess No. 6 can wait until after we check out
+
  ecf.discovery
+
<lemmy> service versions is an interesting issue. I'm not
+
  sure whether ECF provides with this or not.
+
<rcjsuen> Doesn't look like ECF's Discovery APIs have a
+
  version concept in IServiceID or in IServiceInfo.
+
<rcjsuen> I guess unless it's in its properties.
+
<lemmy> Maybe we should extend the service version thingy
+
  to  a broader view of service properties
+
<onnadi3> lemmy: interesting
+
<lemmy> SLP allows to define properties per service which
+
  can be queried by an ldap style query.
+
* wizEpit has quit IRC (Read error: 104 (Connection reset
+
by peer)�)
+
<rcjsuen> Well, having properties certainly helps us scale
+
  in the event of unforseen...properties.
+
<rcjsuen> Makes it more extensible too i naway
+
<onnadi3> If we allowed arbitrary properties, then it
+
  would be up to the service consumer to know how to
+
  identify all those features in the binary/port they're
+
  looking for
+
<onnadi3> And so a project like CDT would, in addition to
+
  defining a GCCFinder, would also define a GCCIdentifier
+
  that, given a GCC binary, could tell what properties it
+
  has
+
<lemmy> i'd expect to have an interface like: discovery
+
  gimme service x with propertiy A and property B not
+
  property C
+
<lemmy> GCCIdentifier sound like an GCCValidator.
+
<lemmy> +s
+
<onnadi3> Sure :-) I guess my point is that we'd need a
+
  way of extracting the properties from the binary/port/soc
+
  ket
+
<lemmy> well, this would be the responsibility of the
+
  finder.
+
<rcjsuen> yeah
+
<onnadi3> that's right
+
* nickboldt has joined #eclipse-soc
+
<lemmy> morning nick
+
<nickboldt> hey there
+
<rcjsuen> hi nick
+
<lemmy> rcjsuen/onnadi: If you look into the examples at
+
  http://jslp.sourceforge.net/, you'll see what I mean by
+
  a query.
+
<lemmy> Also how they handle service properties.
+
<onnadi3> I looked it up on Wikipedia :-)
+
<rcjsuen> wow, very small
+
<lemmy> Btw. I'll probably spent some official work hours
+
  getting ecf.discovery running with jSLP.
+
<onnadi3> lemmy: you have or you will?
+
<lemmy> will hopefully
+
<lemmy> I mean it makes sense in the project i work in.
+
<lemmy> and my boss has already in-officially agreed to
+
  contribute the impl afterwards.
+
<lemmy> Anyway, I guess we are done?
+
<lemmy> I gotta catch a train.
+
<onnadi3> I guess so
+
<onnadi3> Bottom line, learn ecf.discovery
+
<rcjsuen> lemmy: okay, ttyl Markus
+
<lemmy> bye, have a nice day.
+
<rcjsuen> bye
+
<onnadi3> bye, lemms :-)
+
</pre>
+
 
+
=== 9 June 2007===
+
We decided to do the following:
+
 
+
- Use the Apache Commons Collection MultiMap implementation. We would need to get rid of javax.beans.* since it won't compile with CDC 1.0
+
 
+
- Make SimpleConsumer use the console, not a GUI
+
 
+
- Create an immutable class, DiscoveryResults that is the return type of IFinder.find()
+
 
+
- Maintain a list of high-level requirements of this project
+
  
 
<pre>
 
<pre>
 +
<onnadi3> Good day, lemmy, rcjsuen
 
<rcjsuen> onnadi3: Hi
 
<rcjsuen> onnadi3: Hi
<rcjsuen> onnadi3: I realized why you SimpleFinder compiles for you but not for me.
 
<onnadi3> lemmy: Good Morning. Why is that?
 
<rcjsuen> onnadi3: You are using a compiler compliance level of 5.0 or 6.0
 
<rcjsuen> The code will not compile below
 
<rcjsuen> My workspace default is 1.4 so it was using a 1.4 setting.
 
<rcjsuen> I set the project to 5.0 and it compiled.
 
<rcjsuen> See for yourself.
 
<onnadi3> OK. I remember fixing the problem somehow but I'm not sure what I did. I'm pulling up Eclipse now
 
 
<lemmy> Hi
 
<lemmy> Hi
<onnadi3> lemmy: Wie geht es Ihnen? :-)
+
<lemmy> Do we have an agenda?
<lemmy> Super
+
<onnadi3> Wwe need to figure out what I should do to round up before the submission date
<lemmy> Tomorrow I'll leave India  and travel back to Germany. :)
+
<onnadi3> Which is tomorrow, I believe
<onnadi3> Nice. You excited?
+
<lemmy> Yep, tomorrow is pencils down
<lemmy> The previous three months have been a nice experience, but I'm happy to go back.
+
<onnadi3> 1. Upload my code to code.google.com
<onnadi3> Ah. So I gues this is also the end of your crunch time, eh
+
<onnadi3> 2. Make the changes you guys suggested to the documentation
<rcjsuen> onnadi3: Did you look at your blog's replies?
+
<onnadi3> No. 3 would be post on my blog about the wonders of Discovery, but you guys haven't commented on the draft I put up
<lemmy> Yep
+
<onnadi3> Should we just skip it?
<onnadi3> just checking em now
+
<lemmy> we should stick to the plan and try to get as much pr as possible.
<onnadi3> Oops. Ouch
+
<onnadi3> okey-doke
<onnadi3> Sheesh! Why didn't I notice that??
+
<rcjsuen> yup, I agree
<onnadi3> oh well :-)
+
<lemmy> and the comment is still on my todo list.
<rcjsuen> The ol' debugger would've done it.
+
<lemmy> The third comment is the most interesting one. But I'm not sure about the JDK dependencies of common-collections.
+
<onnadi3> Well, the commons collection is the Apache Jar that I mentioned in my earlier e-mail
+
<onnadi3> You said we should avoid the licensing issues, right?
+
<rcjsuen> That was me.
+
<lemmy> Apache license is compatible. Orbit might even contain it already.
+
<rcjsuen> I just don't want to pull in a jar if I'm just using one class.
+
<onnadi3> lemmy: oops. Sorry :-)
+
<lemmy> What's on the agenda for today?
+
<lemmy> I'm a little bit in a hurry, cause I still need to pack my bags...
+
<onnadi3> Well, the only problem I'm having now is figuring out how to query Discovery for the services published to it
+
<lemmy> It appears as if commons-collection isn't in Orbit yet, but many other commons-* are.
+
<lemmy> +1 for using commons-collections if foundation 1.0 works for it.
+
<rcjsuen> yes, I don't see it in Orbit
+
<rcjsuen> It might be something odd like J2SE-1.2.
+
<onnadi3> So I'd just download the jar and import from there, right? I don't have to use org.orbit?
+
<ijuma> i'd guess 1.2 minimum too
+
<rcjsuen> I think httpclient is j2se-1.2
+
<ijuma> rcjsuen: why is 1.2 odd?
+
<lemmy> Create a new plug-in for that JAR. There is even a wizard for such a task.
+
<rcjsuen> ijuma: I didn't think people cared about j2se-1.2 ;)
+
<rcjsuen> then again, until i hopped on the eRCP bandwagon, i didn't think anyone cared about anything below j2se-1.4
+
<onnadi3> lemmy: why do I have to create a new plugin for the Commons jar?  ican just include har in my current plug-in project, can't I?
+
<ijuma> rcjsuen: well, because it's where the collections framework was introduced, it's likely that commons-collection would require that much at least
+
<ijuma> but possibly 1.4 too
+
<ijuma> i know it's not 1.5
+
<ijuma> (yet)
+
<rcjsuen> ah
+
<lemmy> onnadi3: creating a separate plug-in for a jar has the advantage, that other plug-in can reference the very same jar too.
+
<onnadi3> lemmy: Ah. That's clever.
+
<lemmy> And in this specific case, commons-collection might get included in the Orbit project. Discovery would then reference it there.
+
<onnadi3> So even though I'd include the jar in a plug-in, Discovery will still reference it as a package exported by a plugin, not as a plugin itself, right?
+
<lemmy> It's a lessons learned thing. Many many plug-ins used to include log4j. In the end this caused some headaches.
+
<ijuma> rcjsuen: but to answer your question, Spring 2.0 still works with 1.3. 2.1 has just moved to 1.4 in the last development milestone. So yeah, people in the enterprise are also _slow_ ;)
+
<rcjsuen> yeah
+
<rcjsuen> I realized a lot of ppl are still on 1.3
+
<onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via  a call to a Consumer class?
+
<lemmy> I don't see the difference in your question. Discovery depends on the collections plug-in. The collection plug-in exports a couple of packages which then can be used by Discovery.
+
<rcjsuen> I imported commons collection's source to my workspace
+
<rcjsuen> It won't work on CDC1.0 because of java.beans.*
+
<1.5
+
<rcjsuen> lemmy: yeah i told him that
+
<lemmy> OK
+
<rcjsuen> it's To Be Addressed
+
<lemmy> rcjsuen: Can you tell which part of collections requires java.beans*?
+
<rcjsuen> BeanMap
+
<rcjsuen> if I delete it it's okay
+
<lemmy> If that is the only reason, we could modify the JAR and file an enhancement request at apache.org
+
<rcjsuen> The binary apepars to be 571,259 bytes.
+
<rcjsuen> This will likely not fly in an embedded context.
+
<lemmy> Size doesn't matter. ;)
+
 
<onnadi3> :-)
 
<onnadi3> :-)
<lemmy> rcjsuen: Should be easy to optimize size-wise for the embedded use case.
+
<rcjsuen> onnadi3: I left a one sentence comment like 10 minutes ago
<rcjsuen> well, just saying, Equinox won't like this
+
<onnadi3> Hmm, perhaps bugzilla was still down, then
<lemmy> In general I prefer to reuse existing code over implementing from scratch.
+
<rcjsuen> It was synchronizing this mornign.
<lemmy> Fight NIH. :)
+
<lemmy> 1. Upload my code to code.google.com. Is there anything to arrange for?  
<rcjsuen> NIH?
+
<onnadi3> Not really. They just want to see what you've done all summer.
<lemmy> Not Invented Here
+
<onnadi3> rcjsuen: I don't see any need to mention SoC. It was just a vehicle for achieving our ends :-)
<rcjsuen> o
+
<benny`work> onnadi3, do you know where to upload the stuff? can't find anything about where to do it
<rcjsuen> well, let's address onnadi3's question
+
<onnadi3> benny`work: This article explains everything http://groups.google.com/group/google-summer-of-code-announce/web/midterm-survey-information-2
<onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via  a call to a Consumer class?
+
<benny`work> onnadi3, thanks
<lemmy> Yep
+
<onnadi3> lemmy, rcjsuen: Anything else you'd like me to do before pencils down?
<onnadi3> Yay!
+
<rcjsuen> Don't think so.
<lemmy> So you're asking how the interface might look like?
+
<rcjsuen> maybe generate API docs but I don't know where to host that
<rcjsuen> I think he's asking about how consumer plug-in accesses discovery plug-in.
+
<onnadi3> cool
<onnadi3> Well, no. The interface is simply a menu item that you click and it should display a popup that lists all the found srevices so far
+
<kynes> pombreda, ping
<onnadi3> rcjsuen: Yup!
+
<onnadi3> Well, I think that's all that's on the agenda
<lemmy> onnadi3: Why do you "waste" time implementing a UI?
+
<onnadi3> IS there any need for us to meet tomorrow?
<onnadi3> It took 0 time. It was what was produced by the Eclipse Wizard
+
<rcjsuen> I don't think so.
<lemmy> Testing is much better done with JUnit.
+
<onnadi3> Alrighty. I'll shoot y'all an e-mail when I've uploaded everything
<onnadi3> lemmy: Well, I wanted to complete the example
+
Aug 19 13:45:58  onnadi3 is sad that it's all over
<lemmy> Btw. I'm missing JUnit test cases in general.
+
<rcjsuen> onnadi3: Thank you for all your hard work.
<onnadi3> Since I've written a SimpleFinder, I also want a SimpleConsumer
+
<onnadi3> rcjsuen: Thank *you* for lurking on IRC all the time and answering all questions :-)
<lemmy> I'd suggest to design the consumer as a JUnit plug-in project.
+
<rcjsuen> Just trying to pay back to the Eclipse community ;)
<onnadi3> The only thing I think I can test right now is the MultiMap class (which will going soon anyway). The rest of the code is boilerplate which I don't hinkw we agreed on how to test it
+
<rcjsuen> onnadi3: I see you approached the occasional straggler also, thanks
<lemmy> Where is the implementation for MultiMap?
+
<onnadi3> Does a JUnit plugin project mean simply a blank project with JUnit testcases in it?
+
<onnadi3> Sorry, the MultiMap code is not in the repo yet because I couldn't get th test for it to work
+
<onnadi3> I guess I should put all compiled code in the repo, huh...
+
<rcjsuen> My boss was just telling us to commit our project's code yesterday ;)
+
<rcjsuen> I sidestepped by saying he just told us the package name to use today (which was different from what I was using) so I had to refactor and test properly ;p
+
 
<onnadi3> :-)
 
<onnadi3> :-)
<lemmy> Might be that I'm not used to CVS anymore, but I'm fine with compiling but untested code in the repo.
+
<onnadi3> Well, I better finish rounding up my SoC. Markus, Remy, I'll talk to you all later
<lemmy> Simply to make sure the code is in a safe place.
+
<lemmy> ttyl
<onnadi3> Alrighty. Sorry about that. I'll have it up today
+
<rcjsuen> just commit whenever you make a little change
+
<rcjsuen> will save you time when you screw things up
+
<onnadi3> Gotcha. And then i can actually discuss it with people
+
<rcjsuen> I can speak from experience.
+
<rcjsuen> onnadi3: yes, just create a org.eclipse.discovery.tests plug-in project
+
<rcjsuen> then put your test cases there
+
<rcjsuen> maybe some "fake code" if necessary
+
<lemmy> I'm just picky, but in IFinder it reads "find() heuristically locates...". Why include "heuristically" in the interface at all? Seems more like an implementation detail to me. :)
+
<onnadi3> Alrighty!
+
<onnadi3> lemmy: good point on that
+
<onnadi3> I'd still like to have an examples package where I can show how a consumer would utilize discovery to get services from a Finder
+
<rcjsuen> yes, working examples are critical
+
<lemmy> Even though I agree on the necessity for examples, I still think UI is a waste. Somebody wanting to use discovery will not care about the UI part. It will even make the example harder to understand.
+
<rcjsuen> well, the sample unit test should be exemplary enough in that context
+
Jun 09 10:16:19 * kreismeister (n=Miranda@p57AB7ABB.dip.t-dialin.net) has joined #eclipse-soc
+
<onnadi3> lemmy: Well, I kinna thought that a real world Consumer would have a UI
+
<rcjsuen> yes, but anyone that's going to use your plug-in already knows how to write a UI
+
<onnadi3> And also, I wasn't sure how to control a plug-in from the console
+
<lemmy> onnadi3: They probably will, but they want to learn how to use Discovery and not how to wire it up to the UI layer. :)
+
<lemmy> onnadi3: Run Eclipse/OSGi with "-console". "help" will then show you what you can do.
+
<rcjsuen> lemmy: for the issue of accessing the services
+
<onnadi3> Alrighty
+
<rcjsuen> lemmy: you're more familiar with OSGi services
+
<lemmy> Which issues? I must have missed them. :o
+
<onnadi3> lemmy: So, do you have any ideas for how I can get the services stored in Discovery via  a call to a Consumer class?
+
<rcjsuen> that
+
<lemmy> Does services in this context really mean OSGi services?
+
<onnadi3> oh no no no
+
<onnadi3> It means the services that Finders find
+
<rcjsuen> well then, never mind
+
<lemmy> Btw. I would find() let return something like a DiscoveryResult rather than a Map. Internally it could still use a Map though, but later you might want to add some methods to it.
+
<lemmy> ...which would be possible with a Map, but would look funny.
+
<onnadi3> okey-doke
+
<onnadi3> (BTW, you can find the MultiMap code I wrote here http://eclipse-incub.cvs.sourceforge.net/eclipse-incub/sevice-discovery/org.eclipse.discovery/src/org/eclipse/discovery/)
+
<lemmy> Also it shouldn't be possible for a consumer to modify the DiscoveryResults (Map).
+
<lemmy> Since you might return a reference to the internal discovery cache.
+
<onnadi3> Ah. An immutable structure
+
<rcjsuen> yes, immutable is good
+
<lemmy> Maps.unmodifiableMap(aMap).
+
<lemmy> IIRC
+
<lemmy> But if you use a DiscoveryResult, you don't need to expose the Map at all.
+
<onnadi3> Alright, I can do that
+
<lemmy> onnadi3: May I remind you of this "must", "should" and "nice to have" list that we agreed upon in last weeks meeting? :)
+
<lemmy> Requirements tracking is somewhat important to me.
+
<lemmy> Later we might want to create enhancement requests (bugs.eclipse.org) out of it. :)
+
<onnadi3> Yes, that's a good point. So the DiscoveryResults thing would go in the "must" box, right?
+
<lemmy> Why not. :)
+
<lemmy> Though we should also keep track of higher level requirements.
+
<lemmy> Mostly all the ideas which came up last week.
+
<onnadi3> OK
+
<onnadi3> So, somethign like this "IFinder.find() must return a class (say, DiscoveryResult) that contains a Map or whatever data structure is used internally."?
+
<lemmy> MutliMap does not compile for me and I'd move it to .internal. too.
+
<lemmy> Exactly
+
<rcjsuen> lemmy: for the requirements page?
+
<lemmy> rcjsuen: ?
+
<rcjsuen> onnadi3: is that for the requirements page?
+
<onnadi3> Yeah, e.g. http://wiki.eclipse.org/index.php/An_auto-configuration_plugin_for_Eclipse#Requirements
+
<rcjsuen> That'd be a bit too low level in my opinion. You should scratch out the "Map or whatever data structure" bits.
+
<rcjsuen> Just say it contains the results and leave it at that.
+
<lemmy> Might be the case that it doesn't need a Map later on anymore.
+
<onnadi3> rcjsuen: Hmm, but then Map would fit the requirement...
+
<lemmy> Leave the internal implementation to the code. Only document external interfaces. :)
+
<rcjsuen> yes, don't get into the implementation details if possible
+
<onnadi3> OK
+
<rcjsuen> as long as I can get the results
+
<rcjsuen> i don't care if you're using a List of Lists or not
+
<onnadi3> :-)
+
<lemmy> onnadi3: You can't add domain specific methods to a Map which you can do with a domain specific object. That's my whole point for DiscoveryResult.
+
<onnadi3> lemmy: I understand
+
<onnadi3> Now could we please go back to the issue of getting the results from Discovery. It seems tht without that final example, I won't have made any real progress
+
<lemmy> Sure
+
<lemmy> Offer an EP that returns the DiscoveryResult
+
<lemmy> Or start with a OSGi Service.
+
<onnadi3> The consumer offers an EP?
+
<lemmy> Nope, Discovery does.
+
<onnadi3> I thought EPs take classes of a certain type. Can they pblish, too?
+
<lemmy> Let me sketch it out for an OSGi service: Discovery registers an IDiscoveryService which offers a method discover(ServiceIdentifier)
+
<lemmy> A consumer would then obtain the service an call the IDiscoveryService.discover(aSpecificServiceId) method.
+
<lemmy> Since we don't have ServiceIdentifiers atm, the identifier could simple be a String for the moment.
+
<lemmy> Basically this String will be somehow mapped to the key in the Map I assume.
+
<lemmy> Reasonable so far?
+
<onnadi3> So, in the code I have, the FinderTracker would also register an IDiscoveryService ?
+
<onnadi3> Why does it have to be an interface seeing as there's only 1 Discovery?
+
<lemmy> An interface is useful because consumer plug-ins might want to include this very interface in their plug-in. If an OSGi service is optional and at runtime not present, the consumer code would break because it might access the interfaec.
+
<lemmy> If the interface is included in the consumer plug-in, it will not break with a NoClassDefFound.
+
<onnadi3> oh!!
+
<onnadi3> How long have you been coding OSGi?
+
<lemmy> Not that long. Just for a couple of month.
+
<onnadi3> Oh man...
+
<onnadi3> Alright. So Discovery has an extension pt. that accepts IDiscovyerServices
+
<onnadi3> So when Discovery is given a new extension, it changes a field in the IDiscoveryService to the results of calling discover(serviceID)
+
<lemmy> I'd suggest to skip the EP for the moment and solely use OSGi services. An EP can be designed later with the knowledge gained while working with OSGi services.
+
<lemmy> I don't get this.
+
<lemmy> Remy?
+
<onnadi3> lemmy: what don't you understand?
+
<rcjsuen> No idea.
+
<lemmy> I gotta go now. :( Can we continue Monday afternoon?
+
<onnadi3> Sure. But if you have time, please send me an email about how to get data from Discovery via a separate OSGi bundle
+
<onnadi3> I still don't understand how to do it
+
<rcjsuen> Maybe this will be helpful http://www.knopflerfish.org/osgi_service_tutorial.html
+
<rcjsuen> Was good enough for me for the most part.
+
<lemmy> Talk to you guys on Monday. :)
+
<rcjsuen> bye
+
<onnadi3> lemmy: have a safe trip
+
<lemmy> Thanks
+
 
+
 
</pre>
 
</pre>
  
===2 June 2007===
+
===August 14 ===
At this weekly meeting we tried to decide on exactly what the term "service" means, but we decided to save the discussion for a later date. We also decided on a preliminary architecture for the Discovery plug-in: Discovery will be an OSGi bundle that connects with other service finders through the OSGi services API, but connects with service consumers through Eclipse Extension Points.
+
Action items
 +
* E-mail Alex Blewitt to see if SoCers can post articles to EclipseZone about their projects
 +
* Write an article on Discovery and post it as many places as possible
 +
* Write documentation for Discovery in docbook format
 +
* Check out how Mac Eclipse does their JRE discovery
  
<pre>
+
<pre><onnadi3> I've got meeting items here http://wiki.eclipse.org/Auto-conf_meeting_agenda
<onnadi3> thanks
+
<lemmy> ok, lets get started: How to get Discovery into the Eclipse Platform
<lemmy> I'm not sure, did I send my proposed meeting agenda out?
+
<lemmy> what do you mean by that?
<onnadi3> I didn't get yours...I sent one out, though
+
<onnadi3> Well, I would like my work to be used by other projects
<lemmy> I thought that one was in response to mine.
+
<lemmy> do you mean how to make discovery part of the eclipse sdk?
<lemmy> it's out
+
<onnadi3> Yeah :-)
<onnadi3> Could you please send it again? I can't find it in mly inbox
+
<onnadi3> Is there a process for it?
<lemmy> I've sent it a minute ago
+
<lemmy> that is something we cannot enforce. we rather have to hope for adoption. surely we can promote discovery with blog posts and examples. but at the end of the day, the platform team will decide.
<onnadi3> got it
+
<onnadi3> okay
<lemmy> it overlaps with your email
+
<onnadi3> That kinna leads into the second item
<onnadi3> No problem. Yours is bigger so let's go over the technical aspects of yours, get to p. number 2 in mine, and then move on to the organizational issues
+
<lemmy> exactly. ;)
<onnadi3> So, first point: "What exactly is a "service" anyway? (Better term...)"
+
<onnadi3> zx suggested making a screencast
<lemmy> a minute... I'm in voip call currently.
+
<rcjsuen_> yeah, item 1 really goes down to PR and usability
<onnadi3> Oh...sorry
+
<lemmy> i've never done a screencast. you're talking something like a flash movie?
<lemmy> no problem
+
<onnadi3> Yeah...
<lemmy> remy: you're with us?
+
<onnadi3> Perhaps an article would suffice. Can anyone post on Eclipsezone?
* soulreaper has quit (Read error: 104 (Connection reset by peer))
+
<lemmy> at best we would have both. personally I don't like screencasts, i rather like to read normal text.
<rcjsuen> yes
+
<onnadi3> Me too
<lemmy> great
+
<lemmy> we can ask alex blewit
<lemmy> onnadi3: first point is about deciding if a service needs an identifier. for that we should know what a "service" might be
+
<lemmy> +t
<lemmy> Suppose plug-in A wants to discover a JDK and calls discovery. plug-in B wants to discover a JDK too, but how would discovery know that it can return the results from the previous run.
+
<lemmy> he is the "editor in chief".
<onnadi3> lemmy: Services can be binaries, or ports where a daemon is listening
+
<onnadi3> ah, that guy
<lemmy> that sounds pretty much like a technical description of a service.
+
<onnadi3> Does he lurk here?
<lemmy> s/that/this
+
<lemmy> what about http://www.eclipse.org/articles/ ?
<onnadi3> Hmmm, if we assume for the moment that plug-in A does not care about version, then the name of the binary can be its identifier
+
<rcjsuen_> Nope, he doesn't.
<lemmy> Will this work for a daemon running on a remote host?
+
<onnadi3> Hello Remy :-)
<lemmy> You don't have a name and only a simple port number.
+
<lemmy> we should write him an email. maybe in the name of all soc projects.
<onnadi3> Hmm, that was why I tried using URIs in my sample implementation. That way, we're not restricted to only local binaries or ports
+
<onnadi3> That'd be great
<lemmy> What about URIs and versions?
+
<onnadi3> I think  Eclipse corner will be easy enough
<onnadi3> That's a bit trickier
+
<onnadi3> Oops. "hat is, articles that contain time-sensitive material or are likely to expire in a relatively short period of time do not belong on Eclipse Corner"
<onnadi3> IIRC, GNU Autoconf somehow doesn't bother about version numbers
+
<rcjsuen_> Depends what "short" means.
<onnadi3> It only tests for features
+
<onnadi3> True, but isn't beta software the definition of time-sensitive material? :-)
<onnadi3> And that's kind of what I would like to do also since it will simplify matters a lot
+
<onnadi3> Doh. We don't need to belabor this point. We can always post on Planet Eclipse. That's got mad readership
<rcjsuen> No, autoconf can check versions
+
<rcjsuen_> yeah
<lemmy> Also if I create a JAVA5 project, I want Eclipse to suggest only >=JAVA5 JDKs
+
<rcjsuen_> you could just paste some simple code
<onnadi3> true true
+
<rcjsuen_> then include a zip
<lemmy> or foundation 1.0. ;)
+
<rcjsuen_> with the full thing
<onnadi3> :-) or that
+
<rcjsuen_> or whatever
<lemmy> Btw. foundation 1.0 makes it even more complicated because it represents a group of possible jdks.
+
<onnadi3> So I guess, the bottom line is 1) E-mail Blewitt, and 2) post to Planet Eclipse
<rcjsuen> Well, there are no URIs in F1.0 anyway.
+
<lemmy> onnadi3: are you going to write an email to alex? otherwise i can do it too.
<onnadi3> Yeah. But we can still use logical URIs
+
<onnadi3> lemmy: Well, if its going to be in the name of all of SoC then you should prob'ly do it. Otherwise I will
<onnadi3> But I guess the main problem is...how to detect version?
+
<lemmy> onnadi3: i don't think i'm a better suited represent for soc... but ok, i'll write the email.
<lemmy> detecting a version is really specific to a binary.
+
<onnadi3> Oh, you don't know him personally?
<lemmy> I'd assume it is something specified by a consumer.
+
<onnadi3> Sorry, I thought you did
<onnadi3>  Do you know how Autoconf does it? I'm rebrowsing their docs right now
+
<onnadi3> I can write it, in that case
<onnadi3> but...how would that help GNU Autoconf find the bin? I'd hope they didn't call <binary> --version
+
<lemmy> yeah, simply cc soc-dev
<rcjsuen> Well, not everything has a binary, so that wouldn't make sense.
+
<onnadi3> No problem
<onnadi3> Yeah. And i think if you ant to add a test for sthg it doesn't know about, you have to write the test yourself
+
<rcjsuen_> Don't think anyone in here really knows him that well.
<rcjsuen> Define "doesn't know about"
+
<lemmy> for agenda item #3 i suggest http://www.eclipse.org/articles/article.php?file=Article-Authoring-With-Eclipse/index.html
<onnadi3> Well, let's say configure only knew how to detect JDKs, then if you wanted it to detect GCC, you'd have to write your own test for GCC
+
<lemmy> although for a basic how to hack the wiki might be fine too.
<onnadi3> I think
+
<onnadi3> Hmm, if DocBook can publish to HTML, then I'll go with it
<rcjsuen> hm
+
<lemmy> html, pdf, ...
<lemmy> configure shouldn't know how to detect jdks. It should know how to discover a specific resource with given attributes.
+
<onnadi3> good
<lemmy> a consumer passes those attribute to configure to utilize the discover facilities.
+
<lemmy> docbook doesn't contain the layout, just the structure.
<lemmy> discovery facilities could be a registry finder, a fs finder, a port checker...
+
<rcjsuen_> DITA also does html / pdf, it can also transform to eclipsehelp, though I'm not familiar with the eclipsehelp bit
<lemmy> the consumer would know how to use these finders to find what he needs.
+
<lemmy> for docbook i've done the transformation to html and pdf lately.
<lemmy> my point about a service identifier is to have a globally valid identifier for a given service/resource.
+
<onnadi3> Alrighty. I'll start off with DocBook and switch to DITA if I hit snags
<lemmy> however there is a problem. if a second consumer tries to discover a certain resource that has already been identified and discovery would just return already known results, it might miss resources which would have been discovered because of much better heuristics by the second consumer.
+
Aug 14 15:27:22 --> jevgeni (n=def@ip50.cab81.tln.starman.ee) has joined #eclipse-soc
<onnadi3> Will it be possible to assign a unique identifier to every program?
+
<lemmy> he is hard to miss, isn't he? ;o
<lemmy> Would be great if we would already have such identifiers.
+
<lemmy> the British accent is very strong
<lemmy> Or at least a schema by which we could generate reproducible identifiers.
+
<lemmy> btw. onnadi3 have you had a look at the mac jre discovery code in 3.4m1?
<rcjsuen> lemmy: Hm, that's an interesting scenario
+
<rcjsuen_> I didn't even realize there was a 'Search' button.
<lemmy> rcjsuen: a simple and stupid solution would be a "force" flag to always rediscover even with previous results.
+
<rcjsuen_> Maybe it just looks for specific path names
<lemmy> Having identifiers also allows for consumers to not provide discovery rules. They would reuse already exiting discovery rules without shipping them.
+
<rcjsuen_> like jre/bin/
<lemmy> shipping/including...
+
<lemmy> rcjsuen_: the search button on the jre page is older. but it isn't a smart search, just recursive.
<onnadi3> So I guess the main problem now is how to incorporate version information into the "service" name in a standard way
+
<rcjsuen_> ic
<onnadi3> Most (though not all) program I know use an increasing  numerical scheme for versioning so maybe all we have to do is concat the binary's name with its versio
+
<onnadi3> From the description, it does exactly what our Discovery does
<onnadi3> Then we ca ntell if one version is greater or less than another
+
<onnadi3> Searches a location for JREs
<lemmy> Or have an identifier class with names and versions. ;)
+
<lemmy> but only on mac osx
<lemmy> However, implementation doesn't really matter, does it?
+
Aug 14 15:31:14 --> michaelr (n=no@S010600184d82fd75.cg.shawcable.net) has joined #eclipse-soc
<lemmy> yet
+
<onnadi3> true :-)
<onnadi3> Well...I was trying to make it general enough to also encompass ports (which do not have version information)
+
<lemmy> but it is definitely worth to check how they do it.
<lemmy> The port doesn't, but the service behind it. :)
+
<onnadi3> okay
<onnadi3> Wait. That's not true. There might be different versions of processes running at the same port
+
<rcjsuen_> I wonder how it works
<onnadi3> :-)
+
<rcjsuen_> maybe like if (Platform.getOS().equals(Platform.MAC)) or whatever the actual method/field names are
<lemmy> For my web project I need Tomcat 5 and not 4. :)
+
<-- Pookzilla has quit ()
<onnadi3> Hmmm, so I guess it all boils down to finding binaries
+
<onnadi3> Well, that's it for the agenda. I'm still mailing the CDT-dev folks to try and get the Make insertion working
<onnadi3> Whether hidden behind an fs, or a port
+
<onnadi3> I tried the instructions they gave, but nothing happened
<lemmy> Though we are talking pretty much about semantics of  discovery results. Might it be more reasonable to provide a broad collection of finders and the consumer provides the semantics instead?
+
<rcjsuen_> onnadi3: that's nice
<rcjsuen> I don't think that's unreasonable.
+
<onnadi3> :-)
<onnadi3> OK. So as you said earlier, discovery provides libraries for searching the fs, ports, registry etc. for whatever it is a consumer is looking for
+
<-- jevgeni has quit ("Bye!")
<lemmy> Well, those are just my thoughts. :)
+
<Ali> could you please send me a link to the sourceforge project for that? I didnt see it on teh wiki (I may have missed it though)
<onnadi3> They're good thoughts. I like the idea
+
<onnadi3> lemmy, rcjsuen_: When do I have to turn in all the code/docs/etc. in so you guys can evaluate?
<onnadi3> We just have to solve the little details now
+
<rcjsuen_> Ali: eclipse-incub is the name
<lemmy> normally the details bite us in the a**
+
<rcjsuen_> so sourceforge.net/projects/eclipse-incub
<onnadi3> We got all summer to get used to it :-)
+
<lemmy> as early as possible. continuous evaluation. ;)
<lemmy> so we will file having service identifiers as should but currently as too hard to implement and move on to the next thing?
+
<rcjsuen_> onnadi3: dunno, let's see
<lemmy> like we've done with validation.
+
<rcjsuen_> probably next Friday
<onnadi3> Well, i was thinking of defining service as sthg like "any resource that can be identified by a URI"
+
<rcjsuen_> http://code.google.com/support/bin/answer.py?answer=60325&topic=10729
<onnadi3> (implementation of URI may vary)
+
<onnadi3> Alright, as soon as possible but before Friday, it is :-)
<lemmy> I'm a little bit short on time currently, but maybe we can open a list on the wiki with "must", "should" and "nice to have" to keep track of the features?
+
<onnadi3> So our final meeting will be on Monday, the 20th, then?
<rcjsuen> Yes, probably better to move on. We don't want this meeting to on forever on this thing
+
<lemmy> do we want to have an additional meeting in between?
<onnadi3> Alrighty
+
<Ali> thanks a lot. Is there any information on what is left to be implemented, what features have ben implemented and such?
<onnadi3> Next point, "Extension Points vs. OSGi (declarative?) services"
+
<onnadi3> lemmy: If we do, I'd rather it be between friday and sunday inclusive. That way I'd have stuff for y'all to comment on
<onnadi3> Do y'all think it is worth it to write custom tools for dealing with OSGi services?
+
<Ali> I saw a comment at the bottom of the wiki regarding RSE
<lemmy> first of all, we don't need to decide "either/or". We can use both.
+
<Ali> I am glad to see things are moving forward there :-)
<onnadi3> Well, I thought the only place we need them is for connecting customer plugins with Discovery
+
<lemmy> onnadi3: so we leave the precise date open but target the weekend?
<onnadi3> And once we're using XPs, there won't be any need for OSGi services
+
<onnadi3> Sure thing
<lemmy> XPs?
+
<onnadi3> Are there any other items to discuss today?
<rcjsuen> eXtension Points
+
<lemmy> not from my side
<lemmy> What's wrong with EPs? ;)
+
<lemmy> ok, ttytomorrow
<lemmy> XP is already used by extreme programming. :)
+
<rcjsuen_> bye
<lemmy> ...in my head that is.
+
<onnadi3> alrighty. Bye :-)
<rcjsuen> lemmy: same
+
<lemmy> onnadi3: writing service doesn't really require tooling (maybe for declarative service it does though).
+
<onnadi3> Yeah. For declarative services...so you don't think we'll need dynamic discovery of system resources aka Services?
+
<lemmy> My only point is, that EPs have more dependencies whereas OSGi services are pretty low level.
+
<onnadi3> What kind of dependencies?
+
<onnadi3> (I'm not attached to EPs. I jsut want whatever is simplest)
+
<lemmy> Using services for low level API might therefore be useful. For high level EPs are a better fit.
+
<rcjsuen> onnadi3: Well, a lot more people are familiar with extension points anyway.
+
<lemmy> I'm just aiming at this provisioning angle...
+
<lemmy> In provisioning you might not have access to org.eclipse.*
+
<rcjsuen> looks like org.eclipse.equinox.common, runtime_registry_compatibility.jar, org.eclipse.equinox.registry
+
<rcjsuen> org.eclipse.osgi.services, org.eclipse.osgi
+
<lemmy> org.eclipse.osgi? That's new to me
+
<lemmy> Is it the plug-in or package name?
+
<rcjsuen> well, bundle symbolic name is org.eclipse.osgi
+
<rcjsuen> but sure there are org.osgi.* stuff and also org.eclipse.osgi.* stuff
+
<lemmy> I'd suggest to hook the finders to the base discovery via services and offer services and EPs to consumers.
+
<lemmy> This would certainly require another plug-in on top of base discovery that encapsulates EPs.
+
<lemmy> http://www.skrbl.com/44702430
+
<onnadi3> what do you mean encapsulate EPs? Wouldn't I just provide the Extension Points and then consumers can write extensions for them?
+
<lemmy> bear with my terrible first grade painting skills. :)
+
<lemmy> "EP connector" is necessary so that base can be used in a pure OSGi environment.
+
<rcjsuen> I see your point.
+
<lemmy> Maybe this is overengineering.
+
<lemmy> however foundation 1.0 already leads the path in this direction.
+
<onnadi3> lemmy: Could you please explain what provisioning does? I didn't really understand their Wiki page
+
<lemmy> I don't think their use cases have been fixed yet. :
+
<lemmy> Simplified it deals with bringing Eclipse to the customer.
+
<lemmy> Eclipse in this context doesn't mean the SDK.
+
<lemmy> But software components (== bundles == plug-ins) in general.
+
<lemmy> One of the goals of provisioning is to redo the UpdateManager.
+
<lemmy> And to get rid of "features". ;o
+
<onnadi3> So its just a reimplementation of parts of Eclipse??
+
<rcjsuen> Except something-not-named-features-but-acts-just-like-features will probably remain.
+
<lemmy> *g*
+
<onnadi3> Well, if provisioning is important enough then we might as well use OSGi services and EPs
+
<lemmy> It is up to us how important we rate them. I tend to rate fundamental facilities very high though.
+
<lemmy> But this isn't carved in stone
+
<lemmy> onnadi3: I feel like you dislike services? ;)
+
<lemmy> s/I feel/It feels
+
<onnadi3> No, I don't. They seem a bit more straightforward than EPs
+
<onnadi3> You simply call a method to register your bundle. that's it
+
<onnadi3> But in sum, I'm worried because I don't understand what Provisioning is good for but it sounds like it is worth the effort to use services and EPs
+
* rcjsuen__ (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc
+
<lemmy> We might want to bring Pascal into the discussion.
+
<rcjsuen__> My connection problems are kicking in.
+
<lemmy> :(
+
* benny`work (n=benny@eclipse/developer/Technology/bennywork) has joined #eclipse-soc
+
<onnadi3> rcjsuen, rcjsuen__:There're are two of you :-)
+
<onnadi3> Anyway, I think we've kinna beaten this topic to death. We should probably go with OSGi and EPs for now, and then if necessary, revisit the issue
+
<lemmy> I agree, and at first the effort for correcting our decision isn't to high.
+
<lemmy> too
+
<lemmy> Speaking about IRC connection problems, I could offer both of you an account for my IRC proxy. This should solve your firewall problems too, since it runs on 57000
+
<onnadi3> that would be nice
+
<lemmy> It keeps a buffer of the last n lines so you don't miss anything while you're disconnected.
+
<lemmy> onnadi3: OK, I'll set it up then.
+
<lemmy> Lets stick to the organizational topics, they seem to be easy. :)
+
<onnadi3> And on that note, we can move to "      - Rules Engine
+
<onnadi3>                - DSL vs. Rule Engines vs. anonymous Classes
+
<onnadi3>                - JSR94 (http://jcp.org/en/jsr/detail?id=94)"
+
<lemmy> onnadi3: what about syndicating your blog on the planet?
+
<onnadi3> I already posted a bug report about it but I don't think anyone's looked at it yet :-(
+
<rcjsuen__> onnadi3: Number?
+
<lemmy> Great, so it should appear soon.
+
<rcjsuen__> lemmy: did you talk to Gunnar/Chris directly or something?
+
<lemmy> By meeting minutes I mean that we should try to summarize our meetings and post those to the mailing list/wiki. A simple chat log is way to verbose for outsides to read.
+
<lemmy> Chris is currently on the road which might be the reason for the delay.
+
<lemmy> If it isn't syndicated on Monday, we should ping them directly.
+
<rcjsuen__> I was talking to Chris last night on Sametime
+
<rcjsuen__> I think he was in the airport maybe or something
+
<lemmy> rcjsuen: so you will take care of that issue? :)
+
<rcjsuen__> lemmy: if onnadi3 gives me the bug #
+
<lemmy> I don't have Sametime. ;)
+
<lemmy> rcjsuen: I'm sure this can be arranged.
+
<rcjsuen__> or i guess technically i don't need the bug # i can just give him the blog link
+
<onnadi3> I'm searching for it....
+
<rcjsuen__> but better that way since he can then resolve that bug
+
<rcjsuen__> lemmy: i will ST him next time i see him and asusming he's not busy
+
<rcjsuen__> he's a busy guy after all o.O
+
<lemmy> who isn't these days.
+
<onnadi3> Uh...do y'all know how to search for only bugs posted to PlanetEclipse?
+
<lemmy> I have a suggestion as a first milestone due next week: Implement a simple fs finder connected to org.eclipse.discovery via a service. An exemplary consumer utilizes this finder to discover JDKs. :)
+
<lemmy> Next week meaning 06/09.
+
<lemmy> Including the CVS cleanups.
+
<onnadi3> I can do that.
+
<lemmy> Might make sense to implement the consumer in form of some JUnit tests.
+
<onnadi3> I'm not sure about the consumer part...since that will require extension points and I don't know when exactly my book will arrive next week
+
<lemmy> So we get around the Drools discussion this time. ;)
+
<lemmy> onnadi3: Use a service or just simple method calls for the moment.
+
<onnadi3> okey-doke
+
<onnadi3> Could you please give me an example of what the tests would look like?
+
<benny`work> hi guys
+
<onnadi3> the junit tests
+
<lemmy> After all org.eclipse.discovery is supposed to provide EP _and_ services.
+
<onnadi3> benny`work: hallo
+
<benny`work> hi onnadi3
+
<lemmy> JUnit might be tricky since you don't know the fs content where the tests get executed.
+
<lemmy> Hi Benny
+
<benny`work> hi markus
+
<lemmy> You don't really know how many JDKs to expect.
+
<lemmy> Might be possible to mock the content of the fs somehow.
+
<onnadi3> I think I can do it as org.eclipse.discovery.examples instead
+
<lemmy> renaming/moving is never a problem. We have great tooling at our disposal. ;)
+
<lemmy> for the meeting minutes I suggest to rotate the burden. who wants to take care of this meeting? :o
+
<onnadi3> rcjsuen: I refiled the bug. Its #190652
+
<onnadi3> lemmy: I can do it all. Old meeting logs are here http://wiki.eclipse.org/index.php/Auto-conf_meeting_logs
+
<onnadi3> So should we move on to the DSL vs. Drools or figure out TagSea first?
+
<lemmy> dunno, maybe we can keep drools for next week.
+
* _rcjsuen (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc
+
<lemmy> Btw. by meeting notes I'm talking about a summary instead of just a chat log.
+
<onnadi3> oh. ah.
+
>_rcjsuen< don't you wanna use the proxy I've offered you?
+
<_rcjsuen> Well, that was painful.
+
<onnadi3> Three rcjsuens!!!
+
* rcjsuen has quit (Read error: 110 (Connection timed out))
+
>_rcjsuen< don't you wanna use the proxy I've offered you?
+
<onnadi3> Alright. We could rotate the responsibility but I don't mind doing the chat logs and the summaries
+
<lemmy> Perfect :)
+
<onnadi3> I'm getting paid big bucks to do it, anyway B-)
+
<lemmy> TagSE is just an idea how to make the code easy to understand for Remy and me. Check out the website and decide for yourself if it makes sense after all. I haven't used it yet.
+
<_rcjsuen> I've looked at TagSEA.
+
<_rcjsuen> Never used it, but have seen a 5-10 minute demo.
+
<onnadi3> It seems to me like we should start with Javadoc and move to TagSea if we find deficiencies. I'm not sure what TagSea will really accomplish for us
+
* onnadi3 has quit (Read error: 104 (Connection reset by peer))
+
* rcjsuen__ has quit (Read error: 110 (Connection timed out))
+
* onnadi3 (n=chatzill@mississippi-lnx.cc.gatech.edu) has joined #eclipse-soc
+
<onnadi3> lemmy: Could you please save your chat log? I think you're the only one with the complete thing now
+
<lemmy> Sure, I'll send it to you
+
<onnadi3> danke
+
<lemmy> bitte
+
>_rcjsuen< Are you going to use the bouncer? Otherwise I would reuse your account.
+
* onnadi3_ (n=chatzill@luke.cc.gatech.edu) has joined #eclipse-soc
+
<onnadi3_> rcjsuen, lemmy: Sorry guys
+
<onnadi3_> Have you guys made a decision on TagSea?
+
<lemmy> the decision is yours to make. :)
+
<onnadi3_> cool. I vote that we use Javadoc and if you guys find my commenting illegible, then perhaps we can move on to TagSea...
+
<lemmy> fine
+
* rcjsuen__ (n=rcjsuen@CPE0080c6eae091-CM001947577b96.cpe.net.cable.rogers.com) has joined #eclipse-soc
+
<onnadi3_> Next up, "- QA/Testing (Unit/FIT)"
+
<onnadi3_> What does FIT mean?
+
<lemmy> functional tests
+
<onnadi3_> howzat different from unit tests?
+
<lemmy> It is. You might wanna read up on that one. :)
+
<lemmy> Lets reschedule this one for next week too. My head is empty atm.
+
<onnadi3_> Alright
+
<lemmy> I'll go for some R&R soon. Maybe have a nice cocktail too. ;)
+
<onnadi3_> lemmy: Could you just explain what "    - IRC presence (bouncer/proxy)" this is so we know whether to shelve it too?
+
<lemmy> It's this IRC proxy thingy we've already talked about.
+
<onnadi3_> (Ah...that's why you want to move everything to next week ;) )
+
<onnadi3_> oh OK
+
<lemmy> One reason, also because my battery is nearly depleted.
+
<lemmy> Good night everybody
+
<onnadi3_> okey-dokey. Could you please send th eupdated logs
+
 
</pre>
 
</pre>
 
+
    ===August 6 2007===
===31 May 2007===
+
Markus explained how to use OS-specific fragments.
The first review of my submitted code. This was also where the name org.eclipse.discovery was decided.
+
 
+
 
<pre>
 
<pre>
onnadi3> lemmy: you want me to walk you through my code?
+
Aug 06 11:35:44 <onnadi3> I still haven't figured out how to incorporate code from OS-specific fragments
<lemmy> a second
+
Aug 06 11:35:54 <onnadi3> I haven't worked on that bug since I posted it
<onnadi3> alrighty
+
Aug 06 11:36:04 <onnadi3> ~196660
<lemmy> I see that you use Java5...
+
Aug 06 11:36:42 <lemmy> bugzilla is probably still down
<rcjsuen> AhtiK: no no no, don't worry about what's in eclipse-incub
+
Aug 06 11:37:13 <onnadi3> I can access it just fine. (why didn't KOS-MOS autocomplete?)
<onnadi3> yeah. Doesn't everyone? :-)
+
Aug 06 11:37:59 <lemmy> bugzilla was down earlier today. maybe KOS-MOS needs a restart?!
|<-- AhtiK has left freenode ("Ex-Chat")
+
Aug 06 11:38:15 <onnadi3> strange
<lemmy> rcjsuen: Do you want to talk about EEs?
+
Aug 06 11:39:14 <KOS-MOS> See bug 196660 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=196660
<lemmy> And foundation
+
Aug 06 11:39:20 <onnadi3> yay!
-->| AhtiK (n=ahtik@194.204.31.19) has joined #eclipse-soc
+
Aug 06 11:40:21 <onnadi3> So, have you ever written OS-specific fragments before?
<rcjsuen> yes, I do
+
Aug 06 11:40:40 <lemmy> yep
<rcjsuen> I care about EEs because I do a lil' eRCP hack-age
+
Aug 06 11:41:13 <onnadi3> Could you send me the fragment's manifest or any other code so I can figure out how to do it in Discovery?
<rcjsuen> onnadi3: So do you know what Execution Environments are?
+
Aug 06 11:43:37 <lemmy> onnadi3, swt itself uses fragments.
<rcjsuen> onnadi3: And actually, most of Eclipse is still written with pre-1.5 APIs.
+
Aug 06 11:43:46 <lemmy> which are pretty much platform dependent.
<rcjsuen> onnadi3: http://wiki.eclipse.org/index.php/Execution_Environments
+
Aug 06 11:44:28 <onnadi3> I just can't figure out how to make certain code/classes appear on one OS and not in another
<onnadi3> uh...not really
+
Aug 06 11:44:42 <onnadi3> Perhaps its not too important. We could alway just bundle em all together
<AhtiK> what's the onnadi3 project?
+
Aug 06 11:45:36 <lemmy> we could
<AhtiK> there are eclipse projects that REQUIRE java5
+
Aug 06 11:46:40 <onnadi3> okay
<AhtiK> at eclipse.org
+
Aug 06 11:46:43 <lemmy> the interfaces of each fragment has to be the same, but the impl might differ. actually i would move the interfaces into the host plug-in and let the fragments implement the interfaces.
<rcjsuen> AhtiK: yes, that's correct
+
Aug 06 11:47:32 <lemmy> making certain classes appear only on a certain os kinda destroys the fragment purpose anyway.
<rcjsuen> and i think apt has JavaSE-1.6 requirements
+
Aug 06 11:47:39 <onnadi3> So, we'd publish a JREFinder-win or JREFinder-osx?
<onnadi3> AhtiK: its eclipse-autoconf in CVS
+
Aug 06 11:47:47 <lemmy> nope
<rcjsuen> onnadi3: Basically, it's a constraint at the plug-in level to mandate the APIs that can be used.
+
Aug 06 11:48:18 <lemmy> we publish a jrefinder and a jrefinder-win-fragment and a jrefinder-osx-fragment.
<rcjsuen> Although this isn't forced directly, although you can set incompatible EEs as warnings.
+
Aug 06 11:48:42 <lemmy> a customer deployes all three inside osgi and osgi takes care of loading the right fragment.
<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.
+
Aug 06 11:49:01 <lemmy> osgi checks the platform filter to determine which fragment to load.
<rcjsuen> So if I only have J2SE-1.4 installed, it reads a J2SE-1.5 EE in some MANIFEST.MF
+
Aug 06 11:50:23 <-- moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has left #eclipse-soc
<rcjsuen> That plug-in will NOT be started.
+
Aug 06 11:50:34 <onnadi3> Hmm, but then we're back at square one because I don't know how to set the OS filter. I've really tried and tried but there seems to be no articles that explain how to do it
<rcjsuen> This saves us from weird problems like NoClassDefFoudnError
+
Aug 06 11:50:57 <lemmy> swt demonstrates it perfectly. Just extract org.eclipse.swt_3.3.0.vNNNN.jar and org.eclipse.swt.os.ws.arch.NNNN.jar
<onnadi3> Ah. So I should write my code in Java1.4 style, right?
+
Aug 06 11:51:26 <lemmy> onnadi3, os filters are explained in the osgi r4 spec. either the compendium or the core.
<rcjsuen> or that minor/major version issue
+
Aug 06 11:51:37 <onnadi3> oh
<rcjsuen> Actually, we are considering making it even smaller
+
Aug 06 11:52:16 <onnadi3> I have the core here. Let me check it again
<rcjsuen> So that it can be used in the embedded space
+
Aug 06 11:52:17 <lemmy> in our case it is even easier than it is for swt. we don't need to care about arch and ws. we only need to care about os.
<rcjsuen> So this would be a CDC-1.0/Foundation-1.0 profile.
+
Aug 06 11:52:38 <lemmy> (& (osgi.os=linux) (osgi.arch=x86))
<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..
+
Aug 06 11:53:04 <lemmy> it's a ldap style "query".
<rcjsuen> A lot of Eclipse plug-ins are actually at that level.
+
Aug 06 11:56:00 <onnadi3> Hmm, I found a small section in core about fragments. I think once I look through that and then through the jars (I didn't think of looking there), I'll be able to get this figured out
<rcjsuen> AhtiK: ;)
+
Aug 06 11:56:44 <lemmy> in our case the platform filter will probably look just like "(osgi.os=linux)" and "(osgi.os=win32)"...
<AhtiK> we didn't care to clean up because moved to soc.e.o, if I remember correctly :)
+
Aug 06 11:58:03 <onnadi3> cool
<onnadi3> rcjsuen: Huh. Is there a way to get eclipse to flag code that I write that is not in a particular EE?
+
Aug 06 11:59:58 <onnadi3> Ah, I'm beginning to understand it now. The section on filters is hidden in the "Service Layer" section. That's how come I'd never seen it before
<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
+
 
</pre>
 
</pre>
  
===28 May 2007===
+
===July 30 2007===
Conversation b/w lemmy and LeNettoyeur on some architectural issues.
+
 
+
 
<pre>
 
<pre>
<LeNettoyeur> well it seems that you went of a path where plugins like JDT, CDT, etc would have to be modified
+
<lemmy> So what is on our agenda?
<lemmy> true
+
<rcjsuen_> k we're good
<lemmy> Actually I would prefer not to change existing code but I don't see a way to avoid it.
+
<rcjsuen_> i 'm outside the lab right now >_>
<LeNettoyeur> I believe that the auto conf plug-in should provide a headless discovery facilities
+
<onnadi3> All that was left was to decide what we're to do about CDT i.e. to go ahead and discover whether Make exists on a system or not
<lemmy> I totally agree with headless
+
<lemmy> the other stuff is already done?
<LeNettoyeur> this plug-in would then have extension, contributed by jdt and the others
+
<onnadi3> Well...I've implemented it and it compiles
<LeNettoyeur> and these jdt.autoconf would know which value to set into jdt prefs (or whatever other mechanism)
+
<rcjsuen_> lol
<LeNettoyeur> so you end up with 3 plugins.
+
<onnadi3> But I'm getting synchronization errors
<LeNettoyeur> org.eclipse.autoconf provides basic infrastructure for discovery and has an extension point
+
<onnadi3> (I dread Concurrency)
<LeNettoyeur> org.eclipse.jdt... stays unchanged
+
<rcjsuen_> synchronization?
<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
+
<rcjsuen_> ah
<LeNettoyeur> This last plugin may have an optional dependency on UI to contribute a pref page.
+
<onnadi3> I'm working on it. I hope it won't be a big deal
<lemmy> If the consumer obtains information via some other API call, we would miss it.
+
<onnadi3> So, Markus, do you still think we should go ahead with just finding make on a system?
<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> yes, as it will help us to understand what we can generalize and refactor.
<lemmy> in the long run however, I see the ownership of jdt.autoconf at the jdt.
+
<onnadi3> That's true
<LeNettoyeur> I Agree and this is why I think you can rely on prefs and other internal formats
+
<rcjsuen_> yes
of JDT
+
<lemmy> for example the rule set/heuristics should come from a xml file. I don't want to touch code/recompile if I add a new location.
<lemmy> 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.
+
<onnadi3> Hmm, but the IFinder.refresh() can't be specified declaratively
<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> Why not?
<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.  
+
<onnadi3> Well, for instance in JREFinder, refresh() needs to call Platform and then run a loop in order to pick out the the right VMType to do the testing with
<LeNettoyeur> If you look at mylar that's how it works. Reach into the guts of controls... it does not use APIs.
+
<onnadi3> If you're going to have loops, then its no longer really declarative, is it?
<lemmy> another thing we're currently thinking about is if we go and try to validate our findings. it definitely raises security concerns.
+
<lemmy> I don't get why this renders a xml file impossible.
<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".
+
<onnadi3> Well, it doesn't make it impossible but it doesn't seem to be worth the trouble of avoiding recompilation if we'll end up writing loops and conditionals in XML
<LeNettoyeur> This decision should be left to the user
+
<lemmy> conditional xml? why?
<LeNettoyeur> and the rules should be splitted such that there is a purely static discovery where no discovered code is ran
+
<-- rcjsuen has quit (Read error: 110 (Connection timed out))
<LeNettoyeur> and another part which is more "validation" of the discovered pieces
+
<onnadi3> If you can, please look at  JREFinder.isJREDirectory(). It makes use of loops and an if-statement
<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> btw. i'm still missing the jrefinder.ui plug-in
<lemmy> yep, validation is something optional.
+
<onnadi3> Oh? I committed that
<LeNettoyeur> I see checksum as just another way to discover
+
<lemmy> I'm talking about JREFinder.find() and the potentialJRELocations getting filled.
<lemmy> good point
+
<lemmy> This could be done with a simple/non conditional xml.
<LeNettoyeur> and if it is the way that one has decided to identify its thing then that's it
+
Jul 30 11:46:39 --> moksha_anderson (n=mr_ander@ppe75-1-87-88-113-246.dsl.club-internet.fr) has joined #eclipse-soc
<lemmy> which is definitely a good example why discovery shouldn't happen each time a project gets created.
+
<lemmy> there is no jrefinder.ui plug-in. :o
<lemmy> nobody know how expensive those rules can get.
+
<onnadi3> Yeah. But what I'm saying is that IFinder also needs a refresh() method which uses relatively complex constructs that would not be suitable for XML. So we have to decide if we really want discovery plugin writers to have to separate their IFinder code into a Java part and an XML part
<lemmy> very valuable input, thx. :)
+
<lemmy> Yes, because the xml changes independently of the refresh and more frequently.
 +
<onnadi3> Hmm...
 +
<onnadi3> That's true, too :-)
 +
<onnadi3> (BTW, I named the ui plugin wrongly and that's why it isn't showing up...yet)
 +
Jul 30 11:51:52 --> rcjsuen (i=rcjsuen@nat/ibm/x-d827998b15814402) has joined #eclipse-soc
 +
<onnadi3> lemmy: should we enforce the XML rule or  just let plugin writers use XML if they see fit?
 +
<lemmy> I don't see a reason to enforce it.
 +
<onnadi3> oh OK. So you meant use XML for JREFinder, then?
 +
Jul 30 11:56:06 --> soulreaper_ (i=soul@p54A66704.dip.t-dialin.net) has joined #eclipse-soc
 +
<lemmy> onnadi3, yep
 +
<lemmy> btw. newer swallow Exceptions.
 +
<lemmy> try { ... } catch(Exception e) { // do nothing } is really bad.
 +
<lemmy> JREFinder.readLInes()
 +
<onnadi3> But the silly BufferedReader throws exceptions when it hits EOF. I couldn't think of another way to test for EOF
 +
<onnadi3> And the API doesn't have an isEndOfFile() method
 +
<lemmy> What kind of exception does it throw in that case?
 +
<-- rcjsuen_ has quit (Read error: 110 (Connection timed out))
 +
<onnadi3> **ahem** an IOException. I'll put that in right away :-)
 +
<rcjsuen> it shouldn't
 +
<rcjsuen> you're calling reader.readLine()?
 +
<onnadi3> Yeah
 +
<rcjsuen> If it's done
 +
<rcjsuen> it should return null
 +
<lemmy> onnadi3, the problem with catching Exception is, that it catches all RuntimeException. And somebody might be interested in certain RuntimeExceptions
 +
<onnadi3> Ah. Null. I didn't see that...
 +
<onnadi3> Good call, Markus. Will change it
 +
<-- soulreaper has quit (Read error: 110 (Connection timed out))
 +
<onnadi3> Alright. Bottom line: we should get JREFinder to use a an external representation (e.g. XML) for storing the potential JRE locations
 +
<onnadi3> lemmy, rcjsuen: I don't think there's anything else left to discuss; Do y'all?
 +
<rcjsuen> I don't think so off hand.
 +
<onnadi3> okey-dokey. I'll do some more bug hunting and update bugzilla once this undiscovery thing is done, then
 
</pre>
 
</pre>
  
===26 May 2007===
+
===July 28 2007===
<pre>
+
*Weekly meetings moved to 11:30am EDT/7:30pm CST
<onnadi3> Two things:
+
*Designed the interface IFinder that all finders will share. See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121 Bug 198121]
<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 ;-)
+
</pre>
+
  
===15 May 2007===
 
Gmail chat
 
 
<pre>
 
<pre>
10:41 AM markus: Hi
+
<onnadi3> rcjsuen, lemmy: Should we go ahead and get started?
me: Hello, Markus
+
<lemmy> sure
  Howdy?
+
<rcjsuen> yes, let's do that
markus: How are you?
+
<onnadi3> I would like us to go over the outstanding bugs so I can get an idea for fixing them
me: I'm fine, thank you
+
<rcjsuen> before my teammates come in ;p
  You still in India, I see
+
<onnadi3> 1. Improve configuration of new Discovery Finders
10:42 AM markus: Yep, I am, but only for another month.
+
<onnadi3> ~198121
10:43 AM Beginning with June it will be easier to schedule meetings.
+
<KOS-MOS> See bug 198121 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=198121
me: Excellent
+
<rcjsuen> query https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=SOC&component=org.eclipse.soc.discovery&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPEN
10:44 AM markus: I'll log this session so Remy gets to know what we decided.
+
<rcjsuen> ED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=
me: Alrighty
+
<rcjsuen> or not
  So, the main things I wanted to know were
+
<rcjsuen> i see it got mangled
10:45 AM 1) Shall we stick to the scope of the project as somewhat defined on the wiki? and
+
<onnadi3> rcjsuen: how'd you get to that page?
  2) Where can I find good free Eclipse learning material?
+
<rcjsuen> what page
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.
+
<rcjsuen> the query?
10:47 AM me: Ah. Good choice
+
<onnadi3> yeah
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".
+
<rcjsuen> i just constructed one from bugzilla
  -n
+
<onnadi3> could you give me the parameters? I've tried it unsuccessfully before
me: Yup
+
<lemmy> why does find() return null? why not make the method abstract?
10:49 AM BTW, for CDT we'd need to discover things like the compiler, Make, maybe subversion or CVS etc.?
+
<rcjsuen> I guess this one is better ;) https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
markus: GCC, any other compiler...
+
<rcjsuen> even tho we see the other bugs but anyway
10:50 AM With GCC being the test case?
+
<onnadi3> lemmy: It returns null because I haven't yet implemented it. I should have noted that
me: test case? Do you mean starting point?
+
<onnadi3> Let me give the sequence of calls to Finder
markus: Basically it comes down to discovering a binary in the local fs and making sure it's the right one.
+
<rcjsuen> yeah that's what i figured
me: Yeah
+
<rcjsuen> so i didn't say anything there
10:51 AM markus: by generically specifying discovery heuristics.
+
<onnadi3> a. You construct the Finder
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.
+
<onnadi3> b. You call find() whenever you want the service discovered
10:53 AM me: That's a good point. Hadn't thought about malicious bins
+
<onnadi3> c. You call unfind() whenever you want the service undiscovered. There is also a separate thread that monitors the found service and calls unfind() at regular intervals
markus: Might also be slightly expensive to call several binaries.
+
<onnadi3> that's it
me: I'm thinking... :)
+
<lemmy> "You" is who in the JRE scenario?
  What do you mean expensive?
+
<onnadi3> "You" is the person subclassing Finder e.g. JREFinder, MakeFinder etc.
10:54 AM markus: performance
+
<lemmy> That I don't get
10:55 AM something like "aBinary --version" shouldn't be too expensive but we can't be sure of the side effects.
+
<lemmy> Let me put it this way, who calls this methods during runtime?
  On the other hand using something like a checksum might be too strict and I don't know of a fuzzy checksum. ;o
+
<onnadi3> The JREFinder plugin, for example
10:56 AM me: 1 possibility, which isn't very flexible, would be to rely on the registry or environment variables
+
<rcjsuen> In its start method?
  But of course sometimes, the program isn't registered
+
<lemmy> Doesn't the JREFinder implement the Finder?
10:57 AM markus: This would require the user to setup the environment or the tool to register appropriately.
+
<rcjsuen> onnadi3: Query for all discovery bugs https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&component=org.eclipse.soc.discovery query for open ones https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=SOC&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=org.eclipse.soc.discovery
  But the environment, registry,... could still be used to gather knowledge about the system.
+
<lemmy> s/implement/extend
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
+
<rcjsuen> lemmy: you mean who instantiates it and calls find(), right?
11:00 AM markus: Well, lets leave the verification open for the moment but lets not forget about it either.
+
<onnadi3> That is one way. The other would be to expose the Finder class and have it called whenever the user clicks a button. That is how the JREFinder plugin is built right now actually
11:01 AM me: Yeah. That was a very good point you brought up
+
<lemmy> rcjsuen: yep
11:02 AM markus: In regards of free documentation for eclipse
+
<onnadi3> I guess we should use "finder plugin" for the plugin and "JREFinder" for the class. And yes, JREFinder implements Finder
eclipse.org/articles
+
<lemmy> So the finder plug-in calls find() on JREFinder and passes the result to the ECF discovery API?
wiki.eclipse.org
+
<onnadi3> lemmy: Actually, how I described it was that calling find() would automatically pass the result to the ECF Discovery API
help system
+
<onnadi3> rcjsuen: thanks for the links
eclipsezone
+
<rcjsuen> so what exactly is the Collection for?
news.eclipse.org
+
<rcjsuen> Or wait the Colection is what's been found or?
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.
+
<lemmy> so find() passes it to the PluginDiscoveryService ds instance?
  You might find it in a library.
+
<onnadi3> rcjsuen: the Collection is not strictly necessary. I thought it would be nice to have a list of what was found
  Otherwise those $43 are worth it.
+
<rcjsuen> ah kk
11:04 AM me: ah. I'll check out the articles first and then probably pick up the book too.
+
<lemmy> I would separate it into find() and populate().
  Someone else blogged about using that same book
+
<lemmy> populate() passes the find() result to ds
11:05 AM markus: I think it's the most comprehensive book on plug-in development.
+
<onnadi3> lemmy: Shouldn't we have instead, find(), populate() and findAndPopulate()?
  Though with 3.3 it is slightly outdated, but not much.
+
<onnadi3> So that plug-in writers don't have to do populate(Finder.find())
11:06 AM me: okey-doke
+
<rcjsuen> onnadi3: if we go that route i'd prefer a find() and a find(boolean populate) for populating, I don't like findAndPopulate ;p
markus: Have you thought about a way to describe the heuristics?
+
<lemmy> rcjsuen: this look so c-ish
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
+
<onnadi3> okey-dokey :-)
11:08 AM markus: Great you picked the idea up. :)
+
<lemmy> looks
me: :) yup
+
<rcjsuen> lemmy: funny, beacuse I don't know C at all
  It sounded like you'd worked on it a bit
+
<rcjsuen> except hello world
11:09 AM howdja get into it?
+
<rcjsuen> and how to make a struct
markus: I read a thesis about rules engines and drools in particular.
+
<rcjsuen> I think that's about it
  And I can contact the author if necessary.
+
<lemmy> Why have a parameter to change the behavior of a method? make two methods out of it. :)
11:10 AM me: oh wow. What was the thesis about?
+
<onnadi3> But wouldn't it just be simpler to have the one method that find()s, populate()s and returns the found services?
markus: using rules engines for implementing business logic in applications.
+
<rcjsuen> lemmy: I'm just applyign the same idea from JFace viewers refresh/update and SWT widgets layout methods
  unfortunately its written in german.
+
<lemmy> rcjsuen: they are pretty c-ish too. ;o
11:11 AM me: ah...
+
<rcjsuen> onnadi3: so by that you mean we have a populate() method that's populating _and_ returns the found services, yesA?
  I gotta hurry up on them Lektions :)
+
<lemmy> Anyway, I still don't get the whole picture...
11:12 AM markus: Next Saturday you won't be in town?
+
<rcjsuen> lemmy: having to call dispose() is pretty C-ish ;)
  But the one thereafter?!
+
<onnadi3> rcjsuen: Yeah
11:13 AM me: Yeah
+
<lemmy> rcjsuen: dispose(*widget) would be c-ish. dispose() is rather c++-ish. .P
  Actually...
+
<onnadi3> rcjsuen: that was a yeah regarding your comment about populating and returning
  I think I'll have access to internet where I'm going
+
<rcjsuen> onnadi3: I see.
  (I'll be at a graduation which is onthe Monday after)
+
<rcjsuen> true, we're not doing free(this)
11:14 AM markus: But it isn't your graduation, is it?
+
<onnadi3> :-)
me: Oh no no no
+
<lemmy> We have the PluginDiscoveryService which acts as the general API for consumers like JREInjector. Consumers get discovery results from the PluginDiscoveryService for a given type.
markus: otherwise you might face problems with payment. ;)
+
<lemmy> Also we have Finders which report discovery results to PluginDiscoveryService
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)
+
<lemmy> reporting results to PluginDiscoveryService is something in the responsibility of the Finders?
  (and I might not be sober by then :) )
+
<onnadi3> lemmy: Yes, since there is no one else for them to report to
markus: I guess i understand. ;)
+
<lemmy> onnadi3: what's with Finders registering themselfs at the PluginDiscoveryService?
11:17 AM me: So for now, I guess the project can be condensed to:
+
<lemmy> Then the PluginDiscoveryService would call find() on all registered finders
  An implementation of a rule engine for detectin binaries on an FS
+
<lemmy> registering could be done via OSGi services (but that's just the technical side of it).
  ?
+
<onnadi3> I think its the other way round. The Finder takes a pointer to the PluginDiscoveryService so that it can call registerService()
  *detecting
+
<lemmy> are we talking about registering the finder at the plugindiscoveryservice?
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.
+
<lemmy> that is the basic necessity, if plugindiscoveryservice should be responsible for calling find()...
me: yup
+
<onnadi3> The reason why we can't have PDS calling find() on all Finders is because you never know when someone will want a service found e.g. in the case of having a GUI button that starts the finding process
11:19 AM markus: So more like: A framework based on a rules engine to detect "services" with an exemplary local fs implementation.
+
<lemmy> onnadi3: true, but it means also that we cannot issue a global find() on all finders.
11:20 AM me: Ah yes. I like that :)
+
<lemmy> question is, what is the main use case.
markus: Btw any news in regards to the paperwork?
+
<lemmy> PluginDiscoveryService might offer discover() and discover(IServiceType)
me: No. I sent mine in yesterday, though
+
<onnadi3> what does discover() do? Call find() on all Finders?
11:21 AM markus: The Google or the Eclipse ones?
+
<lemmy> while the first is for issuing a general find() on all finders independent of the type, the latter is for calling find() on specific finders.
me: Could you please tell me where I can find the buttons that say whether they've been received?
+
Jul 28 10:06:01 --> sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
  oh ah. um the google ones
+
<rcjsuen> I like that.
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.
+
<onnadi3> Doesn't that make what we did with JREFinder impossible then? i.e. have a GUI that initiates the find process. I'm not saying that JREFinder is the best model for structuring finders...
  Might be best to sent a question to soc-dev. Other might search for the same button. ;)
+
Jul 28 10:07:09 --> kreismeister (n=Miranda@eclipse/developer/Eclipse/Kreismeister) has joined #eclipse-soc
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
+
<lemmy> onnadi3: The gui would be finder independent.
  And so I didn't join it then
+
<onnadi3> Ah yes
  I'm gonna be so hated :)
+
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
  Anyway...
+
<rcjsuen> mmm yes
11:24 AM markus: I haven't seen anything on this topic on the soc-dev ml. %)
+
<lemmy> If there is no Finder for the given IServiceType registered, nothing would happen.
me: oh. Sorry, I meant the Google ml
+
<lemmy> onnadi3: calling the specific finder directly also has the disadvantage, that you cannot easily have different finders for the same type.
  You're right. I'm hitting up soc-dev
+
<lemmy> imagine a RegistryJREFinder and a FilesystemJREFinder.
  BTW, should I put our chat logs on on the wiki?
+
<onnadi3> lemmy: jolly good point
11:25 AM markus: IRC or this one?
+
<lemmy> They both discovery the same IServiceType "JRE"
  IIRC for IRC the group agreed on not putting the up.
+
<lemmy> Finder would then only implement IDiscoveryResult find() and unfind(IDiscoveryResult) maybe renamed to refresh(IDiscoveryResult)
11:26 AM them
+
<lemmy> But this would leave PluginDiscoveryService responsible for keeping and updating IDiscoveryResults for undiscovery.
me: Well, the IRC...and all the "official" meetings
+
<lemmy> I'm not sure if this is a big disadvantage.
  I thought it'd be nice to have em all in one place fore reference
+
<onnadi3> It can always delegate to the Finders, can't it?
markus: Currently there is some discussion ongoing on how we wanna "monitor" the projects.
+
<lemmy> All this matches stuff could be handled inside the Finder
11:27 AM Either inside the wiki, the mailinglist or with bugs in bugzilla.
+
<lemmy> onnadi3: PluginDiscoveryService will delegate the unfind/refresh of the IDiscvoeryResult to the Finder, but it needs to keep track of IDiscoveryResults.
  Or even blog posts.
+
<onnadi3> I believe it already does that
me: About that, isn't monitoring projects via bugs kind of an abuse of the system?
+
<lemmy> perfect :)
11:28 AM I mean, isn't bugzilla meant for bugs?
+
<onnadi3> If we have Finders registering with PluginDiscoveryService through extension points, how will (for instance) the GUI be able to initiate a find()?
  just wondering
+
<rcjsuen> isn't that the discovery(IServiceType.JRE) thing?
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.
+
<lemmy> The GUI will need to get the PluginDiscoveryService instance and call discover() on it.
  chatlogs could go in as attachments.
+
<lemmy> rcjsuen: exactly
11:29 AM me: OK
+
<lemmy> The current button wouldn't call JREFinder directly anymore, but PluginDiscoveryService.discovery(aJREType)
  So I guess the answer is to wait until y'all decide the means we should use to track our discussions, eh?
+
<lemmy> Getting the PluginDiscoveryService reference in the GUI can be done via OSGi.
11:30 AM markus: I guess so
+
<-- sonnyblack has quit (Read error: 110 (Connection timed out))
me: 'key-doke
+
Jul 28 10:21:18 * sonnyblack_ is now known as sonnyblack
11:31 AM One last question:
+
<onnadi3> Aaaaah
  How do you manage to be so enthusiastic about Eclipse all the time?
+
<onnadi3> I see
  Whenever I talk to you or Remy, I just get all fired up with Eclipse-coding-passion
+
<onnadi3> rcjsuen: Could you please tell us the method names you would have preferred for the Finder class?
11:32 AM markus: Well, I spent nearly all day working with Eclipse. In the evening I'm not that enthusiastic anymore. ;)
+
<rcjsuen> isMatch -> matches
  But working here in India is more exhausting than back home.
+
<lemmy> I've just submitted a IFinder proposal as a bug comment
</pre>
+
<rcjsuen> dunno about initPotentialMatches(), unfind is pretty weird but dunno if there are better options
===21 April 2007===
+
<rcjsuen> lemmy: to 198121?
 
+
<lemmy> yep
<pre>
+
<onnadi3> lemmy: what is the boolean in refresh() supposed to be?
*** onnadi3 [i=82cf935f@gateway/web/cgi-irc/ircatwork.com/x-6b272e4f5f832da1] has joined #eclipse-soc
+
<rcjsuen> now bugzila worked
*** Topic is: SOC 2007 @ Eclipse is on! http://code.google.com/soc - Get help with ~help - List of accepted applications: http://code.google.com/soc/eclipse/about.html  - Find information here: http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007 - Be patient and stick around for an answer - Subscribe to the mailinglist https://dev.eclipse.org/mailman/listinfo/soc-dev
+
<lemmy> onnadi3: pretty much what unfind() did.
*** Topic set by pombreda [Sun Apr 15 18:10:57 2007]
+
<rcjsuen> Eh?
*** onnadi3 faern arhan pombred1 benny`patchslut rcjsuen kynes soulreaper lemmy Pookzilla zx KOS-MOS ijuma
+
<onnadi3> Sorry, I meant what is the return value of refresh()?
*** Channel created on Sun Nov 26 00:42:43 2006
+
<lemmy> but IFinder is stateless. I doesn't keep track which IDiscoveryResults have been found before.
<onnadi3> rcjsuen, lemmy: sorry, people. I'd been waiting in #eclipse_soc ...
+
<lemmy> boolean
<rcjsuen> onnadi3: oh, sorry I was not clear
+
<lemmy> valid
<lemmy> Hi Ogehi
+
<lemmy> is the given IDiscoveryResult still valid or not
<lemmy> +c
+
<rcjsuen> hm
<onnadi3> Hello, Markus
+
<rcjsuen> validate(IDR) maybe? ;p
<onnadi3> rcjsuen: nah, its my fault. I've been here before :-)
+
<rcjsuen> that's kinda like refresh
<onnadi3> What's been happening in SoC, today?
+
<rcjsuen> we're validating it again
<lemmy> do we have a log?
+
<rcjsuen> or maybe not
<onnadi3> Ach, I'm using a web client that doesn't support logging...
+
<lemmy> true :)
<onnadi3> Can you log?
+
<rcjsuen> maybe validate implies a shortop
<lemmy> yep, i'll log our conversations.
+
<rcjsuen> whereas refresh is a longop?
<onnadi3> Good. Thanks
+
<rcjsuen> hm
<onnadi3> rcjsuen, lemmy: Shall we get down to business?
+
Jul 28 10:29:45 * rcjsuen rubs his chin.
<lemmy> later i'll try to setup logging which redirects to html.
+
<-- kreismeister has quit (Read error: 104 (Connection reset by peer))
<lemmy> onnadi3: sure :)
+
<onnadi3> Shouldn't we also have a method that refreshes all the previously found IDiscoveryResults?
<rcjsuen> Yes, I'm here.
+
<rcjsuen> like a validateAll()?
<onnadi3> Excellent!
+
<onnadi3> Yeah
<lemmy> remy: you got my email with the proposed agenda?
+
<rcjsuen> hm
<onnadi3> Yup.
+
<lemmy> onnadi3: IFinder.refreshAll()?
<rcjsuen> lemmy: yeah
+
<onnadi3> And it could return a Collection of still valid IDRs
<onnadi3> Quick question before we start: does Eclipse have a "find in files" function?
+
<lemmy> but this implies that IFinder knows about previously discovered IDiscoveryResults.
<rcjsuen> in my INBOX
+
<rcjsuen> Maybe take a Collection and pass back a Collection of valid ones?
<rcjsuen> too
+
<onnadi3> Oh!!! I see your point, Markus. PDS is already keeping track of IDRs
<lemmy> ok, wasn't sure if it got caught in the spam filter again. %)
+
<lemmy> well, this is just convenient API then.boolean validate(IDiscoveryResult) is the minimum.
<rcjsuen> onnadi3: if you use the search it'll search all open projects, dunno about specifying specific files
+
<lemmy> Well, one problem arises with IFinder not keeping track of IDiscoveryResults. PDS needs to know by which specific IFinder instance the IDiscoveryResult has been found earlier.
<rcjsuen> lemmy: wel-, i am sure everyone is busy (except me), let's get started?
+
<lemmy> The RegistryJREFinder probably cannot verify an IDR discovered by the FilesystemJREFinder
<onnadi3> rcjsuen: alrighty. Thanks
+
<onnadi3> Akk! This means that PluginDiscoveryService will have to handle polling when it comes to undiscovery
<onnadi3> Sure, let's start
+
<lemmy> The IDS instance could store the IFinder by which is has been found.
<lemmy> do we consider the channel log our meetings minutes?
+
<lemmy> polling? PDS certainly is responsible for refreshing IDS and hence needs to ask the various IFinders regularly.
<onnadi3> Sounds fine
+
<lemmy> Btw validate sounds more like verification of an IDS. I tend to refresh
<rcjsuen> fine by me
+
Jul 28 10:37:39 --> kreismeister (n=Miranda@p57AB7FBA.dip.t-dialin.net) has joined #eclipse-soc
<lemmy> has either of you anything to add to the agenda?
+
<lemmy> verification in terms of "is this IDS really a Sun JRE 1.4"...
<onnadi3> Nope
+
<onnadi3> lemmy: what is IDS?
<rcjsuen> seems ok
+
<rcjsuen> I'm fine with refresh
<rcjsuen> if something comes up i will say something
+
<lemmy> s/IDS/IDR
<lemmy> ok, so lets get started with "project documentation".
+
<onnadi3> okey-dokey. So i guesswe're pretty much done with this bug, apart from naming?
<lemmy> i guess the wiki is a good place to keep general text.
+
<rcjsuen> yeah
<lemmy> but what about diagrams and such, do we wanna use UML? do we need it?
+
<onnadi3> Bug no.2: Decide on the CDT tools to provide discovery for
<lemmy> Ogechi: are you familiar with UML?
+
<lemmy> I got a question, ca we move our meeting permanently to monday afternoon ~17:30pm?
<rcjsuen> I've never used UML outside of school, so I am fine if we don't use it
+
<onnadi3> Sure, if it works with Remy
<rcjsuen> and that was for like...one term
+
<rcjsuen> What time is that
<onnadi3> lemmy: I know of it but haven't used it. It'll be useful if we get're building a boatload of classes
+
<lemmy> 11:30
<onnadi3> lemmy: I think we should start with prose first and get into UML as the need arises
+
<rcjsuen> ooo, that collides directly with my weekly meeting
<lemmy> fine with me, lets try to limit the new things in this project.
+
<rcjsuen> Although that meeting isn't that important
<lemmy> s/things/technology
+
<rcjsuen> cuz we can bring our notebooks
<rcjsuen> lemmy: agreed
+
<rcjsuen> it's an informal status update
<onnadi3> agreed
+
<rcjsuen> I think it's fine
<lemmy> so for the project we will work with written text.
+
<lemmy> perfect, so next meeting is 07/30 11:30am EDT
<onnadi3> For documentation, we'll basically need inline comments, and perhaps a "how to hack" document, right?
+
<onnadi3> ALrighty
<onnadi3> lemmy: yup
+
<rcjsuen> ok
<rcjsuen> yes, the atter is extremey important
+
<onnadi3> SoBug no.2: Decide on the CDT tools to provide discovery for
<rcjsuen> there goes my keys again
+
<onnadi3> ~197885
<lemmy> what do you guys understand under a "how to hack"?
+
<KOS-MOS> See bug 197885 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=197885
<rcjsuen> for there to be users, you need to have a good howto guide
+
<onnadi3> (I like doing that :-))
<rcjsuen> because we are a-- -azy and woud rather not try to figure out how to use a too-
+
<onnadi3> Shall we be sticking with CDT?
<onnadi3> "how-to-hack: A doc describing how a program was built to aid other developers in modifying it later"
+
<lemmy> I'm still +1 for CDT even if it means we only do discovery of make
<onnadi3> rcjsuen: been typing too long? ;-)
+
<rcjsuen> yeah
<rcjsuen> onnadi3: maybe, dunno, oh wel-
+
<rcjsuen> i never see people complain about setting up pdt
<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.
+
<rcjsuen> (well install is hard)
<lemmy> i guess this tool isn't targetted on end users, hence an isv might be appropriate.
+
<onnadi3> So, we need to test if make is in the PATH, and if it is not, find where it is installed on the system
<rcjsuen> true
+
<lemmy> well, we wan't to discover all installations ofmake and not just the one in make.
<onnadi3> what is an ISV?
+
<lemmy> s/make/path
<rcjsuen> embedded in ec-ipse -ike what p-atform does?
+
<onnadi3> The thing is the CDT interface doesn't really have a drop-down list like JDT does
<rcjsuen> something software vendor i think it is
+
<onnadi3> All it has is a text box where you can enter the name of the make command you want to use
<rcjsuen> independent maybe
+
<lemmy> postponed until Monday? The other bug will keep you busy anyway, right?
<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
+
Jul 28 10:57:21 --> sonnyblack_ (n=sonnybla@host137-3-dynamic.10-87-r.retail.telecomitalia.it) has joined #eclipse-soc
<onnadi3> not in WEB, of course
+
<onnadi3> sure :-)
<lemmy> maybe we should divide it. we need documentation for people working with the code base and also for people using the codebase.
+
<onnadi3> Sweet meeting y'all
<lemmy> for the latter the typical eclipse documentation for extensionpoints... would probably be the best. for the former i would choose uml. ;p
+
<onnadi3> See ya soon
<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
+
 
</pre>
 
</pre>

Latest revision as of 19:37, 22 August 2007

The final meeting.

August 19 2007

The final meeting.

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

August 14

Action items

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

Markus explained how to use OS-specific fragments.

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

July 30 2007

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

July 28 2007

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

Back to the top