[equinox-dev] org.osgi.util.promise
Hi, I want to verify: org.osgi.util.promise (via org.eclipse.osgi.util) doesn't seem to be in Eclipse Neon, but is available in Oxygen+. Is that right? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Meta-Type Annotations
Hi Peter, FWIW, ECF depends upon and distributes org.osgi.service.remoteserviceadmin.* as part of ECF's RSA impl. We use a piggy back CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8527 Not that I'm recommending this for metatype annotation classes. Seems to me it would be better placed as part of Equinox SDK...along with the metatype impl? Scott On 4/4/2017 11:15 AM, Peter Nehrer wrote: Hello, I'm looking for annotation types in package org.osgi.service.metatype.annotations but can't seem to be able to find them anywhere in Equinox. Looking at https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8618, the latest attached jar (https://dev.eclipse.org/ipzilla/attachment.cgi?id=12761) does have those annotations, but I can't find that jar included anywhere in Eclipse (git, build, p2 repo... anywhere); not even Orbit has the latest version. Where do I need to look? Has Equinox only consumed portions of that jar? If so, would it be OK to extract the Metatype annotations and still be covered by the same CQ? I'd appreciate any pointers anyone might have. Thanks! --Peter ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] scr, cm, and metatype
On 1/20/2017 6:38 AM, Thomas Watson wrote: EventAdmin is also the RI for OSGi R6. There are no updates to EventAdmin for R7. Thanks. One follow up on EventAdmin. I've read that the Equinox EventAdmin uses a single thread for dispatch...i.e. for all topics...and it seems like that's correct given a short glance at the code.And that there is no way to configure things to (e.g.) use/configure a thread pool. Is that still true? Thanks, Scott CM and DS both have significant updates in R7, but the spec is not going to be finalized in time for Oxygen so it will have to way until the next release. The DS updates are very significant and that is what motivated me to move to the felix SCR implementation. There simply was no interest to be found to update the Equinox DS implementation and it was getting very stale WRT spec levels. I have not looked at the CM changes in detail for OSGi R7, but I suspect that should be easily contained in Equinox. Let me know if anyone is interested in starting a branch to work on CM R7 in the mean time! And to let folks on this list know again. The Equinox Framework also continues to be the OSGi RI and ongoing work towards R7 is being done in a branch (twatson/osgiR7). Again this is not planned to be included in Oxygen because the specification likely will not complete in time. We could consider it for Oxygen.1 though. Tom From: Scott Lewis <sle...@composent.com> To: equinox-dev@eclipse.org Date: 01/19/2017 03:59 PM Subject: Re: [equinox-dev] scr, cm, and metatype Sent by: equinox-dev-boun...@eclipse.org On 1/19/2017 12:36 PM, Thomas Watson wrote: Equinox metatype implementation continues to be the reference implementation for OSGi and implements the very latest released specification. I did update the CM implementation to be CM spec version 1.5 a long time ago (3 years?). OSGi R6 did not update the CM spec, if I recall correctly. The spec doc for OSGi R6 still lists CM spec at version 1.5. So from my perspective both of the CM and metatype Equinox impls are current with R6. Ok, great...I must have been misinformed about the versions. Same for EventAdmin? Also...I heard that there were some proposed CM/DS additions for R7. Are those to be in Equinox Oxygen or not likely? Scott Tom From: Scott Lewis _<sle...@composent.com>_ <mailto:sle...@composent.com> To: Equinox development mailing list _<equinox-dev@eclipse.org>_ <mailto:equinox-dev@eclipse.org> Date: 01/19/2017 12:40 PM Subject: [equinox-dev] scr, cm, and metatype Sent by: _equinox-dev-bounces@eclipse.org_ <mailto:equinox-dev-boun...@eclipse.org> As per bug [1], Equinox and Eclipse are moving to use Felix SCR v2.0.8 for Oxygen. My understanding is that the Equinox ConfigAdmin and Metatype implementations are rather old now...and don't support OSGi R6 versions of those services. Would it be possible to add Apache Felix of ConfigAdmin and Metatype...versions that are at least R6 compatible...to Orbit? The reason I ask is that a number of projects (e.g. ECF, Kura, Karaf, others)...and our/their consumers...use DS+ConfigAdmin+Metatype all three together, and having the Equinox versions of these services be so old is a problem for them (especially since the spec enhancements over last few years have been very significant. Or, perhaps the right answer is to update these Equinox impls? Not sure. [1] _https://bugs.eclipse.org/bugs/show_bug.cgi?id=501950_ ___ equinox-dev mailing list_ __equinox-dev@eclipse.org_ <mailto:equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit_ __https://dev.eclipse.org/mailman/listinfo/equinox-dev_ ___ equinox-dev mailing list _equinox-dev@eclipse.org_ <mailto:equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit _https://dev.eclipse.org/mailman/listinfo/equinox-dev_ ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Felix SCR
Hi, I thought I remembered that Equinox/Eclipse was going with the replacing the SCR impl that it's currently using with the Felix SCR implementation sometime during the Oxygen release cycle. Is that still right? If so, when is it planned to happen? And one final question: I assume it will be using some version of Felix SCR that supports the 1.3+ version of the SCR spec...is that true? Thanksinadvance, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Convergence between p2 and the OSGi resolver+repository
On 11/15/2016 6:44 PM, Pascal Rapicault wrote: Specifically: - Is it possible to publish the bundle generic capabilities/requirements to the p2 repository? Yes this should be possible. The underlying p2 capability / requirement model is really extensible and the current limitation is only the serialized format. I think this bug would be relevant to this question: https://bugs.eclipse.org/bugs/show_bug.cgi?id=313553 ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] osgi application service
Equinox implements the osgi application service (org.osgi.service.application) via this bundle: org.eclipse.equinox.app This bundle has compile-time dependencies on both the equinox service registry (org.eclipse.equinox.registry), and PackageAdmin which for some environments are a disadvantage. The org.osgi.service.application package is also present in the same bundle as the implementation, which is a debatable choice. Would there be any appetite to refactor the org.eclipse.equinox.app bundle (perhaps into multiple dependent bundles) so as to: 1) Separate the impl of org.osgi.service.application from the parts that are dependent upon the equinox service registry (so as to allow use of the application service without the service registry) 2) Remove deps to PackageAdmin service 3) Possibly separating the org.osgi.service.application classes from the equinox impl. ? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Getting equinox artifacts using maven
On 7/20/2015 1:49 PM, Thomas Watson wrote: The Equinox SDK includes several bundles that are not actually developed as part of the Equinox project. I'm not sure I want to have Equinox publish other Eclipse project's bundles. I would like to start with publishing only the Equinox bits that implement the OSGi specifications. Two questions about this: 1) Has there been any progress and/or plans WRT publishing the Equinox bits into maven repo (and ideally to public repos)? 2) For projects (ECF in this case) that have a dependency on jobs...is there any way that we could publish a maven repo that included some version of jobs and the required Equinox bundles? Perhaps temporarily? The reason for this is that we are getting a fair number of consumer requests to make our OSGi Remote Services implementation available as maven repo, so that it can be more easily used in (e.g.) Karaf and/or other OSGi runtimes that favor the use of maven repos. We do make our own bundles available as a maven repo [1], but we have dependencies on 3 equinox bundles and jobs so this makes things difficult for maven-based consumers. Thanks, Scott [1] http://build.ecf-project.org/maven/3.10.1/ ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Getting equinox artifacts using maven
On 7/20/2015 5:39 AM, Thomas Watson wrote: I think it would be great if we could make this happen for all of Equinox. BTW jobs is not part of Equinox, it is part of the Eclipse project. It appears to be in the Equinox Mars SDK...would it be possible to include it in what's being discussed? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Getting equinox artifacts using maven
On 7/3/2015 5:14 AM, Mikael Barbero wrote: Hi Christian, There is a bug about this issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=471373 From the message https://dev.eclipse.org/mhonarc/lists/dash-dev/msg01348.html, you will understand why synchronization from repo.eclipse.org http://repo.eclipse.org to maven central is in a stale state. However, it is perfectly possible for a project to publish directly to Maven central. Californium project is about to do that (https://bugs.eclipse.org/bugs/show_bug.cgi?id=468448) If the equinox devs would like to publish their bits to repo.eclipse.org http://repo.eclipse.org or gpg sign their artifacts to publish them to maven central, I can help with that. Is there any interest from equinox team in publishing bits to maven repos? As Christian said, ECF is providing an R6 OSGi Remote Services/RSA distribution for Apache Karaf [1]. We currently create a maven repo ourselves as part of our releases [2]. ECF RS/RSA has deps on 4 equinox bundles, however: o.e.equinox.common o.e.equinox.concurrent o.e.core.jobs o.e.equinox.supplement As I understand, these are part of the equinox sdk. Given this, I suppose we are asking to publish the equinox sdk as maven repo, ideally through maven central but repo.eclipse.org would be ok too. Thanks, Scott [1] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf [2] http://build.ecf-project.org/maven/3.10.0/ HTH Mikael Le 3 juil. 2015 à 12:34, Christian Schneider ch...@die-schneider.net mailto:ch...@die-schneider.net a écrit : I am currently helping Scott Lewis to bring ECF to Apache Karaf. Our biggest problem with this is that ECF needs a bunch of equinox bundles that are not available in maven central. See this http://download.eclipse.org/rt/ecf/3.10.0/site.p2/karaf4-min-features.xml At the moment we use http urls to be able to get at least started. These urls are not really good for people inside bigger companies though. Often these companies do not allow direct access to the internet even for developers and especially for production machines. So accessing the urls is not possible. Additionally they are not cached like mvn urls. So every clean startup of karaf hits the p2 repo server again. It also makes it very hard for people to use these artifacts in non tycho builds which are very common outside the eclipse world. I have noticed that eclipse already hosts several maven repositories for other projects. Would it be possible to also deploy equinox bundles into such a repository or even better into maven central? At apache this is very convenient. We have a nexus server at apache and the project poms are set up to deploy their for snapshots and releases there. Releases go to a staging repo automatically and after the vote you just need to press a publish button and the artifacts go to maven central. I am pretty sure we can organize to help with this if eclipse would be interested to also get such a setup. The collaboration between eclipse projects and apache projects is still quite slim unfortunately. I think one big reason for this is the separate repository systems that make it very difficult to use projects from each other. So I think tackling this problem would help a lot to improve collaboration. I have read in another thread that this would be a complicated problem. Unfortunately there is no further information what the obstacles are. I spoke to quite some people at eclipse about this and they are all quite interested in maven deployments. So I think at the minimum there should be an open discussion so people understand where we are with this. Is there some place maybe on bugzilla where I can read into what was discussed about this? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] R6 httpservice impl in equinox
Ray and Thomas, Regarding the OSGi R6 httpservice impl in equinox: Are all the same equinox bundles required (any new or removed)? Are there any equinox-specific examples, tests, or docs? Thanksinadvance, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Jetty version for Luna?
On 9/18/2014 10:04 AM, Thomas Watson wrote: We are looking to move up the Jetty 9 for Equinox. But from the perspective of the http service impl in Equinox it is expected to work across multiple container implementations and Servlet specification levels. Jetty 9 is attractive for several reasons as you mentioned. Another benefit is to make sure the http service works on the latest spec release of Servlet. I see from M5 that Jetty 9.2.5 is there...that's great. Thanks to any/all involved. Question: Does/will the (presumably still Jetty-based) implementation of the OSGi HttpService include the support for whiteboard/R6 in Mars? Thanksinadvance, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] equinox ds
On 2/19/2015 5:26 PM, BJ Hargrave wrote: See http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg08088.html Thanks. I can't seem to find the SCR version at felix.apache.org that supports RFC190. Would you please point me in the right direction there? And given Thomas' plans for Mars (using Felix SCR version), how far along is the conversion work? Are the SCR bundle(s) going to be in Orbit at some point? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Jetty version for Luna?
On 9/18/2014 10:04 AM, Thomas Watson wrote: We are looking to move up the Jetty 9 for Equinox. But from the perspective of the http service impl in Equinox it is expected to work across multiple container implementations and Servlet specification levels. Jetty 9 is attractive for several reasons as you mentioned. Another benefit is to make sure the http service works on the latest spec release of Servlet. WRT to plans. The move to jetty 9 can happen at anytime, but need someone to step up to do the work. Last I checked we do have some initial work done in https://bugs.eclipse.org/bugs/show_bug.cgi?id=401784but need someone to dust that one off and see if it is in shape to get into Mars. The R6 impl of Http Whiteboard specification is coming along, but realistically it probably will not be ready until M4. Thanks Thomas. As an Equinox incubator committer I could possibly help out with some of this, if desired. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Running junit plugin tests with security manager
We/ECF would like to be able to run some junit plugin tests (junit 3 at least, 4 if possible) with the java security manager running in the target. Has anyone previously created/got the .java.security policy and appropriate permission.perms that would allow this to happen? I fussed with creating the .java.security policy files to allow use of EclipseStarter, junit, etc...but didn't get very far. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] PDE DS annotations?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=376950 On 6/4/2014 7:04 PM, Raymond Auge wrote: Does anyone know if PDE supports DS annotations? It seems not in Kepler, but I'm holding out hope until I hear no from you all. -- *Raymond Augé* http://www.liferay.com/web/raymond.auge/profile (@rotty3000) Senior Software Architect *Liferay, Inc.* http://www.liferay.com (@Liferay) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Jetty version for Luna?
Hi, I assume that since the current Equinox HttpService impl is provided by Jetty that some version of Jetty will be used for Equinox Luna. If that's right, what version of Jetty will be used? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Jetty version for Luna?
Hi David...yeah, thanks. I should have qualified that I was mostly interested in 8 vs. 9. Thanks for the info. Scott On 4/17/2014 3:52 PM, David M Williams wrote: what version of Jetty will be used? The same version that is currently being used, 8.1.14 ... well, unless they come out with a quick point release that has a critical fix in it, or something. But will stay on 8.x stream, if that's more to the point? HTH From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 04/17/2014 05:45 PM Subject: [equinox-dev] Jetty version for Luna? Sent by: equinox-dev-boun...@eclipse.org Hi, I assume that since the current Equinox HttpService impl is provided by Jetty that some version of Jetty will be used for Equinox Luna. If that's right, what version of Jetty will be used? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] R6 httpservice update
Hi Gunnar, On 3/15/2014 6:49 AM, Gunnar Wagenknecht wrote: On 2014-03-07 16:58:17 +, sle...@composent.com said: 3) Both orgs are already using Jetty...and are looking to continue this I believe, the approaches are totally different from a technical point of view. Currently...perhaps. Thus bringing them together is not easiely possibly. :) My response is: the technical challenges of bringing them together are probably not that significant...at least compared to the org and cultural challenges of getting the cooperation/joint effort and resources from the various teams (equinox, jetty, felix, etc) across organizations (eclipse, apache). The Equinox HttpService is essentially just a servlet that runs in any compatible container. It's shared between the servlet bridge and Jetty. The Jetty version just launches an embedded Jetty server and hooks the servlet into it. Thus, it's esentially single web app with a single servlet. I think the Apache HttpService as a much more deeper integration with Jetty. The configure different Jetty web apps / contexts per HttpContext. But I could be wrong and this was with the PAX HttpService. WFIW, all of the whiteboard enhancements of the R6 spec can be actually implemented by an extender bundle. That could potentially be shared between both worlds. There you go! :) Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] subsystem spec
On 12/19/2013 12:08 PM, Thomas Watson wrote: The current Equinox plan [1] does not include implementing any new specifications from the EEG. While I would certainly be open to a contribution of subsystems in Equinox, I think it would fit better under the gemini project where many of the other EEG specifications are implemented. Subsystems is a rather involved specification to implement. Unless someone already has an impl just ready to contribute I don't see one becoming available in eclipse for some time. I know Glyn Normington was thinking of providing an implementation in Virgo at some point, but I don't think that made it anywhere. In the mean time you could consider pulling in the Apache Aries subsystems implementation into orbit. This implementation runs well on Equinox and uses Equinox regions as an implementation detail for providing the isolation required for subsystems. I see. I suppose that's what ECF will do (Aries) in immediate term. Up to PMC and RT projects of course, but it might be worth proposing some strategy for RT projects to coordinate on producing an impl (i.e. gemini, ECF, Equinox, others?). Scott Tom [1] http://projects.eclipse.org/projects/rt.equinox/releases/4.4.0 Scott Lewis ---12/19/2013 12:38:45 PM---Hi, I'm interested in whether there are any desires and/or plans for Equinox From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 12/19/2013 12:38 PM Subject: [equinox-dev] subsystem spec Sent by: equinox-dev-boun...@eclipse.org Hi, I'm interested in whether there are any desires and/or plans for Equinox to implement the EEG Subsystem Spec (chap 134) in Luna or post timeframe? I went to the Equinox plan [1] and something seems to be wrong with accessing the page right now so I couldn't see whether it's in the project plan or not. I suppose this could also be considered a question for the entire RT project as well...although I don't know what other RT project would be a candidate for subsystem spec impl. The reason I ask: ECF would like to consume an Equinox-based impl of the subsystem spec...and use it for/with our impl of the RS/RSA specs. For example to make provider distribution/installation/configuration easier. Thanks, Scott http://www.eclipse.org/projects/project-plan.php?projectid=rt.equinox ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] subsystem spec
Hi, I'm interested in whether there are any desires and/or plans for Equinox to implement the EEG Subsystem Spec (chap 134) in Luna or post timeframe? I went to the Equinox plan [1] and something seems to be wrong with accessing the page right now so I couldn't see whether it's in the project plan or not. I suppose this could also be considered a question for the entire RT project as well...although I don't know what other RT project would be a candidate for subsystem spec impl. The reason I ask: ECF would like to consume an Equinox-based impl of the subsystem spec...and use it for/with our impl of the RS/RSA specs. For example to make provider distribution/installation/configuration easier. Thanks, Scott http://www.eclipse.org/projects/project-plan.php?projectid=rt.equinox ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] TrustEngine in supplemental?
On 12/11/2013 1:35 PM, Thomas Watson wrote: From: Scott Lewis sle...@composent.com Hi Tom, On 12/11/2013 5:47 AM, Thomas Watson wrote: We may be able to put org.eclipse.osgi.service.security package in supplemental, but would it be possible to have others supply a different fragment that implements ECFTrustManager in another way? Possibly. Could you explain what you have in mind? Even if we move the org.eclipse.osgi.service.security API to the supplement bundle you would still need an implementation of TrustEngine to plug into ECFTrustManager. Yes...where (what bundle) is the equinox TrustEngine implementation(s)? A TrustEngine which is backed by a keystore is implemented by the Equinox framework [1]. By default the framework registers a TrustEngine that is backed by the CA certs usually provided by the VM installation, but the framework can be configured to use a different keystore if desired. I'm not sure if in your ssl scenarios some other entity is also registering a TrustEngine service. No, no ECF code is currently registering a TrustEngine service. My thought was that some other fragment could be implemented that provides an alternative implementation of ECFTrustManager that simply looks at the CA certs keystore themselves instead of using a TrustEngine service to do that work for them. I see. Another alternative: if the TrustEngine service interface (only) were added to the supplemental, I (or contributors/consumers) could look into providing a non-Equinox TrustEngine implementation as part of ECF's ssl support. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] TrustEngine in supplemental?
ECF is restructuring our features so that our bundles can more easily be installed in non-Eclipse runtime environments [1]. We also would like to continue to produce distributions that can run on Felix and/or other frameworks while providing as much of our own functionality as possible...particularly around remote services/RSA. There are some SSL fragments in ECF (contributed to us years ago by IBM) that are dependent upon the Equinox TrustEngine class...i.e. org.eclipse.osgi.service.security.TrustEngine. Here's [2] the ECF class that references TrustEngine in org.eclipse.ecf.ssl. There are consumers of ECF that would potentially like to use the org.eclipse.ecf.ssl fragments on non-Equinox frameworks, but that's not currently possible given the TrustEngine's presence in org.eclipse.osgi...and it doesn't appear to be in the Equinox supplemental [3]. Is it appropriately in Equinox supplemental? Thanks, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=409787 [2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/framework/bundles/org.eclipse.ecf.ssl/src/org/eclipse/ecf/internal/ssl/ECFTrustManager.java [3] http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg06829.html ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] simpleconfigurator on other frameworks?
Hi John, Thanks for the info. Speaking only about simpleconfigurator for the moment, has anyone tested it out on Felix recently (e.g. as part of p2-on-Felix efforts)? Would there be any desire/community value in (e.g. me) doing that and reporting results somehow/somewhere? Scott On 7/24/2013 10:59 AM, John Arthorne wrote: Simpleconfigurator is I believe completely generic and could be used on other frameworks. It does have some optional Equinox dependencies. Simpleconfigurator.manipulator requires frameworkadmin. There was a time in the past when we had prototypes of frameworkadmin for Felix and Knopplerfish but those were abandoned. The purpose was always for the frameworkadmin API to remain generic, and then have separate implementations per framework. There are some related bugs with a small amount of historical info: https://bugs.eclipse.org/bugs/show_bug.cgi?id=289136 https://bugs.eclipse.org/bugs/show_bug.cgi?id=175809 john From: Thomas Watson tjwat...@us.ibm.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 07/24/2013 09:47 AM Subject: Re: [equinox-dev] simpleconfigurator on other frameworks? Sent by: equinox-dev-boun...@eclipse.org Although simpleconfigurator has no 'p2' in its namespace it is maintained by the p2 team. So this may be a better question for p2-dev. That being said I know that simple configurator has a goal to not depend on anything out side of the framework. It is driven by the content of bundles.info. The bundles.info file is managed by the rest of p2 (or anything else, simpleconfigurator does not care who manages that file as long as it uses the the expected syntax/format). Others from p2 may be able to point you to some efforts from a while back to run p2 on other frameworks besides Equinox. Tom Scott Lewis ---07/23/2013 03:34:37 PM---Hi Folks, A couple of questions about simpleconfigurator (and simpleconfigurator From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 07/23/2013 03:34 PM Subject: [equinox-dev] simpleconfigurator on other frameworks? Sent by: equinox-dev-boun...@eclipse.org Hi Folks, A couple of questions about simpleconfigurator (and simpleconfigurator manipulator): 1) I see from a casual look at the dependencies that it only imports org.osgi packages...does this mean that SC/SCM can run on other frameworks (e.g. Felix)? 2) I assume that simple configurator depend upon FrameworkAdmin service...is that right? What other services does it depend upon? 3) Is there a web/wiki page that has docs WRT these questions and/or others? I found [1], but it's maybe a little dated (?) thanksinadvance, Scott [1] http://wiki.eclipse.org/Configurator ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] simpleconfigurator on other frameworks?
Hi Folks, A couple of questions about simpleconfigurator (and simpleconfigurator manipulator): 1) I see from a casual look at the dependencies that it only imports org.osgi packages...does this mean that SC/SCM can run on other frameworks (e.g. Felix)? 2) I assume that simple configurator depend upon FrameworkAdmin service...is that right? What other services does it depend upon? 3) Is there a web/wiki page that has docs WRT these questions and/or others? I found [1], but it's maybe a little dated (?) thanksinadvance, Scott [1] http://wiki.eclipse.org/Configurator ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] How to use web services in an Equinox OSGi container.
ECF is another option for OSGi remote services (and Remote Service Admin). RS/RSA was formerly known as DOSGI. http://wiki.eclipse.org/ECF#OSGi_Remote_Services ECF has a provider architecture for remote services [1]...which allows the use of a variety of existing transportsincluding Restlet, other REST-based services, SOAP/Axis/WS, JMS...and/or custom provider(s). Equinox is the default OSGi framework for ECF development...so integration with Equinox is a given...although our RS/RSA impl also runs on Felix. Scott [1] http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF On 4/21/2013 9:56 PM, Prasad Jeewantha wrote: Hi Alex, Thanks a lot for the response. I think Apache-CXF DOSGi is the best option I have for my scenario. PJ On Sun, Apr 21, 2013 at 4:17 PM, Alex Blewitt alex.blew...@gmail.com mailto:alex.blew...@gmail.com wrote: On 21 Apr 2013, at 10:44, Prasad Jeewantha wrote: I need to develop an application with back-end and front-end clearly separated through web services. The BE and FE of the application should run on two separate JVMs in two Equinox containers. The BE-FE communication happens through webservices. Is there any recommended way to do this? I came across Apache-CXF which provides a framework for webservices. Please tell me if/how Equinox be integrated with Apache-CFX. Any help is appreciated. Thanks, PJ. PS: please see my SO question on this. http://stackoverflow.com/q/16129590/1411653 Yes, it is possible to do this in any OSGi runtime (whether Felix or Equinox). However, this is not an Equinox specific issue. Please see the examples at the Apache-CXF pages for distributed OSGi: http://cxf.apache.org/distributed-osgi.html Alex ___ equinox-dev mailing list equinox-dev@eclipse.org mailto:equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] equinox event question
Greetings, We/ECF uses Equinox event for our implementation of the Remote Service Admin specification. One of our consumers has been using ECF remote services/RSA, Equinox, DS and their own code, and has experienced a problem that we are attempting to diagnose. See the full description on this bug [1]. As you can see on the bug, the error message that they are apparently getting when the remote service export fails is: !ENTRY org.eclipse.equinox.ds 2 0 2013-01-14 20:46:42.134 !MESSAGE [SCR] Enabling components of bundle org.eclipse.equinox.event did not complete in 3 ms !ENTRY org.eclipse.equinox.ds 2 0 2013-01-14 20:46:42.135 !MESSAGE [SCR - WorkThread] Timeout occurred! Thread was blocked on processing [QueuedJob] WorkPerformer: org.eclipse.equinox.internal.ds.SCRManager@19336006; actionType 1 This apparently happens intermittently at startup. Couple of questions for Equinox folks: Does anything about this error message (for org.eclipse.equinox.event) look familiar/understandable? Is it possible that a race on startup is causing this? Also...for the DS folks...is there any option that will get DS to report the component where the thread was blocked? It would be very helpful for us to be able to understand where this is happening (i.e. whether it's consistently on a given component, etc). Thanksinadvance, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=398321 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] equinox event question
Thanks much Thomas. So far, the reporter has been great about responding to requests, so my guess is he'll come up with the desired info. BTW...others might be interested in this...the bug reporter has been using Equinox + ECF Remote Services to do some interesting work on 'Service Oriented Evolutionary Algorithms'. See [1] for his description. Scott [1] http://osgiliath.org/2013/01/16/service-oriented-evolutionary-algorithms-paper-has-been-accepted/ On 1/17/2013 11:42 AM, Thomas Watson wrote: Hi Scott, I added comments to the bug. I suspect it is a deadlock caused by locks in the DS and/or framework implementations. But at this point it is just a guess. Hopefully the bug reporter can help out by generating a thread dump for us to look at. Tom Scott Lewis ---01/17/2013 11:51:11 AM---Greetings, We/ECF uses Equinox event for our implementation of the Remote Service From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 01/17/2013 11:51 AM Subject: [equinox-dev] equinox event question Sent by: equinox-dev-boun...@eclipse.org Greetings, We/ECF uses Equinox event for our implementation of the Remote Service Admin specification. One of our consumers has been using ECF remote services/RSA, Equinox, DS and their own code, and has experienced a problem that we are attempting to diagnose. See the full description on this bug [1]. As you can see on the bug, the error message that they are apparently getting when the remote service export fails is: !ENTRY org.eclipse.equinox.ds 2 0 2013-01-14 20:46:42.134 !MESSAGE [SCR] Enabling components of bundle org.eclipse.equinox.event did not complete in 3 ms !ENTRY org.eclipse.equinox.ds 2 0 2013-01-14 20:46:42.135 !MESSAGE [SCR - WorkThread] Timeout occurred! Thread was blocked on processing [QueuedJob] WorkPerformer: org.eclipse.equinox.internal.ds.SCRManager@19336006; actionType 1 This apparently happens intermittently at startup. Couple of questions for Equinox folks: Does anything about this error message (for org.eclipse.equinox.event) look familiar/understandable? Is it possible that a race on startup is causing this? Also...for the DS folks...is there any option that will get DS to report the component where the thread was blocked? It would be very helpful for us to be able to understand where this is happening (i.e. whether it's consistently on a given component, etc). Thanksinadvance, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=398321 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] TrustEngine and other security services
Hello, Is there documentation on Equinox security services like org.eclipse.osgi.service.security.TrustEngine service...and implementation? I looked in the Equinox Security area [1], but didn't find a lot of service/API docs. Is/are there examples of using the TrustEngine service(s)? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] target version of osgi specs for juno
On 7/3/2012 10:48 AM, BJ Hargrave wrote: Several of the OSGi spec implementations in Equinox Juno are used as RI for OSGi Compendium 4.3: DS, Metatype, Coordinator, Initial Provisioning, Event Admin, Wire Admin. So all those implementations are at the Compendium 4.3 level. I don't know the status of the other OSGi spec impls in Equinox Juno. ECF [1] implements Remote Services (compendium in 4.3, core in 5.0) and Remote Services Admin (enterprise) specs. With Juno release, both of these impls are now at the OSGi 5.0 spec level. Scott [1] http://www.eclipse.org/ecf ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] policies wrt use of Bundle-ActivationPolicy
Hi, ECF has consumers that use our OSGi remote services implementation in client-server use cases. Some of these also use other framework impls (e.g. felix) for the remote service host and/or consumer. As a plugin to Eclipse, we use Bundle-ActivationPolicy: lazy for many/most of our bundles...but there are now requests [1] for us to remove BAP from some of our bundles, in order to facilitate usage in non-Eclipse use cases. What are the current policies and/or guidelines for the use (or not) of BAP within (and/or outside of) Eclipse? Thanks, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=373475 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] policies wrt use of Bundle-ActivationPolicy
Hi Richard, On 3/13/2012 11:58 AM, Richard S. Hall wrote: stuff deleted However, I can talk about general OSGi policy: If your bundle is expected to provide functionality to client bundles and client bundles can reasonably expect to obtain (or witness or whatever) your provided functionality without being required to explicitly class load from your bundle, then you should not use lazy policy. Does that make sense? Yes. The functionality at issue here is remote services/RSA...where the service hosts expect to be able to call bundleContext.registerService(...) and have some topology manager be previously started...and with service hook export the service for remote access as part of the registerService call. On the service consumer side it's trickier, because in at least some cases people expect to have the remote service be discovered (via some network discovery provider) as soon as things start. This is also the case in [1], for example. The simplest example is a bundle that provides a service and imports its service package. If this bundle is lazy, then its service will never be provided because an explicit class load will never be triggered on it. This is not limited to providing services, though. For extenders, if they are lazily started but extendees do not explicitly load classes from the extender, then extensions may never be processed. yes...this is exactly the case with remote services I would say. You just need to think of how your bundles are or can be used to know if lazy policy is right for them. Right...I agree...thanks. I hope that's what we're doing with [1]. The tricky bit (as usual) is knowing how/can people are using our stuff. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ds properties
Hi Thomas, Aren't there some timeouts associated with invoking bind/unbind/activate/deactivate component methods? These are what I'm mostly interested in. Thanks, Scott On 5/11/2011 1:48 PM, Thomas Watson wrote: He Scott, Stoyan, the current owner of DS, likely will not respond until he gets in tomorrow since he is located in Europe. But I am not sure what timeouts you mean or what you are trying to trace. I know the DS implementation has some trace options that can be enabled through the tracing tab on the Eclipse launch configuration. Not sure if these trace options would provide the information you are looking for though. Tom Scott Lewis ---05/11/2011 01:22:29 PM---I believe there are some system properties that can change the From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org Date: 05/11/2011 01:22 PM Subject: [equinox-dev] ds properties I believe there are some system properties that can change the org.eclipse.equinox.ds defaults...e.g. wrt timeouts and tracing and such. Is this right? If so, is there some documentation on those properties (e.g. names, defaults, etc)? I didn't find anything through a couple of searches through the wiki/website. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] ds properties
On 5/11/2011 2:04 PM, Neil Bartlett wrote: Scott, Is this what you're looking for? http://wiki.eclipse.org/Equinox/RuntimeOptions Yes...exactly. Thanks kindly Neil and Thomas. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] OSGi Remote Service Admin
Greetings, As planned, the ECF project is approaching completion of an ECF-based implementation of the remote service admin OSGi 4.2 specification [1]. For those unfamiliar, the remote service admin spec is part of the OSGi enterprise spec. As appropriate for our project scope, our intention is to focus only on implementing the remote service admin spec...i.e. we have no intention or plans for implementing other parts of the OSGi ee spec (e.g. blueprint, etc). The remote service admin specification includes classes...and these classes are included in the 4.2 osgi.enterprise.jar. How should ECF proceed WRT the IP clearance for these OSGi classes? Are they included in some overarching Eclipse Foundation-OSGi relationship? Are they included in the process that the runtime project has for getting new versions of (e.g.) the core framework spec classes? If not, could/should they be? We would obviously rather not have to through a distinct, ECF-specific IP process for including these OSGi classes in ECF...especially since we as a project do not currently have an active representative on the Enterprise experts group. Also, duplicating work already done by the IP team is undesirable for obvious reasons. So...how should we proceed WRT use of these OSGi EE classes for remote service admin? Thanks, Scott [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=324215 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Meeting minutes and provide status
Thomas, Although I was unable to attend this call and probably won't be able to attend future calls at the chosen time/day, I would like to request a review as per my mailing list posting below. I would like to make sure this request is not lost in the usual shuffle. Thanks, Scott ---equinox dev mailing list posting 9/7/2010 This is a request to have the org.eclipse.equinox.concurrent API reviewed, accentuated (if desired...e.g. integration with jobs API), and ultimately graduated (from provisional) for ultimate inclusion in Equinox 3.7. Please see the attachment on this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247 Scott On 9/21/2010 8:45 AM, Thomas Watson wrote: The meeting minutes from todays Equinox call today can be found at http://wiki.eclipse.org/Equinox/Meeting_Minutes/20100921 This is also a reminder to send me your status for this weeks eclipse team meeting on Wednesday. Thanks. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] request for equinox concurrent API review and graduation
This is a request to have the org.eclipse.equinox.concurrent API reviewed, accentuated (if desired...e.g. integration with jobs API), and ultimately graduated (from provisional) for ultimate inclusion in Equinox 3.7. Please see the attachment on this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247 Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] threadpool?
Hi Folks, Is there a threadpool impl available in Equinox somewhere? (non-internal packages of course). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Lazar Kirchev on rt.equinox.incubator by Scott Lewis
Scott Lewis voted: +1 Welcome Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] context classloader support specifics?
Hi, Would someone be able to point me at docs on the context classloader support specifics in Equinox? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] concurrent.future provisional api
Hi Thomas, FWIW there was quite a lot of discussion and public review of this API as part of the original contribution. The history is here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777 I've opened this bug to track the graduation request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309247 Scott Thomas Watson wrote: Hi Scott, I am glad to hear you have been making good use of the concurrent.future package in ECF. Unfortunately I don't see us being able to commit to fully reviewing the API in the last two weeks of M7 to allow it to become API for Helios. This will have to wait until the next release. Please open a bug report requesting the graduation of the API for next release. We should plan to get it done in an early milestone (M1 or M2). At least the package is not in some internal named package so when we do make it real API we will not be automatically breaking clients. Only if we find something that must change will clients be broken when it becomes API. Tom Inactive hide details for Scott Lewis ---04/13/2010 09:33:38 PM---Hi Folks,Scott Lewis ---04/13/2010 09:33:38 PM---Hi Folks, From: Scott Lewis sle...@composent.com To: Equinox development mailing list equinox-dev@eclipse.org Date: 04/13/2010 09:33 PM Subject: [equinox-dev] concurrent.future provisional api Hi Folks, The org.eclipse.equinox.concurrent bundle has a package in it: org.eclipse.equinox.concurrent.future that is exported, but is currently marked x-internal:=true since it's been considered provisional since being introduce Jan 2009. I would like to consider removing x-internal=true for Helios. ECF has been using the provisional API for about 1 year now for our remote service API async/messaging support and for discovery API, and so far the usage has not generated any required changes. So please let me know how/if this could be done. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] concurrent.future provisional api
Hi Folks, The org.eclipse.equinox.concurrent bundle has a package in it: org.eclipse.equinox.concurrent.future that is exported, but is currently marked x-internal:=true since it's been considered provisional since being introduce Jan 2009. I would like to consider removing x-internal=true for Helios. ECF has been using the provisional API for about 1 year now for our remote service API async/messaging support and for discovery API, and so far the usage has not generated any required changes. So please let me know how/if this could be done. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox
Hi Rob, Rob Heittman wrote: Inline: On Sun, Apr 4, 2010 at 6:01 PM, Scott Lewis sle...@composent.com mailto:sle...@composent.com wrote: My only comment about discovery is that ECF also has a discovery API (org.eclipse.ecf.discovery) ... [snip] The OSGi remote services spec defines a thing called a 'config type'...which is just a String that uniquely identifies a type of remote service provider. ECF maps this 'config type' to identify an ECF IContainer type/factory...and this string identified the provider used underneath (e.g. ecf.r-osgi.peer, ecf.generic.client, ecf.xmpp.client, etc)...so to use a particular provider/protocol to register/publish a remote service all one has to do is create a provider with new name, specify it as the config type to use when registering a remote service, and that provider will be used. Good. I am not immersed in this model yet, but it sounds like a nice, loosely coupled way to accomplish discovery. I'll have a look at what Zookeeper is doing to get more up to speed. Just to be clear we/ECF have a pending contribution that allows the use of Zookeeper for discovering any/all types of remote services providers. See this bug for details https://bugs.eclipse.org/bugs/show_bug.cgi?id=301854 and this blog about the contribution: http://industrial-tsi-wim.blogspot.com/2010/03/ecf-discovery-how-many-zookeepers-does.html I see. I agree that the use of OSGi services for dynamicity is a very useful thing...and another thing that would make sense to do within Restlet...assuming OSGi runtime environment. Naturally. There has been discussion on the Restlet list of the possibility of creating an OSGi edition that is more tightly bound to OSGi and requires that it be used inside an OSGi runtime. I suspect, from other work I've done, that this needn't be an edition as other Restlet editions are -- conditionally compiled throughout to work in special Java environments, e.g. GWT, GAE, or Android. IIRC that was the last consensus when it came up on the list, too. I suspect that if the appropriate facilities are exposed, all the OSGi runtime-dependent aspects can be put in their own bundle(s). The devil being in the details of the appropriate facilities are exposed ... to me this suggests, within Restlet, more reliance on interfaces and less on concrete classes, implemented with an a priori awareness of what we want higher-level features like ECF discovery and OSGi remote services to be able to do with Restlet. Sounds excellent to me. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox
Hi Jens, Jens Lauterbach wrote: stuff deleted So I'm curious about the other specs not listed on this page: • UPnP Device Service • Remote Services The Eclipse Communication Framework (3.2) project (part of EclipseRT, but not Equinox project specifically) fully implements the Remote Services specification from OSGi 4.2 spec (chap 13). ECF 3.2 was released in Feb [1], and here's a description of some of the technical characteristics of the OSGi 4.2 impl along with links to docs and examples [2]. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] How much of the R4.2 spec is implemented in Equinox
Sorry...here are the refs: [1] http://eclipseecf.blogspot.com/2010/02/ecf-32-now-available.html [2] http://eclipseecf.blogspot.com/2010/01/osgi-remote-services-from-ecf.html Scott Lewis wrote: Hi Jens, Jens Lauterbach wrote: stuff deleted So I'm curious about the other specs not listed on this page: • UPnP Device Service • Remote Services The Eclipse Communication Framework (3.2) project (part of EclipseRT, but not Equinox project specifically) fully implements the Remote Services specification from OSGi 4.2 spec (chap 13). ECF 3.2 was released in Feb [1], and here's a description of some of the technical characteristics of the OSGi 4.2 impl along with links to docs and examples [2]. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox
. Regarding Jetty, it can be used with Restlet in two ways. First, as a regular Servlet container as pointed out by Scott, or as a standalone Restlet connector (bypassing the Servlet layers) to directly use the Restlet layers, providing a lighter solution. Note that while Restlet applications can be deployed into Servlet containers if needed, many users prefer standalone deployment of Restlet applications in Restlet components, using Restlet connectors (such as Jetty). I hope this helped to clarified :) Best regards, Jerome PS: I've put in copy the various persons interested in this Equinox/Restlet GSoC project(s) as I'm not sure how many follow this list. Sorry for any duplicate email. Le 29/03/2010 19:33, Scott Lewis a écrit : Hi Jerome, Jerome Louvel wrote: Hi Scott, Rajeev and all, Thanks for your interest Rajeev in this GSoC project. Scott, it seems that the integration of Restlet with ECF could give you with fully-featured server-side REST support. This would also be a nice use case for the GSoC Restlet integration with Equinox project. I agree. I've recently created a wiki page for this project. Maybe we could propose another GSoC project for this specific topic? ECF integration http://wiki.restlet.org/developers/172-restlet/350-restlet.html I think that would be a great idea. One point of information/interest...there are already several ECF committers and contributors that would probably also be interested in this 'second step'...i.e. of using Restlet API on Equinox/OSGi server to implement an ECF remote services host provider. Actually, Bryan Hunt is one such ECF contributor, and he may be interested in this sort of use case as well. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox
Hi Rob, Thanks for the comments. A couple of reactions inline below: Rob Heittman wrote: Restlet is already fairly far down the road of bundleization (sounds German). The project delivers many bundles which provide different extension capabilities and compatibilities, and at least at the fundamental level, these all behave just fine in OSGi. However, the bundles require some additional work to really talk, as by default they rely on Java service discovery (anti) patterns to discover, select, and use the present extensions. There is still some contention between different approaches for doing this in OSGi (see this long -- and aging -- thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1322152 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1322152) but there are really two sane paths: - Repackage some Restlet bundles as fragments (David Fogel likes/uses this approach) - Override the service discovery stuff programmatically (My company likes/uses this approach) There is an option 3, involving hacking META-INF/services in each bundle to rig the discovery the way you want it, and yes I have a few places where I still have to do that, but it doesn't really dignify further discussion :-) My only comment about discovery is that ECF also has a discovery API (org.eclipse.ecf.discovery), and that discovery API is also implemented by multiple providers...like zeroconf/bonjour, slp, apache zookeeper, and others (I believe that Bryan Hunt has done a discovery provider also, but am not certain of that). Like the remote services stuff I described before, the ECF OSGI remote services implementation only uses the abstract discovery API...meaning that any providers (no matter what protocol they use) will automatically be spec compliant. So this is one area of further study and action: how, canonically speaking, should one compose a set of Restlet extensions in an OSGi container and indicate which combination should be used for a particular application? If I am using Restlet as my OSGi HttpService -- or via any other OSGi service interface -- what is the canonical path to indicate that I want it to use Jackson for JSON-based representations and run over the Jetty connector? The OSGi remote services spec defines a thing called a 'config type'...which is just a String that uniquely identifies a type of remote service provider. ECF maps this 'config type' to identify an ECF IContainer type/factory...and this string identified the provider used underneath (e.g. ecf.r-osgi.peer, ecf.generic.client, ecf.xmpp.client, etc)...so to use a particular provider/protocol to register/publish a remote service all one has to do is create a provider with new name, specify it as the config type to use when registering a remote service, and that provider will be used. Some providers would use Jackson, or json.org json parsing (which we already have as a bundle in ECF SDK), and use the Jetty http service. Does this answer your question? Next ... The routing-level plumbing of Restlet 2.x involves concrete classes which are wired together in a fairly static way. (I am thinking here of Restlet and its subclasses: especially, VirtualHost, Component, Filter, Guard, Router, Route). There is an inchoate desire to make this more dynamic and to leverage interfaces in a future Restlet release; interfaces here make me think naturally of OSGi services. For example, we have a number of different Guards which do authentication against different types of authorities. At present, these have to concretely extend the Guard class and I must define my own interfaces around them, then extra code to discover them and plug them into the application at the appropriate place. It would be nice if all this was more OSGi-native. Again -- nothing here is really at the fully formed specification level, just a hint at an area where valuable work could be done. I see. I agree that the use of OSGi services for dynamicity is a very useful thing...and another thing that would make sense to do within Restlet...assuming OSGi runtime environment. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Re: [GSoC] Restlet integration with Equinox
Hello Jerome, Jerome Louvel wrote: Hi Scott, Rajeev and all, Thanks for your interest Rajeev in this GSoC project. Scott, it seems that the integration of Restlet with ECF could give you with fully-featured server-side REST support. This would also be a nice use case for the GSoC Restlet integration with Equinox project. I've recently created a wiki page for this project. Maybe we could propose another GSoC project for this specific topic? I'm not opposed to a separate GSoC project for full integration with ECF's implementation of OSGi remote services, but I guess I don't really understand: given that Restlet is basically already done/working, and Jetty is already used (presumably as the servlet container for restlets), what would be the integration between Restlet API and Equinox *other* than integration with OSGi remote services? I'm really trying to understand what that would be. But again, I don't have any particular problems with two gsoc project ideas if they really are two different integrations. ECF integration http://wiki.restlet.org/developers/172-restlet/350-restlet.html Thanks...this looks great. It might more properly be phrased as OSGi remote services integration though...since that's the OSGi standard that ECF implements. Otherwise, Restlet 2.0 (currently in RC stage) fully supports asynchronous request processing on both server-side and client-side so it looks like a good fit for your ECF requirements. It also nicely integrates with Jetty 7.0. That's great (on both async and jetty 7). It does indeed sound like the asynchronous request processing would be a very good fit to ECF's remote services...as although not standardized by OSGi spec at the moment, our remote services impl does have full support for async messaging with remote services [1]) Thanks, Scott [1] http://eclipseecf.blogspot.com/2010/02/osgi-remote-services-and-sync-vs-async.html Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com Le 24/03/2010 18:55, Scott Lewis a écrit : Hi Rajeev, Simon, Bryan, FYI, there is already quite a lot of REST support in the Eclipse Communication Framework (ECF) project, which is part of Eclipse RT along with Equinox. Below are some relevant links to the existing work here. One of the things that we *haven't* completed/done with REST is to create support for restful OSGi remote services on the host/server. The existing REST work is mostly) focussed on supporting Equinox/OSGi-based REST clients. Work on restful remote services would be a great area for work IMHO...especially since it can be (and in my opinion should be) easily connected to the OSGi 4.2 remote services standard implementation that ECF already provides. I notice that you (Rajeev) go to the University of Moratuwa. Perhaps coincidently, last year ECF had a gsoc project led by another student at Moratuwa...he's now working with us as an ECF contributor...and I've copied him on this email. Perhaps you might want to contact him directly. Thanks, Scott [1] http://eclipseecf.blogspot.com/2010/01/soap-rest-and-ecf-remote-services.html [2] http://eclipseecf.blogspot.com/2009/11/ecf-provides-some-additional-rest.html [3] http://eclipseecf.blogspot.com/2010/02/ecf-32-now-available.html Rajeev Sampath wrote: Hi, I'm a Computer Science student from University of Moratuwa, Sri Lanka and interested in the GSoC project idea on 'Restlet integration with Equinox' which is available at Eclipse GSoC ideas list [1]. I'm quite familiar with OSGi and RESTful web-services, but new to Restlet and now in the process of getting familiarized with it. I'd like to know whether there have already been initiatives to accomplish this by Equinox community (apart from the Restlet's resources available at GSoC ideas page) so that I can get myself synchronized. I could hardly find anything on this from the Equinox developer mailing list. I appreciate your comments and suggestions regarding this project. [1] http://wiki.eclipse.org/Google_Summer_of_Code_2010_Ideas Thanks. Rajeev ___ equinox-dev mailing list equinox-dev-j9T/66mevpfafugrpc6...@public.gmane.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [GSoC] Restlet integration with Equinox
Hi Rajeev, Simon, Bryan, FYI, there is already quite a lot of REST support in the Eclipse Communication Framework (ECF) project, which is part of Eclipse RT along with Equinox. Below are some relevant links to the existing work here. One of the things that we *haven't* completed/done with REST is to create support for restful OSGi remote services on the host/server. The existing REST work is mostly) focussed on supporting Equinox/OSGi-based REST clients. Work on restful remote services would be a great area for work IMHO...especially since it can be (and in my opinion should be) easily connected to the OSGi 4.2 remote services standard implementation that ECF already provides. I notice that you (Rajeev) go to the University of Moratuwa. Perhaps coincidently, last year ECF had a gsoc project led by another student at Moratuwa...he's now working with us as an ECF contributor...and I've copied him on this email. Perhaps you might want to contact him directly. Thanks, Scott [1] http://eclipseecf.blogspot.com/2010/01/soap-rest-and-ecf-remote-services.html [2] http://eclipseecf.blogspot.com/2009/11/ecf-provides-some-additional-rest.html [3] http://eclipseecf.blogspot.com/2010/02/ecf-32-now-available.html Rajeev Sampath wrote: Hi, I'm a Computer Science student from University of Moratuwa, Sri Lanka and interested in the GSoC project idea on 'Restlet integration with Equinox' which is available at Eclipse GSoC ideas list [1]. I'm quite familiar with OSGi and RESTful web-services, but new to Restlet and now in the process of getting familiarized with it. I'd like to know whether there have already been initiatives to accomplish this by Equinox community (apart from the Restlet's resources available at GSoC ideas page) so that I can get myself synchronized. I could hardly find anything on this from the Equinox developer mailing list. I appreciate your comments and suggestions regarding this project. [1] http://wiki.eclipse.org/Google_Summer_of_Code_2010_Ideas Thanks. Rajeev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] JXTA and Equinox
Hi Ali, The Eclipse Communication Framework [1] project has a provider architecture, allowing the use of arbitrary protocols to implement common APIs. Some years ago, one of our committers (Pierre Henry-Perret) did some work to implement a jxta provider [2]. This work was not completed...however, I believe some of it can/could be migrated forward. I'm including Pierre on this thread so that he can be engaged directly. As I recall, the classnotfound issues reported on the bug [2] were due to some of the third party lib dependencies in jxta (e.g. log4j) not being resolved correctly. With Orbit and/or other means, these issues are easily resolved. Scott [1] http://www.eclipse.org/ecf [2] https:// https://bugs.eclipse.org/bugs/show_bug.cgi?id=135452 Ali Naddaf wrote: Hello everyone. I was wondering if anyone has successfully tried using JXTA (or JXSE, to be more precise) and Equinox. Searching for OSGi and JXTA on Google gives a bunch of hits but the reports are mixed and mostly talk about some classloader issues and haven't seen any successful report so I thought maybe someone on this list may have tried or know of such an effort. Many thanks Ali. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] SCRManager
Hi Stoyan and Neil, I've created enhancement request for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=276727 Thanks, Scott Neil Bartlett wrote: Yes I agree this would be very useful. In fact Felix's SCR already has such an introspection interface. Like Stoyan I think this would be best mandated by the DS spec so that it could be used independently of any framework or SCR implementation. I have started writing an RFP for this already but have not had a lot of time to work on it. Neil On Mon, May 18, 2009 at 8:17 AM, Stoyan Boshev s.bos...@prosyst.com wrote: Scott Lewis wrote: Question about the SCRManager class in the org.eclipse.equinox.ds declarative services implementation: Is there any way to get at the SCRManager instance programmatically? That is, there is already a command provider that allows console access to the SCRManager (and the ServiceComponents, etc), but is there any service made available for other bundles to access the SCRManager? AFAICT by quick examination of the source, the answer is currently 'no', but would there be some possibility of having such programmatic access in the future? Should an enhancement request be opened? Indeed, now the SCR core is not programmatically accessible. Please open an enhancement request about this. The desire here would be to write some management interfaces/UI that would allow the service component state to be queried (like the SCRCommandProvider does now). This is really an interesting use case. In the ideal case the access to SCR should be done via a service specified by the DS specification. This would allow you to manage the DS components regardless of the SCR implementation. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev Regards, Stoyan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] SCRManager
Question about the SCRManager class in the org.eclipse.equinox.ds declarative services implementation: Is there any way to get at the SCRManager instance programmatically? That is, there is already a command provider that allows console access to the SCRManager (and the ServiceComponents, etc), but is there any service made available for other bundles to access the SCRManager? AFAICT by quick examination of the source, the answer is currently 'no', but would there be some possibility of having such programmatic access in the future? Should an enhancement request be opened? The desire here would be to write some management interfaces/UI that would allow the service component state to be queried (like the SCRCommandProvider does now). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] servletbridge + p2
For those interested, I've created an enhancement request easier servletbridge-based equinox servers, with p2 bundles included. https://bugs.eclipse.org/bugs/show_bug.cgi?id=275762 I've attached a contribution that is a feature and product-definition for creating such a server/servers. Any thoughts/comments appreciated. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Autostarting Bundles
Hi JB, J B wrote: stuff deleted I was able to get the P2 console started, but haven't been able to figure out how to provision a bundle using yet. Anyone have experience with doing that? Yes. The main things to do: 1) Create a 'group iu' in your repository. This can easily be done by (e.g.) creating a feature in Eclipse and exporting the feature to an existing repository. 2) install the group iu with the console 'provinstall' command (after adding the repo via provaddartifactrep and provaddrepo [I think these are the command names]). 3) use the confapply command to apply the configuration to a running instance Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] P2 and the transport layer
Hi All, Yes this is one use case that ECF was introduced to support. Incidently, we do already have JMS-based providers for ECF...although there is a small amount of remaining work to support the filetransfer API. See/join the ecf-dev mailing list here: https://dev.eclipse.org/mailman/listinfo/ecf-dev Also see some recent discussion about supporting multicast-based file transfer as well (not the same thing as JMS, of course, but the remaing work to support filetransfer is overlapping): http://dev.eclipse.org/newslists/news.eclipse.technology.ecf/msg01398.html Thanks, Scott Henrik Lindberg wrote: p2 transport is based on ECF, so what you propose is the way to go if you need some other protocol. - henrik 8 apr 2009 kl. 18.44 skrev J B moa...@gmail.com: Can anyone provide me better details to the current state of the transport layer for P2? We need to support provisioning, but our only available transport layer will be JMS. If the P2 transport layer is based on ECF, I was hoping it might be possible to simply plugin a JMS transport and ride on top of that. Any thoughts? Thanks! Birch ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Request to remove Constants#SERVICE_TYPE constant
Hi Thomas, As it turns out, the RFC 119 spec removed SERVICE_TYPE usage some time ago, so we (ECF) didn't even have a chance to reference it in our impl. ...so we're +1 on immediate removal. Scott Thomas Watson wrote: Hello fellow Equinox team. In the past Equinox was under the Eclipse PMC and we needed to get PMC approval for post M6 API changes. Now that we are under RT Jeff and I decided that it would be best to keep the Equinox API change approvals localized to the Equinox dev list. Here is my first API change request for Galileo (hopefully will not need any more this release). I am CC'ing the eclipse PMC for their awareness. GOALS/BENEFITS: org.osgi.framework.Constants is an interface of constants for the OSGi framework. This API is defined by the OSGi Alliance. Several new constants have been added during the coarse of the OSGi R4.2 specification process which is being implemented in the Galileo release of Equinox. The SERVICE_TYPE is a new constant that was introduce during the R4.2 specification process. It has since been decided that the constant is not needed and should be removed. In Equinox we must align with the final OSGi API as defined by the OSGi Alliance. ASSOCIATED BUGS: https://bugs.eclipse.org/bugs/show_bug.cgi?id=270511 RISKS: Low. These are new constants introduced by OSGi during the 3.5 cycle. The constant is consumed by ECF (RFC 119 impl), but they are willing to make the change as well. There are currently no other known adopters. PERFORMANCE IMPACT: None. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] a future with futures
Hi Thomas, Thomas Watson wrote: How big is the code? I got the impression that is is not going to be that big (perhaps 20k or less)? The current class files are ~15k compressed jar (good guess Tom). Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] a future with futures
Hi Thomas and all, I've attached a zip with new plugin org.eclipse.equinox.future with package naming as discussed, and patches for jobs and tests plugins to the original bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777 Just to avoid further potential for multi-bug confusion. Scott Thomas Watson wrote: comments in-line. Tom Scott Lewis wrote: Hi all, Although provisional API (for 1.5 years) seems a bit conservative...and it will cause ECF/other potential clients of the API difficulties over this time (i.e. we would like to have our ECF 3.0/Galileo release of remote services use this API)...I understand and can certainly live with this decision. So if I understand it correctly the approach is to be: 1) new plugin with id: org.eclipse.equinox.future 2) API package name: org.eclipse.equinox.internal.provisional.future 3) JobsExecutor and RealmExecutor in org.eclipse.core.jobs bundle, in a new package: org.eclipse.core.internal.provisional.jobs.future We seem to go back and forth on this practice. If the package name has internal in the name, does it also need provisional? The p2 bundles use both internal.provisional so that is likely what we should do also. Is this right? If so I will create the described new plugin, and submit new patch that includes this plugin on the enhancement request. A question: For the test code, where (in the equinox test cases) should the test code go? Should it have a new test plugin as well? What about the JobsExecutor-based tests? Should these go in the jobs test bundle or somewhere else? Currently we have org.eclipse.core.tests.runtime which tests things like jobs, registry, preferences, common etc. and org.eclipse.osgi.tests which currently tests the framework and application model. I suggest you place the tests in org.eclipse.core.tests.runtime for now. You should probably open a bug against Equinox-Components to continue this discussion. Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Support for RFC 119
H Tom, Thanks for the responses. Follow up inline below. Scott Thomas Watson wrote: Comments in line below. Tom Scott Lewis wrote ECF is looking to implement OSGi 4.2 RFC 119 in the Galileo/ECF 3.0 release: This is great news. https://bugs.eclipse.org/bugs/show_bug.cgi?id=249240 After reading the RFC 119 spec, it seems that there are only a very few implications for equinox itself: 1) RFC 119 depends upon RFC 126 (which is the Service Registry Hooks rfc), which after inspecting the org.eclipse.osgi bundle has apparently been implemented in HEAD/3.5. Thanks to whoever did that! I'm testing/using it now and will immediately report any issues found. Thanks goes to BJ Hargrave for this. We look forward to you using this feature. This feature is also being used by OSGi members to implement the RI for RFC 119. 2) In the RFC 119 draft that I have, their is an addition of a new type for org.osgi.framework.ServiceException. From RFC 119: 5.2.2.2 Exception Handling There will be a new type of exception for the ServiceException: REMOTE. This type of exception is thrown when there is an issue with the distribution software used to covert between the protocol-specific and OSGi invocations. After looking at ServiceException, I see that that REMOTE type value is not currently defined in org.osgi.framework.ServiceException (on org.eclipse.osgi HEAD). How should this addition be properly affected? Should I open an enhancement request to add a REMOTE type and attach a patch to contribute an addition/change? (e.g.): Hmmm it looks like there is a gap here in the companion code provided by OSGi (org.osgi.* packages). I opened a bug against the enterprise expert group to sort this out. I suspect they should be defining a new exception (RemoteServiceException) which uses the SUBCLASSED ServiceException type. For now you can just throw a ServiceException of UNKNOWN or if you want you could just use your own value for the type until we sort this out. Ok, is this something I/we can track or is it OSGi members only? stuff deleted All new api defined by RFC 119 is being added to the following packages org.osgi.service.discovery org.osgi.service.distribution I have an open CQ to use the OSGi companion code from the R4.2 specification (see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795) The osgi-cmpn jar contains these two packages for R4.2. I think an ECF implementation would want to include these APIs and export it themselves instead of having some unrelated 'util' bundle export them from equinox. You can open another CQ for ECF and piggy back the one from above. OK done. The ECF CQ is: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2959 4) There are several new service property name constants. How/where should these be added? (on Constants? or some other/new interface for remote service properties?). The API contained in the packages above define several new constants. Are these the ones you are referring to? I'll take a look. I haven't seen the cmpn code before so if they are *not* there I'll bring it up again here. If there are others that belong in org.osgi.framework.Constants then please let me know and I will raise issues with OSGi. Yep. By my reading, with the addition of 2, and answers to 3 and 4 that there will be no more required additions/changes to Equinox in order to support RFC 119. Please let me know if I should open enhancement requests and create attachments...or do something else...to effect the necessary changes and additions. Thanks, Scott I look forward to working with you from an Equinox perspective to get this work started. Thanks much. One question: If we/ECF is going to have or create the bundle that exports the distribution provider and discovery interfaces from the r4.2 cmpn...should this bundle be in the equinox namespace (and if so what?) or should it be in the ecf namespace (i.e. in org.eclipse.ecf core bundle or some such)? We can work this out 1-1 if you prefer Tom...let me know if you would rather I contact you or equinox dev team directly to settle these questions. Thanks again, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] a future with futures
On this E4 enhancement request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777 there has been a long and fruitful discussion about supporting asynchronous programming (for E4 as well as other projects including ECF, p2, DSDP) by adding the concept of a 'future' to Equinox. Various designs have been proposed, and I think that there has been a good amount of convergence recently...i.e. see comment 121: https://bugs.eclipse.org/bugs/show_bug.cgi?id=253777#c121 for a recent summary. I would like to request that this contribution be considered for addition to Equinox for the Galileo release cycle. If there is more/other that I can do as a contributor please let me know. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] running startApp from equinox console
I'm trying to setup an Equinox server and run startApp from within the
console.
I'm successfully starting org.eclipse.equinox.app bundle upon framework
start, and so see the application commands in the console of the OSGi
server.
But when I give the startApp command in console, the exception below is
thrown. Here is the block of code from EclipseAppContainer (that is
doing the throwing). The launcherTracker.getService() call returns
null, and so the ApplicationException is thrown:
synchronized (this) {
appLauncher = (ApplicationLauncher)
launcherTracker.getService(); -- This getService() returns null
if (appLauncher == null) { -- this test succeeds
if (isDefault) { -- this is false
// we need to wait to allow the
ApplicationLauncher to get registered;
// save the handle to be launched as soon as the
ApplicationLauncher is available
defaultMainThreadAppHandle = appHandle;
return;
}
throw new
ApplicationException(ApplicationException.APPLICATION_INTERNAL_ERROR);
}
curDefaultApplicationListener = defaultAppListener;
curMissingAppLauncher = missingAppLauncher;
}
So my question is...why does the launcherTracker return null? Is there
some other bundle that has to be started in order to have an
ApplicationLauncher registered? If so, which one?
Thanksinadvance,
Scott
exception
osgi startApp org.eclipse.equinox.p2.installer.application
org.osgi.service.application.ApplicationException
at
org.eclipse.equinox.internal.app.EclipseAppContainer.launch(EclipseAppContainer.java:322)
at
org.eclipse.equinox.internal.app.EclipseAppDescriptor.launchSpecific(EclipseAppDescriptor.java:93)
at
org.osgi.service.application.ApplicationDescriptor.launch(ApplicationDescriptor.java:316)
at
org.eclipse.equinox.internal.app.AppCommands._startApp(AppCommands.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150)
at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:302)
at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:287)
at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:223)
at java.lang.Thread.run(Unknown Source)
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] running startApp from equinox console
Hi Thomas, Thanks for the info...this does the job. One other question: Is there a way to specify these application properties from inside the console 'startApp'? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] running startApp from equinox console
Thanks Thomas, I don't have a strong use case for application properties override, so I'll push for now. Scott Thomas Watson wrote: The threading/cardinality properties? There is currently no way to override the application properties specified by an applications extension. I suppose we could enhance the container to allow these types of properties to be specified in the Map which is use to launch an application (i.e. when calling ApplicationDescriptor.launch(Map)) Other option is to install a fragment that specifies the same application class but uses the threading/cardinality options you want. You can open an enhancement bug if you want to investigate overriding properties of an applications extension when launching an application. Tom Inactive hide details for Scott Lewis ---08/27/2008 04:05:03 PM---Hi Thomas,Scott Lewis ---08/27/2008 04:05:03 PM---Hi Thomas, From: Scott Lewis [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 08/27/2008 04:05 PM Subject: Re: [equinox-dev] running startApp from equinox console Hi Thomas, Thanks for the info...this does the job. One other question: Is there a way to specify these application properties from inside the console 'startApp'? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] P2 authoring reaches first milestone
Hi Henrik, Really Cool Stuff. I'm examining/trying it now. One comment I wanted to make on this list...you have a number of good questions about the p2 use of Namespaces and IDs on the wiki page (e.g. can new namespaces be added, what are constraints on IDs, etc). I just wanted to remark that ECF core has a package org.eclipse.ecf.identity that includes a Namespace abstract super class, ID and IIDFactory interfaces, and several built-in Namespaces...e.g. StringID, LongID, GUID (based upon base-64 encoded large number). There is also an extension point for adding new Namespaces. So I guess what I'm trying to say is that if these concepts (Namespace, ID, extensibility in namespaces and ID construction, etc) are desired/needed for P2 going forward, there is already a working implementation available in ECF core. We (obviously) use and extend it heavily...to represent service ids, user ids, group ids, file ids, etc. It has minimal requirements (none other than CDC 1.0/Foundation 1.0). Also...just FYI...we have been/are adding a persistent store for ECF IDs: http://wiki.eclipse.org/Storage/Retrieval_of_IDs%2C_IContainers_using_Equinox_Secure_Preferences This uses the newly added Equinox Secure Preferences to securely store/retrieve Namespaces and their IDs. Scott Henrik Lindberg wrote: Hi, I have now reached a first milestone in P2 IU authoring. This wikipage http://wiki.eclipse.org/Equinox_p2_Metadata_Authoring has screenshots of the editor. There are also instructions (at the top), where to find the editor and how run it. To summarize: - IU files can be created and edited - Support for undo/redo and interactive error messages I have some questions regarding certain fields, and what makes sense from an editing perspective. Some of those questions are on the wiki page. Feel free to add comments or ideas to the wiki page. What remains to be supported: - creation of fragment - creation of patch - lookup in repositories. - build/test stuff Looking forward to receiving comments. best regards Henrik Lindberg [EMAIL PROTECTED] ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] P2 authoring reaches first milestone
Scott Lewis wrote: stuff deleted and extend it heavily...to represent service ids, user ids, group ids, file ids, etc. It has minimal requirements (none other than CDC 1.0/Foundation 1.0). Sorry, I should have been clearer about this. It does also have a dep on org.eclipse.equinox.common (for IAdaptable, IAdapterManager, IStatus, etc) and the extension registry (for extension point processing). Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] linux read-only filesystems and p2?
Hi Folks, I was at Google yesterday, and a person there was having troubles with p2 because they were trying to do plugin installs with Eclipse p2 on a read only filesystem. I haven't tried this myself, so I may not have all the details described correctly, but are there any known issues with this and/or bugs in this area? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] p2 mixing extensions and services?
Hi Fredrik, Fredrik Alströmer wrote: stuff deleted As a hypothetical use-case you could probably also take remote invocation, if you have it as an OSGi service (for example) instead, there's nothing keeping the framework from giving you a proxy-implemenation doing RMI calls, which might be interesting in a distributed system, where the touchpoints are actually remote. Hypothetically. :) I can't think of a situation where this would be the case, but distributed systems are undeniably cool... ;) Yes, indeed. Just FYI...there is a new component beginning to use ECF remote services with p2...initially described here: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01570.html ECF is shortly moving to the runtime project, and so are likely to continue more fully in this vein. We welcome your and/or others participation. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] The metadataRepositories extension point
I agree that URIs would be desirable over URLs. One thing to point out though...there is no URI class in the CDC 1.0/Foundation 1.0 EE. That's the primary reason that the ECF filetransfer IFileIDFactory does not have a URI-based file id creation (it does have URL-based creation, of course), as we wanted this part of ECF 2.0.0 to support CDC 1.0/Foundation 1.0 EE. But for future versions I'm generally happy to move to CDC 1.1/Foundation 1.1 as a minimum runtime for ECF filetransfer. And I can see that CDC 1.1/Foundation 1.1 is the minimum EE for other parts of p2 already. Scott Pascal Rapicault wrote: It is exactly for the reason you have highlighted that we wanted to use URI instead of URLs and I want this to be fixed as we are starting shaping APIs Inactive hide details for Thomas Hallgren ---06/13/2008 05:42:29 AM---On some places in the p2 API's there are comments regardiThomas Hallgren ---06/13/2008 05:42:29 AM---On some places in the p2 API's there are comments regarding perhaps using URI's instead of URL's. I From: Thomas Hallgren [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 06/13/2008 05:42 AM Subject: Re: [equinox-dev] The metadataRepositories extension point On some places in the p2 API's there are comments regarding perhaps using URI's instead of URL's. I think that would be an excellent idea. A URI is not tied to the existence of a particular scheme so for a repository URI the scheme itself could be used to find the corresponding repository factory. We use this approach successfully in the spaces project where each space provider implements their own URI scheme. At present, I need to use URL's that points to non-existent things so that I eventually end up in my factory implementation where I can peruse the URL for it to make sense. It works but it's not very clean (nor efficient). Regards, Thomas Hallgren Thomas Hallgren wrote: I'm trying to understand how to use the org.eclipse.equinox.p2.metadata.repository.metadataRepositories extension point in order to register a factory for my new IMetadataRepositoryFactory. From what I can see the current implementation relies on a 'filter' called 'suffix' but I'm unable to see the correlation between this filter and the URL that is used to identify the repository. It would help me a great deal if someone could explain how I can make sure that the MetadataRepositoryManager finds my new IMetadataRepositoryFactory implementation. Thanks, Thomas Hallgren ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] ECF stream
My apologies...I forgot to notify this list. Thanks PaScaL for sending. Scott Pascal Rapicault wrote: Last week, Scott announced on the ECF mailing list that development leading to ECF 2.0 will be done in a branch called Release_2_0. Therefore, if you have ECF loaded in your workspace, please make sure to have the Release_2_0 branch of the 6 ECF project loaded. I have also updated the p2 psf file. PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] FYI: Remote provisioning using p2 and ECF
FYI, There's some interesting work just beginning on remote provisioning using p2 and ECF remote services described here: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01570.html Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [sec] use of Equinox secure storage
Hi John, Agreed RE: making life easier WRT authentication/account mgmt/single sign-on, etc. I'm hoping that Matt, Eric, Thomas, etc. will also work with us to take further advantage after 3.4 is out. Scott John Arthorne wrote: Great news! Our attempts at handling authentication in p2 were not very successful due to interaction with java.net.Authenticator, and the cumbersome pattern of catching exceptions, trying to guess if they are authentication failures, prompting and then retrying. Hopefully pushing this down into ECF will make life easier for all clients of ECF including p2. John *Scott Lewis [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 05/14/2008 01:15 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] [sec] use of Equinox secure storage ECF has begun some work on using the new Equinox secure storage to persist ECF IDs (which are used by ECF to uniquely identify users, accounts, services, remote resources, other things). After Ganymede, we expect this to be usable for (e.g.) automatic login to remote accounts, single-sign on, local storage of user-data/properties by accounts, etc. For those that are interested, please see/join bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=232116 Also see mailing list posting: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg01553.html ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] mysterious problem with classloader
Hi Equinoxers, ECF has a discovery provider that is based upon SLP (Service Locator Protocol...RFC 2608). The provider plugin depends upon/uses the java implementation of SLP called jSLP [1], originally developed by Jan Rellermeyer, who is now an ECF committer and has contributed jSLP to Orbit. Short summary: ECF SLP Provider (org.eclipse.ecf.provider.jslp) depends upon: jSLP Bundle from Orbit (ch.ethz.iks.slp) depends upon ECF Core/ECF Discovery API (org.eclipse.ecf/org.eclipse.ecf.discovery) We seem to be having some troubles with the lazy activation of SLP provider/jSLP bundle and classload failures. The details are described in this bug and the attached M7 log: https://bugs.eclipse.org/bugs/show_bug.cgi?id=229922 Any thoughts about what's going on here...or thoughts about how to further diagnose? It doesn't seem to be completely deterministic. Thanksinadvance, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] New API method in ECF (org.eclipse.ecf.identity) since 3.4M6
Hi Olivier, This utility method was added as part of a bug fix to one of our provider bundles, and the committer didn't initially realize that the 6 ECF bundles going into the platform integration build were now under API freeze. When he realized that this method was added to a bundle under API freeze he removed the method and it's no longer present (in M7). But it did get into the integration build, since it's done automatically and I didn't know about the change until after the integration build had occurred. So this isn't deliberate...ECF has as a policy to freeze the API on these bundles at M6+0...in keeping with the platform. It was simply an honest mistake. My apologies for causing work for everyone. LMK if I should do something more/other to resolve this. Scott Olivier Thomann wrote: Hi, I noticed in the last integration build that a new method org.eclipse.ecf.core.util.StringUtils#String replaceAllIgnoreCase(String, String, String) has been added since 3.4M6. It is located in the bundle org.eclipse.ecf.identity. This is considered to be a new API added after API freeze and therefore it would require PMC approval. I don't know whether ecf bundles are part of the API freeze or not. If not, then I should add this entry to the exclude list. If yes, then it would be nice to send a note to the eclipse-pmc mailing list to request approval for the new API with a bug report associated with this change. The template is: GOALS/BENEFITS: ... AFFECTED BUGS: - https://bugs.eclipse.org/bugs/show_bug.cgi?id=myBugID RISKS: ... PERFORMANCE IMPACTS: ... Like this we can then add it to the exclude list with the appropriate bug id reference and we have a tracecability of API changes post 3.4M6a. Thank you, Olivier ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] New API method in ECF (org.eclipse.ecf.identity) since 3.4M6
Hi Olivier, Olivier Thomann wrote: Hi Scott, This didn't cause any work for anybody except the build machine :-). The check is done during each build. It was easy to detect it without any extra work. That's nice to know...maybe releng would be willing to share the scripts to run the PDE API checker (I assume that's what's doing this)...and we/others could add such a check to our build also. Since this is not intended to be part of the 3.4 release and I expect it to be removed from the next integration build you provide to p2, I won't add it to the exclude list. Are you ok with this ? Sure. For my info...what does it mean to be on the exclude list? Excluded from what? As soon as the new drop will be used by an integration build, the API freeze check won't report it anymore. Great. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [prov] handing of patches
With the recent changes/additions for patch handling, will p2 now allow the update/patch of platform plugins (including, for example, ECF6)? Reason I ask...ECF currently has to create separate builds (and ask people to use different update sites) for ECF-on-eclipse 3.3-3.4M5, and ECF-on-eclipse 3.4M6+ because of the p2 'patch problem'. Just want to know if this is still an issue (my expectation is yes this is still an issue, but would like to be sure). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [p2] compile error?
Hey all, In 3.4M6a, I just updated to the latest of all the projects in org.eclipse.equinox.p2.releng/projectSet.psf I'm getting a compile error in org.eclipse.equinox.p2.reconciler.dropins/Activator:244: ... Location eclipseHome = (Location) ServiceHelper.getService(getContext(), Location.class.getName(), Location.ECLIPSE_HOME_FILTER); ... DescriptionResourcePathLocationType Location.ECLIPSE_HOME_FILTER cannot be resolvedActivator.java org.eclipse.equinox.p2.reconciler.dropins/src/org/eclipse/equinox/internal/p2/reconciler/dropins line 244Java Problem This is in Eclipse 3.4m6a. The interface org.eclipse.osgi.service.datalocation.Location seens not to have an ECLIPSE_HOME_FILTER (has INSTANCE_FILTER, INSTALL_FILTER, etc). Is there something I'm doing wrong for p2 setup, etc? Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Hi Pascal and all, Some additional participation opportunities: - Multi-threaded downloads using ECF - User interface for configuring/pausing/resuming/managing downloads - Use/testing of bittorrent for downloads (and/or other protocols) - Integration/UI of dynamic repository discovery, both in admin app and Eclipse Scott Pascal Rapicault wrote: I'm calling out for participation from the community on the following item: - Director application. This consists in improving the interface of our command line client and ensure that it replaces the equivalent functionality available in update manager. - Repository mirroring application. This consists in improving the mirroring application, which is key to selectively publish content from one repository to another. - Action based contribution to touchpoints. This consists in revisiting the way actions are contributed to touchpoints by allowing them to be shared across touchpoints. If you are interested in any of these areas, please let us know. Thank you, PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Hi Folks, Sorry, I realize I may have stepped on (Susan's) toes WRT the UI items below. Susan can comment (if she wants) on whether participation on the below fits in with her/others plans in those areas. Scott Scott Lewis wrote: Hi Pascal and all, Some additional participation opportunities: - Multi-threaded downloads using ECF - User interface for configuring/pausing/resuming/managing downloads - Use/testing of bittorrent for downloads (and/or other protocols) - Integration/UI of dynamic repository discovery, both in admin app and Eclipse Scott Pascal Rapicault wrote: I'm calling out for participation from the community on the following item: - Director application. This consists in improving the interface of our command line client and ensure that it replaces the equivalent functionality available in update manager. - Repository mirroring application. This consists in improving the mirroring application, which is key to selectively publish content from one repository to another. - Action based contribution to touchpoints. This consists in revisiting the way actions are contributed to touchpoints by allowing them to be shared across touchpoints. If you are interested in any of these areas, please let us know. Thank you, PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Hi Pascal, Pascal Rapicault wrote: - Multi-threaded downloads using ECF What do you have in mind here that is different from what we already have in today? We currently are not using multiple threads to download different sections of a single (large) file...e.g. thread 1: byte 1-5M, thread 2: byte 5M+1 to end. ECF has the API to do this (via IFileRangeSpecification) but I don't think it's yet being used. For relatively high bandwidth networks such an approach would be useful. It would also be useful to be able to configure things like # of threads per file/size of block. Basically adding download strategies as discussed last fall, and UI to configure. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] Participation opportunity
Hi Jeff, Jeff McAffer wrote: While we are all loving each other I feel obliged to say that the focus of this call to action was (I believe) helping p2 *ship in 3.4* with a reasonable function level. It wasn't apparent to me that the original participation solicitation was scoped to be 'helping p2 ship in 3.4'...but if that's the intention then that's cool. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] ECF bundles not up to date in M6
Hi DJ, Thanks for the explanation. If there is something I can do for future to prevent the replication not happening in time (e.g. put stuff on download.eclipse.org by a certain time on Monday, please let me know). RE: the 'patch' problem. I imagine ECF won't be the only ones facing this issue...so do let the community know if there is something to work on here (is there a bug(s) associated with this?). Thanks, Scott DJ Houghton wrote: Scott, the problem with the ECF JARs earlier this week was that they hadn't replicated to our local servers here. So when people (Kim/Pascal) accessed the URLs for the JARs from home it was all good but when the build machine tried, it was redirected to a local machine which didn't have the JARs yet. The easiest fix at the time was to revert our contribution to the one from the previous map file so that's what I did. Like Pascal mentions, we will look into moving up to the new versions. The idea of dropping higher versions of bundles into your dropins folder is referred to around here at the patch problem. It is on the list but it is not implemented yet. Currently the workaround is to either use the same bundle versions when exporting, or update the bundle.info file manually with the correct information. [EMAIL PROTECTED] wrote on 04/02/2008 12:46:33 AM: Hi Pascal, Strange...as I'm quite certain I checked 3/31 afternoon that the jars referenced in this map http://download.eclipse.org/technology/ecf/integration/ecf.filetransfer.map were replicated OK. Even so, this was after M6 build (sunday) anyway. But this brings up a question for us: If people use the dropins and/or plugins directory install, and they put a newer version of a plugin that already exists/is installed as part of platform, what happens? Bad things/is this to be avoided? or can it be safely done? Thanks, Scott Pascal Rapicault wrote: I'm sorry about the problems this can cause the ECF users, however we tried moving to this most recent build but as you can see, it failed finding the jars on the server during the build http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg11579.html In case of a rebuild we will be looking into addressing this. From: Scott Lewis [EMAIL PROTECTED] To: Equinox development mailing list equinox- [EMAIL PROTECTED] Date: 04/01/2008 09:38 PM Subject:[equinox-dev] [p2] ECF bundles not up to date in M6 Howday p2'ers, The M6 release of Eclipse/p2 seems to have used a relatively old integration build of the 4 ECF bundles (i.e. they have qualifier v20080317-0809 rather than the 20080324 integration build as I expected from this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 This is not tragic, but it causes us a little bit of consternation because there were some very small API additions for ECF filetransfer during the week of the 17th, and these obviously didn't get into M6 of platform. This means that the next milestone of ECF will include these small API additions...and I wanted to let everyone know this doesn't constitute an API freeze breach...as ECF's filetransfer bundles are frozen at this point (but M6 of platform didn't get these additions during week of 24th). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [p2] ECF bundles not up to date in M6
Howday p2'ers, The M6 release of Eclipse/p2 seems to have used a relatively old integration build of the 4 ECF bundles (i.e. they have qualifier v20080317-0809 rather than the 20080324 integration build as I expected from this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 This is not tragic, but it causes us a little bit of consternation because there were some very small API additions for ECF filetransfer during the week of the 17th, and these obviously didn't get into M6 of platform. This means that the next milestone of ECF will include these small API additions...and I wanted to let everyone know this doesn't constitute an API freeze breach...as ECF's filetransfer bundles are frozen at this point (but M6 of platform didn't get these additions during week of 24th). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [p2] ECF bundles not up to date in M6
Hi Pascal, Strange...as I'm quite certain I checked 3/31 afternoon that the jars referenced in this map http://download.eclipse.org/technology/ecf/integration/ecf.filetransfer.map were replicated OK. Even so, this was after M6 build (sunday) anyway. But this brings up a question for us: If people use the dropins and/or plugins directory install, and they put a newer version of a plugin that already exists/is installed as part of platform, what happens? Bad things/is this to be avoided? or can it be safely done? Thanks, Scott Pascal Rapicault wrote: I'm sorry about the problems this can cause the ECF users, however we tried moving to this most recent build but as you can see, it failed finding the jars on the server during the build http://dev.eclipse.org/mhonarc/lists/platform-releng-dev/msg11579.html In case of a rebuild we will be looking into addressing this. From: Scott Lewis [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 04/01/2008 09:38 PM Subject:[equinox-dev] [p2] ECF bundles not up to date in M6 Howday p2'ers, The M6 release of Eclipse/p2 seems to have used a relatively old integration build of the 4 ECF bundles (i.e. they have qualifier v20080317-0809 rather than the 20080324 integration build as I expected from this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219499 This is not tragic, but it causes us a little bit of consternation because there were some very small API additions for ECF filetransfer during the week of the 17th, and these obviously didn't get into M6 of platform. This means that the next milestone of ECF will include these small API additions...and I wanted to let everyone know this doesn't constitute an API freeze breach...as ECF's filetransfer bundles are frozen at this point (but M6 of platform didn't get these additions during week of 24th). Thanks, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] peer-to-peer downloads (ECF)
Hi Alessandro, Alessandro Mottadelli wrote: Scott, thanks for the pointer and info. To implement the described use case (all clients in the lan need to pull something from the wan) I was thinking to something different (maybe simpler?) than mirroring. My first idea was a sort of cooperative download, that is each client ask its peers on the lan if they are already downloading a give file from the wan and eventually waits for the file to become available on the lan. I don't (yet) have an in-depth knowledge of ECF, but -given its scope- my hope is that this scenario could be easily set up. It would not be a 'big deal' to implement what you describe using ECF. The pieces would be: 1) ECF discovery for discovering lan-based peers that implement a given service (for a service that you define) 2) ECF emote services for 'asking peers on the lan if they are already downloading a given file' and/or exchanging other meta-data. We have recently done an example of using remote services discovered using remote services, in case you are interested: http://wiki.eclipse.org/Discovery_of_Remote_Services Also there is an ongoing discussion about the remote services example on the ecf newsgroup now: news:eclipse.technology.ecf. You might also want to consider joining the ecf-dev mailing list: https://dev.eclipse.org/mailman/listinfo/ecf-dev Does all this make sense? Yes, indeed. Please let us know if we can help get you going. The remote services and discovery work are relatively new...although coming along now that jSLP (service locator protocol for discovery) and r-OSGi (well-known remote services impl) are in the mix. SLP is distributed with ECF M5, and r-OSGi will be also...as soon as the legal approval has been received. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] peer-to-peer downloads (ECF)
Pascal Rapicault wrote: Another approach could consist in having a repo that uses bit torrent has its underlying transport. Good point :). ECF does have a bittorrent provider as well: CVS /cvsroot/technology/org.eclipse.ecf/providers/org.eclipse.ecf.provider.bittorrent which depends upon /cvsroot/technology/org.eclipse.ecf/incubation/plugins/org.eclipse.bittorrent The URL protocol type is specified in the provider plugin as 'torrent' Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] ECF discovery of artifact and metadata repos
Jeff McAffer wrote: There currently is no support for known repositories. At least not that I know of. :-) I created enhancement request https://bugs.eclipse.org/bugs/show_bug.cgi?id=218534 for this. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] ECF discovery of artifact and metadata repos
Hi Jeff, Jeff McAffer wrote: Unless it has changed since I messed with it, that FileServerApplication was some hacky attempt at putting an HTTP server on front of some repos. It may be an ok starting point but i'd not put too much weight on it. Perhaps we should just have one thing that exposes a set of repos through HTTP and is optionally discoverable? Does that make sense? Sure. Sounds fine. Adding optional discoverability will be easy. As for hte UI, p2 users, admin or otherwise, likely have no interest in discovery. They just want to nkow what repos are available to be added to their system. So, for example, when someone goes to add a repo, they might have an option of choosing from known repos. That way the list of available repos can be supplied through discovery, static list, dynamic downloaed list, hard coded, ... I agree. The ECF service discovery view will not make an appearance...rather the discovered artifact and meta-data repos will just appear in a 'known repos' UI. So I suppose the 'known repos' UI has to added...I guess as another button (and associated shell/dialog) in the add repo dialog? Unless it's already there and I haven't seen it. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] ECF discovery of artifact and metadata repos
Hi Jeff, Jeff McAffer wrote: There currently is no support for known repositories. At least not that I know of. :-) At various times we talked about priming the repo list etc in installed configurations but that would likely have been with loaded repos. Is discovery expensive? For example, if someone clicked an Add... button would it make sense to do the discovery then or is this something you essentially do in the background periodically or allow the user to drive a look for repositories button? The discovery providers do background discovery. They expose access to discovered services via an IDiscoveryService (OSGi service defined by ECF discovery API). So a client can just get the IDiscoveryService(s) via service registry and use it ask for any discovered services of the appropriate type. As you know the schedule for 1.0 is very tight so Susan and others will have to comment on the feasibility of getting this in. Having said that, we can always have another route that is less well integrated and comes from the incubator at the beginning and then gets integrated over time. ok. Scott Jeff Scott Lewis wrote: Hi Jeff, Jeff McAffer wrote: Unless it has changed since I messed with it, that FileServerApplication was some hacky attempt at putting an HTTP server on front of some repos. It may be an ok starting point but i'd not put too much weight on it. Perhaps we should just have one thing that exposes a set of repos through HTTP and is optionally discoverable? Does that make sense? Sure. Sounds fine. Adding optional discoverability will be easy. As for hte UI, p2 users, admin or otherwise, likely have no interest in discovery. They just want to nkow what repos are available to be added to their system. So, for example, when someone goes to add a repo, they might have an option of choosing from known repos. That way the list of available repos can be supplied through discovery, static list, dynamic downloaed list, hard coded, ... I agree. The ECF service discovery view will not make an appearance...rather the discovered artifact and meta-data repos will just appear in a 'known repos' UI. So I suppose the 'known repos' UI has to added...I guess as another button (and associated shell/dialog) in the add repo dialog? Unless it's already there and I haven't seen it. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] ECF discovery of artifact and metadata repos
Initially, I'm thinking of setting up a discoverable http server to expose p2 meta-data and artifact repos. I noticed that there is an Equinox application: FileServerApplication (in org.eclipse.equinox.p2.tools plugin). Would it be OK to add discovery to this app (via patches)? Or should I create a new separate DiscoverableFileServerApplication? Also, would there be any interest in adding a discovery client to the ProvAdminUI? We have a general service discovery view in ECF http://wiki.eclipse.org/Update_Site_Discovery http://wiki.eclipse.org/Discovery_of_Remote_Services but it would be desirable to have a UI with less detail, that only shows meta-data and artifact repos rather than all services...and doesn't show all the details of the service properties as the ECF discovery view does. Scott John Arthorne wrote: Hi Scott, repository locations are simply represented as a URL. Since both metadata and artifact repositories are pluggable via extension point, any valid URL could potentially represent a repository. Currently the one way to find out if a give URL actually represents a repository is by calling loadRepository(URL, ...) on either IMetadataRepositoryManager or IArtifactRepositoryManager. Hope that helps get you started... John *Scott Lewis [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 02/05/2008 12:08 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] [prov] ECF discovery of artifact and metadata repos In prep for EclipseCon, the ECF team would like to create a demo that discovers p2 artifact and metadata repos. ECF has a discovery API [1], now implemented with both zeroconf/bonjour and SLP providers [2]. We've recently done an example that discovers update sites on lan [3]. So, my main question is: for discovering artifact and metadata repos, what is the necessary meta-meta-data? (data about location/access to repos). Is it simply an URL, or is there more to it? Pointers into p2 code desired...as I need to do that anyway. Thanks, Scott [1] http://wiki.eclipse.org/ECF_API_Docs#Discovery_API [2] http://www.lemmster.de/blog/index.php/2008/02/03/168/ [3] http://wiki.eclipse.org/Update_Site_Discovery ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Example or test code for framework adaptor
Is there any example and/or test code for http://wiki.eclipse.org/Adaptor_Hooks ? Thanksinadvance, Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] [sec] questions about EE for security
Hi Folks, Some questions: I thought I understood (from Equinox Summit) that the recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC 1.1/Foundation 1.1. I see from looking at the equinox JAAS integration bundles (e.g. org.eclipse.equinox.security.auth) that the runtime environment minimum for those bundles is set to JRE 1.4. I understand this, as the JAAS work depends upon packages like javax.security.auth, and javax.security.auth.login, etc. which do not seem to be in CDC 1.1/Foundation 1.1. So maybe I just answered my own question: it seems that the JAAS security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC 1.1/Foundation 1.1). So the implicit (to me anyway) idea here is that bundles that use/extend/depend upon the JAAS security integration also obviously must assume JRE 1.4 and not just CDC 1.1. Correct? Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: AW: [equinox-dev] OSGi Logger Service - Eclipse Plugin Logger
Thanks Niclas. I'm really looking for something much more trivial than Pax logging :)...so for the time being I implemented LogService myself. But thanks for the info, I may very well use Pax logging in the future. One question: what does the Pax logging API bundle depend upon? (i.e. extension registry?, others?). Scott Niclas Hedhman wrote: On Tuesday 09 October 2007 04:28, Scott Lewis wrote: Is there any existing LogService implementation that just prints to System.out/System.err...that is in a bundle present for *all* Equinox impls (not just Eclipse)? Equinox in its purest form has no bundles in it besides the system bundle, and IIRC the internal Equinox logger is not exposed. That is, is there some basic LogService that can be used as a last-ditch logging mechanism (if no other LogService is available)? Pax Logging attempts to provide both OSGi Log Service functionality as well as bridging of third-party legacy APIs such as; JDK Logging Log4J Jakarta Commons Logging Avalon Logging API SLF4J KnopflerFish Log Pax Logging consists of 2 bundles. The API bundle must always be present and is what all the legacy code will 'bind' into when they lookup a logger the respective way. The Service bundle can come and go to allow for upgrade of the Log4J driven bakend, without taking down the entire application. When the Service is not available, the API will revert to System.out (a buffering version is under construction). You find Pax Logging at OPS4J, http://wiki.ops4j.org Cheers ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] processing steps, restartable downloads and ECF
Hi Jeff, Jeff McAffer wrote: Thanks to Stefan we have been introducing the notion of ProcessingSteps to munge the content as it is downloaded from an artifact repository. This allows for things like inline MD5 digest checking, unpack200 processing, delta merging, signature checking, ... All great stuff. Pascal just raised a very interesting question. How do we handle restarting? Some background. In the current prototype (in my workspace, not yet in CVS) there is a chain of ProcessingStep objects. Each step is actually an OutputStream that knows about the next step (output stream) in the chain. When a byte is written to step/stream N, it is processed (counted, transformed, ...) and then the result passed on to step N+1. This repeats until finally the content gets to the last stream in the chain which is usually a FileOutputStream of some sort and so the content is then written to disk. All is well. Now, what happens if we crash or the user somehow pauses the download? The content is partially processed/transformed but it would likely be too costly for each step to persist its intermediate results. It would be more likely that somehow the raw content coming in to the head of the chain of steps is cached and then when the download is restarted after a crash/exit, the chain is recreated and the download is effectively replayed through the chain from the cache. When that is done, the further content from the source would then be pushed through the chain. So, two questions. Does this make sense? and if so, how should we implement this? I wonder if ECF has some technology/support/designs in this area since it seems they support restartable downloads. Scott? Unfortunately not as much as we would like. We do have API support for pausing/resuming downloads (IFileTransferPausable), and the existing impls do naively support this interface, but we need/want to add further/better implementation support (e.g. direct protocol support for protocols that have pause/resume, partial file caching, etc). Actually, I'm a little surprised that you have so far passed the ProcessingSteps as output streams directly to the ECF OutputStream, as I was expecting that you would have a temporary file to receive the file contents, and then when the file reception is done *then* apply the ProcessingSteps. But in any event, we can add impl support for pause/resume/caching etc to the ECF receive implementations w/o changing API to support required use cases. I would appreciate a little better understanding of the existing ProcessingSteps and their function...so could someone point me at the relevant packages/classes and I'll take more of a look? Seems like this would also be a good topic for the upcoming Equinox Summit: what enhancements are needed for file transfer both at API and impl: e.g. pause/resume enhancements, file caching, monitoring/transfer statistics collection?, support more/other providers, etc. Scott Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox coding conventions
I updated the following ECF projects to use the Equinox code conventions. I also updated each project to format java files when saving. org.eclipse.ecf org.eclipse.ecf.core.identity org.eclipse.ecf.filetransfer org.eclipse.ecf.provider.filetransfer Since prov is currently using an old tag of ecf plugins you won't see this immediately (until prov is using ECF HEAD or subsequent tag). Scott Thomas Watson wrote: I updated the following equinox projects to have the latest Equinox code convention settings. I also updated each project to format java files when saving. You may notice additional changes when saving java files and creating patches. In this case the code was probably not correctly formatted. org.eclipse.equinox.app org.eclipse.equinox.common org.eclipse.equinox.device org.eclipse.equinox.event org.eclipse.equinox.http org.eclipse.equinox.http.jetty org.eclipse.equinox.http.registry org.eclipse.equinox.http.servlet org.eclipse.equinox.http.servletbridge org.eclipse.equinox.jsp.jasper org.eclipse.equinox.jsp.jasper.registry org.eclipse.equinox.launcher org.eclipse.equinox.log org.eclipse.equinox.metatype org.eclipse.equinox.preferences org.eclipse.equinox.registry org.eclipse.equinox.servletbridge org.eclipse.equinox.supplement org.eclipse.equinox.useradmin org.eclipse.osgi Because of bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=200207 the org.eclipse.osgi project cannot set the Malformed Javadoc compiler settings to Error. All other projects do have this set to Error. Tom *John Arthorne [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 08/20/2007 04:35 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] Equinox coding conventions As more and more people are contributing to Equinox (Thanks!) we thought it would make sense to point out the Equinox coding conventions: *_ _*_ _*_http://www.eclipse.org/equinox/documents/coding.php_* In some ways these sort of guidelines can show up as restricting one's freedom of artistic code formatting or variable naming expression. In practice however, having a common set of coding practices is one of the ingredients of our success. We have a large and growing body of committers in Equinox, and a much larger community looking in and trying to understand what we write. Having common and consistent conventions makes our code easier to read and work with for everyone. In particular, check out the section around formatter and compiler settings. These we should setup in each project so that everyone is seeing the same errors and formatting the same way. We're also going to experiment with enabling automatic formatting and code cleanup on save, so we can just forget about these issues and let the tools do the work. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [sec] target EEs for JAAS integration work?
Hi Matt, Thanks for comments. A couple of follow ups. Matt Flaherty wrote: Hmmm... Looks like CDC/Foundation does not include the javax.security.auth.* packages. I'm not sure if a JAAS implementation could be dropped on top of it, but I wouldn't be surprised if it could. JAAS is pretty thin. With respect to a LoginModule for 3.4, I expect we will develop several (or explain how to use those in a typical JRE). The default configuration will probably work with a standard format JKS/JCEKS stored in an appropriate place for the platform (workspace, etc). It would be good to make these login modules extensible (via extension point perhaps) so that other bundles (e.g. ECF) can hook into login process of an existing app that uses these login modules (e.g. Eclipse) and (e.g.) add principals and/or credentials to Subject during login or commit and prior to setReadOnly(). If you like, I can/could create an enhancement request for this...let me know. I also could help with some of the programming for such a thing if desired. Scott ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
