Re: [equinox-dev] OBR
Great! Never having looked at the OBR implementation I can't really say which is the best path. I'm imagining that they have some code that reads repositories and some code that does resolution etc. What you need is the repository reading/parsing code. You would take that input information in and create a matching metadata repo and artifact repo object in p2. These would be primed with InstallableUnits (IUs) and artifact descriptors (respectively). From there on the OBR stuff would show up in p2 just like anything else and you can install etc using the p2 resolution strategies etc. Simon is doing something similar to this right now for update sites. He has a harder challenge because update sites don't have alot of metadata that is easily accessible. OBR seems to have more metadata so should be easier to integrate. I would recommend against trying to mix OBR's resolver and artifact fetching etc with that of p2. Feels like there will be conflicts and strangeness that cannot easily be contained in the UI and the end result will confuse users. Anyway, that is the path that I would go. Perhaps the best place to start is by looking at the p2 SimpleMetadataRepository and SimpleArtifactRepository classes as well as the org.eclipse.equinox.p2.updatesite bundle. These do not directly fit what you are doing but what you need is likely some combination of the two and something that can parse OBR repos. Note also that OBR has repo federation that is currently not supported by p2 (though it seems like a good idea). For now I would start simple and go for just one OBR repo at a time. You can find the Europa OBR repo at download.eclipse.org/releases/europa/repository.zip Does this make sense? Jeff Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/11/2008 10:46 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] OBR I agree with this and I'd be willing to actually write the OBR repository adaptor for p2. Would you agree that the simplest way to do that is probably to write it on top of the OBR API's and the Felix bundle repository implementation? - thomas Jeff McAffer wrote: We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same functionality as the OBR client but goes further towards solving the wider range of problems we see in the Eclipse provisioning space. I am all for supporting the use of OBR repositories in the sense that some people will make their function available that way. Given the p2 work however, it would be more interesting (to me at least) to write an OBR repository adaptor for p2 than to use the OBR api. Further, I hope that eclipse projects will feel comfortable making their content available as p2 repositories so that the Eclipse user community is not put in a position of having to get many different provisioning clients. In short, we in p2 would very much like to have your interaction and participation in making a provisioning solution that solves your needs. Jeff *Thomas Hallgren [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/11/2008 10:19 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] OBR Hi, I'm wonder if any work has been done within Eclipse to deal with OBR repositories, and if so, how can I get access to that. If not, and if no one has a better idea, I'm planning to start an IP-zilla to get the Apache Felix OBR approved since we will want to map that kind of repositories in Buckminster and also provide OBR's as an alternative to update sites in the spaces project. Regards, 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] Fw: [Bug 214801] [api tools] consider Export-Package as API
I don't think we can even contemplate this without full tooling automation. As Tom says, we struggle to keep our bundle version numbers correct as it is. We can maintain package versions manually up to a point, such as base framework packages and service packages, but any wider scope would become unmanageable. For most of the wider Eclipse team that rarely/never uses import package, there is no immediate need to version at the package level. Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/11/2008 03:45 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or plain old PDE) mark exports without versions as a warning/error by default or update each project settings in eclipse to make it an error. Now the question is what version would all the well established packages use? Most eclipse packages do not specify a version which means they have been using the default version of 0.0.0. If a package is being versioned for the first time what should its version be? - Start off using 1.0.0 - Use the Bundle-Version I favor using the Bundle-Version for well established packages because if we decide to add versions to the maintenance streams then we have room to downgrade the versions as appropriate. Completely new packages in a release should start off with version 1.0. I have been trying to version the exports of org.eclipse.osgi for the past few releases. It is hard to keep track of without tooling. Just look at how many times we forget to increment the bundle versions in Eclipse and that is just one version number per bundle to maintain. Now we will have to maintain each package version individually which is a much bigger task. Hopefully more advanced API tooling could detect that the API package has changed since last release and needs to be incremented. Does the new API tooling currently do something like this for Bundle-Version? Tom Jeff McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we keep letting slide. Are we going to ensure that all export package statements have version num From: Jeff McAffer [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 01/11/2008 02:17 PM Subject: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Tom raises a good point that we keep letting slide. Are we going to ensure that all export package statements have version numbers for 3.4? If we have API tooling for this then it would likely be reasonable to start doing. Even without tooling today, we could introduce version numbers based on the bundle version number for this release and then evolve from there (with tooling that will come in the future). Jeff - Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM - [EMAIL PROTECTED] 01/11/2008 10:50 AM To Jeff McAffer/Ottawa/[EMAIL PROTECTED] cc Subject [Bug 214801] [api tools] consider Export-Package as API https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801 Product/Component: PDE / Incubators --- Comment #2 from Thomas Watson [EMAIL PROTECTED] 2008-01-11 10:50:13 -0400 --- I agree with the concept. All exported packages which are not marked x-internal:=true should be versioned. Without this it makes using Import-Package very limiting because you cannot specify what version of the package you require. Packages marked as x-friends are questionable, but I can see friend bundles depending on a particular friend package version. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.___ 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 image/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gifimage/gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API
You need to, as part of the release process, use tooling, like japitools, to examine each package for changes, including non-backwards compatible changes. Then, at the end of the release, the package and bundle version numbers can be properly increased. We do this in the OSGi release process. BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] Office: +1 386 848 1781 Mobile: +1 386 848 3788 - Original Message - From: Thomas Watson Sent: 01/11/2008 01:45 PM To: Equinox development mailing list equinox-dev@eclipse.org Subject: Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or plain old PDE) mark exports without versions as a warning/error by default or update each project settings in eclipse to make it an error. Now the question is what version would all the well established packages use? Most eclipse packages do not specify a version which means they have been using the default version of 0.0.0. If a package is being versioned for the first time what should its version be? - Start off using 1.0.0 - Use the Bundle-Version I favor using the Bundle-Version for well established packages because if we decide to add versions to the maintenance streams then we have room to downgrade the versions as appropriate. Completely new packages in a release should start off with version 1.0. I have been trying to version the exports of org.eclipse.osgi for the past few releases. It is hard to keep track of without tooling. Just look at how many times we forget to increment the bundle versions in Eclipse and that is just one version number per bundle to maintain. Now we will have to maintain each package version individually which is a much bigger task. Hopefully more advanced API tooling could detect that the API package has changed since last release and needs to be incremented. Does the new API tooling currently do something like this for Bundle-Version? Tom From: Jeff McAffer [EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 01/11/2008 02:17 PM Subject:[equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API Tom raises a good point that we keep letting slide. Are we going to ensure that all export package statements have version numbers for 3.4? If we have API tooling for this then it would likely be reasonable to start doing. Even without tooling today, we could introduce version numbers based on the bundle version number for this release and then evolve from there (with tooling that will come in the future). Jeff - Forwarded by Jeff McAffer/Ottawa/IBM on 01/11/2008 01:22 PM - [EMAIL PROTECTED] rg To 01/11/2008 10:50 AM Jeff McAffer/Ottawa/[EMAIL PROTECTED] cc Subject [Bug 214801] [api tools] consider Export-Package as API https://bugs.eclipse.org/bugs/show_bug.cgi?id=214801 Product/Component: PDE / Incubators --- Comment #2 from Thomas Watson [EMAIL PROTECTED] 2008-01-11 10:50:13 -0400 --- I agree with the concept. All exported packages which are not marked x-internal:=true should be versioned. Without this it makes using Import-Package very limiting because you cannot specify what version of the package you require. Packages marked as x-friends are questionable, but I can see friend bundles depending on a particular friend package version. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gif___ 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] OBR
This makes a lot of sense. We don't have any use for the artifact fetching. Our objective is to be able to publish OSGi bundles to a generic repository (in the spaces project) and to be able to consume OBR's from Buckminster. The latter might well be Buckminster consuming p2 IU's that in turn maps to an OBR through the adapter that I intend to implement. Thanks for the pointers. I'll start there. - thomas Jeff McAffer wrote: Great! Never having looked at the OBR implementation I can't really say which is the best path. I'm imagining that they have some code that reads repositories and some code that does resolution etc. What you need is the repository reading/parsing code. You would take that input information in and create a matching metadata repo and artifact repo object in p2. These would be primed with InstallableUnits (IUs) and artifact descriptors (respectively). From there on the OBR stuff would show up in p2 just like anything else and you can install etc using the p2 resolution strategies etc. Simon is doing something similar to this right now for update sites. He has a harder challenge because update sites don't have alot of metadata that is easily accessible. OBR seems to have more metadata so should be easier to integrate. I would recommend against trying to mix OBR's resolver and artifact fetching etc with that of p2. Feels like there will be conflicts and strangeness that cannot easily be contained in the UI and the end result will confuse users. Anyway, that is the path that I would go. Perhaps the best place to start is by looking at the p2 SimpleMetadataRepository and SimpleArtifactRepository classes as well as the org.eclipse.equinox.p2.updatesite bundle. These do not directly fit what you are doing but what you need is likely some combination of the two and something that can parse OBR repos. Note also that OBR has repo federation that is currently not supported by p2 (though it seems like a good idea). For now I would start simple and go for just one OBR repo at a time. You can find the Europa OBR repo at download.eclipse.org/releases/europa/repository.zip Does this make sense? Jeff *Thomas Hallgren [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/11/2008 10:46 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] OBR I agree with this and I'd be willing to actually write the OBR repository adaptor for p2. Would you agree that the simplest way to do that is probably to write it on top of the OBR API's and the Felix bundle repository implementation? - thomas Jeff McAffer wrote: We currently do host an OBR repo with the major releases. Don't remember the URL but the required repository.xml/zip file is there for Callisto and Europa. The OBR client code may be interesting but our strategic direction is p2. For the most part p2 has (or can be made to have) the same functionality as the OBR client but goes further towards solving the wider range of problems we see in the Eclipse provisioning space. I am all for supporting the use of OBR repositories in the sense that some people will make their function available that way. Given the p2 work however, it would be more interesting (to me at least) to write an OBR repository adaptor for p2 than to use the OBR api. Further, I hope that eclipse projects will feel comfortable making their content available as p2 repositories so that the Eclipse user community is not put in a position of having to get many different provisioning clients. In short, we in p2 would very much like to have your interaction and participation in making a provisioning solution that solves your needs. Jeff *Thomas Hallgren [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/11/2008 10:19 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject [equinox-dev] OBR Hi, I'm wonder if any work has been done within Eclipse to deal with OBR repositories, and if so, how can I get access to that. If not, and if no one has a better idea, I'm planning to start an IP-zilla to get the Apache Felix OBR approved since we will want to map that kind of repositories in Buckminster and also provide OBR's as an alternative to update sites in the spaces project. Regards, 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
Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Package as API
I agree that tooling is needed in order to make this somewhat feasable. On the OSGi mailing list there was a question posted about using EMF on another framework implementation. One of the issues was that EMF uses Require-Bundle on org.eclipse.core.runtime. This ends up pulling in lots of dependencies, one of which is org.eclipse.osgi. This makes it impossible to use EMF on another Framework impl. If EMF instead used Import-Package to get its packages then it is conceivable that EMF could have its dependancies resolved in another Framework impl. But using Import-Package for the eclipse packages without versions is dangerous because you do not know what you will get. Eclipse team rarely uses Import-Package, this maybe because it is a bit harder. But for now I would advise against it because it is dangerous without versions. Until versions are established EMF should *not* move to Import-Package IMO. Tom From: John Arthorne [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/11/2008 03:27 PM Subject:Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Export-Packageas API I don't think we can even contemplate this without full tooling automation. As Tom says, we struggle to keep our bundle version numbers correct as it is. We can maintain package versions manually up to a point, such as base framework packages and service packages, but any wider scope would become unmanageable. For most of the wider Eclipse team that rarely/never uses import package, there is no immediate need to version at the package level. Thomas Watson [EMAIL PROTECTED] Sent by: To [EMAIL PROTECTED]Equinox development mailing list rg equinox-dev@eclipse.org cc 01/11/2008 03:45 PM Subject Re: [equinox-dev] Fw: [Bug 214801] [api tools] consider Please respond to Export-Packageas API Equinox development mailing list equinox-dev@eclipse.org Without tooling this will be difficult. If we wanted to use the big hammer approach the we would have the API tooling (or plain old PDE) mark exports without versions as a warning/error by default or update each project settings in eclipse to make it an error. Now the question is what version would all the well established packages use? Most eclipse packages do not specify a version which means they have been using the default version of 0.0.0. If a package is being versioned for the first time what should its version be? - Start off using 1.0.0 - Use the Bundle-Version I favor using the Bundle-Version for well established packages because if we decide to add versions to the maintenance streams then we have room to downgrade the versions as appropriate. Completely new packages in a release should start off with version 1.0. I have been trying to version the exports of org.eclipse.osgi for the past few releases. It is hard to keep track of without tooling. Just look at how many times we forget to increment the bundle versions in Eclipse and that is just one version number per bundle to maintain. Now we will have to maintain each package version individually which is a much bigger task. Hopefully more advanced API tooling could detect that the API package has changed since last release and needs to be incremented. Does the new API tooling currently do something like this for Bundle-Version? Tom Inactive hide details for Jeff McAffer ---01/11/2008 02:17:11 PM---Tom raises a good point that we keep letting slide. Are we gJeff McAffer ---01 /11/2008
