Community
Participate
Working Groups
Build Identifier: 2.1.0.M03-incubation The P2 publishing was already discussed in https://issuetracker.springsource.com/browse/DMS-2537 The problems with the approaches described in the DMS issue are unfortunately still not solved so the only option available is to launch the P2 publisher in standalone VM (and OSGi environment). The P2 publisher however has dependencies and requires OSGi infrastructure (configuration files/area, etc.) so the proposed patch downloads a binary drop with all the needed infrastructure and bundles. The drawback from this approach is that the download is around 25MB. In the future this will surely be minimized since there is a discussion in the P2 mailing list to reduce the size of the provisioning tools. There is also a prototype for updater/installer which is ~2MB, so the publishing download can probably be reduced to 3MB. Another problem I spotted while creating this P2 publishing task is that the shutdown bundle (org.eclipse.virgo.kernel.shutdown-2.1.0.M02-incubation.jar) is not published due to missing symbolic name in META-INF. Reproducible: Always Steps to Reproduce: 1. Apply the patch 2. Start build with p2.publish task (ant clean p2.publish) 3. Update/Install from the P2 repository in target/repository
Created attachment 176868 [details] GIT patch for build-kernel
Chris will look at this.
If the tool is to be reduced in size then it is possible that virgo-build could be updated to include this functionality. I don't think it's sensible to just have this going in the kernel repo, certainly the web-server repo should have it as well and eventually all the repos for the publishing of intermittent build artifacts. It would also be good to do this to a remote location. I'm quite concerned about the size of the download currently and I really don't want to see this be part of the normal build for kernel. The overhead issues were generally what stopped progress on DMS-2537. Could you provide links to any of the information about the cut down provisioning tools, I would be interested to see if they also no longer require an embedded OSGi instance to be launched. This is certainly something we want to get working but it should be for all the repos, so become part of virgo-build. Keeping it under a separate target for now is the right thing, the p2.publish name is good. What are you trying to achieve with this, by getting the kernel to publish to a local p2 repo? Thanks for spotting the missing entry in the kernel shutdown bundle, it will be a simple and quick fix for us to do. Thanks, Chris. (Passing back to Steve as I am away for a couple of weeks now).
The thread for the lean P2 client can be found here: http://dev.eclipse.org/mhonarc/lists/p2-dev/msg03271.html Unfortunately the lean P2 client will be running in an OSGi environment, which means that the embedded OSGi is still a must. The only way to avoid this I'm aware of is using maven/tycho with update-site project types. Creating a local P2 repository is the easiest and least intrusive way I can think of. Later this local repo can be copied to a HTTP server and can become the official Virgo P2 repository (nightly or milestone). This local repo can also be used to provide binary drops with P2 repository inside the same way as Equinox and Eclipse do in the moment. For more details on our use cases you can have a look at: http://dev.eclipse.org/mhonarc/lists/virgo-dev/msg00170.html
Another approach would be to publish artifacts to a P2 repository on build. This is of course possible but still the build-kernel project has to provide a special bundle that packs the scripts, configuration files, etc. so the Virgo install from P2 can be complete. Therefore having a publish after every sub-module build will not bring any real benefit and is most likely to even cause inconsistent repository. Such approach can only be useful if the intention is to use the P2 repository as a build artifact storage in the future so other projects can use the artifacts inside for their own build. Still a certain level of consistency has to be maintained - a bundle should be published if all its requirements are already in the repository. Currently we can achieve consistent Virgo repository with three products since the Virgo file structure is not following the default Equinox one. To enable different file structure a mapping that is made on product level has to be created. That's why we need a product for all bundles in lib, a product for the lib/kernel bundles and the last product will provide the Virgo repository.
Created attachment 178754 [details] P2 repository with all Virgo files Consistent Virgo repository with three products due to the different file structure in Virgo (compared to Equinox). Products included: * all bundles in lib * lib/kernel bundles * repository
Bug 324991 will block this request since it requests change the file structure. This however will mean that the p2 repository can be created with only one product instead of 3.
Created attachment 184505 [details] The patch for the kernel repo as a result of the F2F pair programming
I have added a patch that is up to date with the work done at the F2F on the kernel repo. Please can you confirm that it is entirly the work of yourself and me then I can commit it with you as the author. I just need this confirmation as a part of the legal process.
I confirm that 100% of the patch was created by me and Christopher Frost as a result of pair programming and I have the right to contribute it to Eclipse.
*** Bug 332420 has been marked as a duplicate of this bug. ***
Initial work committed to web-server and kernel, the p2.publish target is working. Probably some extra work required in the future to polish it though.
