[equinox-dev] IP CQs waiting on your team
equinox-dev, IPZilla records show that one or more of the projects on which you are developer are in need of attention. The following CQs have been in the 'awaiting_project' status for over 3 weeks and need your team to take action. rt.equinox: 6484 Apache Felix Resolver -- checkintocvs, nonepl, sourceandbinary, unmodified, 4 months ago https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6484 If you have any questions, please do not hesitate to contact your project lead, PMC member, or the EMO ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Project meta data is out of date for rt.equinox
Thomas, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page does not exist (projecturl = http://eclipse.org/equinox returns a 404) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] About the fwk rewrite
On 2012-09-04, at 10:23 AM, Thomas Watson wrote: > I will be working on documenting the goals and design of the generic model > over the coming weeks. No, I did not rework the way EclipseStarter reads > config.ini. EclipseStarter is just a launcher (that ends up using > org.osgi.framework.launch API). It still reads the config.ini for framework > configuration and it still continues to install the initial bundles from the > osgi.bundles property. I tried to keep this flow so that the new framework > implementation could be boot strapped without tons of changes to the rest of > Eclipse. For example, you should be able to launch a self-hosted eclipse > with the new implementation from a Juno installation. > I was asking because I thought this could be a nice way to change the way files are laid out on disk to make them easier to manage (e.g. have multiple config files that are read and merged at runtime rather than one file). However this would most likely require changes to p2 and PDE which is probably way broader than the scope of the work desired here. > But I did greatly simplify how the framework stores its persistent > information on disk. That is really the only part the core framework > controls as far as layout on disk is concerned. All other aspects are > handled by things outside of the core framework (e.g. the plugins folder the > configuration/ folder etc.). > > For the Felix comment. Have I thought of just using the Felix Framework as > is? Sure, but I think competition is good and I think it is in the best > interest of Eclipse to continue to have ownership of one of the core > technologies it is running on. Also, I want to point out that the OSGi > Resolver specification is a very small part of a proper OSGi Framework > implementation. It is a large leap to go from using one small part of the > felix project to moving completely over to the Felix OSGi Framework > implementation. Also, I should point out that the Felix Framework is not > currently using the OSGi Enterprise Specified Resolver service > implementation. It should not be a large amount of work for them to do that > but, as of right now, the OSGi Resolver service implementation in Felix is a > separate bundle. Richard Hall hopes to eventually merge that implementation > into the Felix framework. > I was curious since after all collaboration may have been as fruitful than co-opetition. Thanks for taking the time to answer. Pascal > > Tom > > > > Pascal Rapicault ---09/04/2012 06:12:46 AM---I have a couple > questions about the framework rewrite: > > > From: > > Pascal Rapicault > > To: > > Equinox development mailing list , > > Date: > > 09/04/2012 06:12 AM > > Subject: > > [equinox-dev] About the fwk rewrite > > > > I have a couple questions about the framework rewrite: > - Is there a document describing the goals of the rewrite > - Is there any plan to change how things work on disk? (e.g. config.ini) > - Since we are sharing the resolver with Felix, have we considered simply > reusing felix in its entirety? > > 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] About the fwk rewrite
I will be working on documenting the goals and design of the generic model over the coming weeks. No, I did not rework the way EclipseStarter reads config.ini. EclipseStarter is just a launcher (that ends up using org.osgi.framework.launch API). It still reads the config.ini for framework configuration and it still continues to install the initial bundles from the osgi.bundles property. I tried to keep this flow so that the new framework implementation could be boot strapped without tons of changes to the rest of Eclipse. For example, you should be able to launch a self-hosted eclipse with the new implementation from a Juno installation. But I did greatly simplify how the framework stores its persistent information on disk. That is really the only part the core framework controls as far as layout on disk is concerned. All other aspects are handled by things outside of the core framework (e.g. the plugins folder the configuration/ folder etc.). For the Felix comment. Have I thought of just using the Felix Framework as is? Sure, but I think competition is good and I think it is in the best interest of Eclipse to continue to have ownership of one of the core technologies it is running on. Also, I want to point out that the OSGi Resolver specification is a very small part of a proper OSGi Framework implementation. It is a large leap to go from using one small part of the felix project to moving completely over to the Felix OSGi Framework implementation. Also, I should point out that the Felix Framework is not currently using the OSGi Enterprise Specified Resolver service implementation. It should not be a large amount of work for them to do that but, as of right now, the OSGi Resolver service implementation in Felix is a separate bundle. Richard Hall hopes to eventually merge that implementation into the Felix framework. Tom |> | From: | |> >--| |Pascal Rapicault | >--| |> | To:| |> >--| |Equinox development mailing list , | >--| |> | Date: | |> >--| |09/04/2012 06:12 AM | >--| |> | Subject: | |> >--| |[equinox-dev] About the fwk rewrite | >--| I have a couple questions about the framework rewrite: - Is there a document describing the goals of the rewrite - Is there any plan to change how things work on disk? (e.g. config.ini) - Since we are sharing the resolver with Felix, have we considered simply reusing felix in its entirety? 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] New framework?
On 09/04/2012 03:47 PM, Thomas Watson wrote: Yes, in my original post I stated this: - all equinox framework extension hook implementations will need to be migrated to new hooks. Sorry I missed that. It should not be difficult, but some migration will have to occur to run on the new framework (need a better name for this than "new framework"). Knowing that there will be s.t. similar is already comforting :) thanks, Stephan ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] New framework?
Yes, in my original post I stated this: - all equinox framework extension hook implementations will need to be migrated to new hooks. It should not be difficult, but some migration will have to occur to run on the new framework (need a better name for this than "new framework"). Tom |> | From: | |> >--| |Stephan Herrmann | >--| |> | To:| |> >--| |equinox-dev@eclipse.org, | >--| |> | Date: | |> >--| |09/02/2012 12:32 PM | >--| |> | Subject: | |> >--| |Re: [equinox-dev] New framework? | >--| Hi Tom, On 08/30/2012 02:55 PM, Thomas Watson wrote: > In short, yes I have been working on re-implementing the core framework ... Will this affect any clients that use API not specified by OSGi? Specifically, what about the adapter hooks? Will anything change here? thanks, Stephan ___ 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 framework?
Hi Pascal, I plan to get more details on the new implementation soon. My hope is to be able to split out pieces of work that can be contributed to by others in the community. Up to this point I have simply been working on getting the base framework up and running on the generic model. Now that I have something kind of working I think it is time to get others involved if there is interest to do so. (Sorry for the delay in response. I sent that note last week and then promptly went on vacation). Tom |> | From: | |> >--| |Pascal Rapicault | >--| |> | To:| |> >--| |Equinox development mailing list , | >--| |> | Date: | |> >--| |08/30/2012 11:09 PM | >--| |> | Subject: | |> >--| |Re: [equinox-dev] New framework? | >--| Thanks for your detailed answer Tom. This is indeed a great news. I will encourage you to talk about this effort more widely and openly, as this is a perfect point in time to get more ppl involved with the project (though to some extent it may even be a tad late). Pascal On 2012-08-30, at 7:55 AM, Thomas Watson wrote: Hi Pascal, In short, yes I have been working on re-implementing the core framework on top of a generic capability and requirements model that was introduced in the Core OSGi Framework R5 specification and the OSGi resolver specification that was released with the OSGi Enterprise R5 specification. As Pascal knows the current Equinox Framework is built upon what I call a strongly typed dependency model where the package org.eclipse.osgi.service.resolver is at the center. This equinox resolver API is quite complex and a bit cumbersome in my opinion. Over the years it has become harder and harder to maintain and adapt as new requirement types (namespaces) get defined by the OSGi alliance. I started this effort in early summer when we thought Java Modularity was going to be released in Java 8. Java Modularity in the VM has the potential to add new dependency types and I wanted a framework implementation that would could easily prototype different dependency types. Instead of re-inventing a dependency model I decided to give the generic resource/capability/requirement model defined by OSGi R5 a try and rebase the framework implementation on that. I also decided not to implement my own OSGi Resolver implementation, but instead have chosen to collaborate with Richard Hall of the Apache Felix project and reuse the OSGi Resolver service implementation from the Felix project. This is why you will notice the occasional CQ note go by over the equinox-dev mailing list for the Felix Resolver. Overall I think the model is quite nice and I have been relatively happy with the implementation on top of this model. So far this has largely been a side project of my own (in a branch called twatson/container). Now that Java Modularity has been pushed out to Java 9 it is not urgent to push a radically different framework implementation into Kepler in preparation for Java Modularity and OSGi inter-op. With that said, I just recently got to the point where the "New framework" is getting
[equinox-dev] About the fwk rewrite
I have a couple questions about the framework rewrite: - Is there a document describing the goals of the rewrite - Is there any plan to change how things work on disk? (e.g. config.ini) - Since we are sharing the resolver with Felix, have we considered simply reusing felix in its entirety? Pascal ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] New framework?
Yes, adaptor hooks will be reworked. On 2012-09-02, at 1:31 PM, Stephan Herrmann wrote: > Hi Tom, > > On 08/30/2012 02:55 PM, Thomas Watson wrote: >> In short, yes I have been working on re-implementing the core framework ... > > Will this affect any clients that use API not specified by OSGi? > Specifically, what about the adapter hooks? Will anything change here? > > thanks, > Stephan > > ___ > 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
