Community
Participate
Working Groups
The Equinox team consumes the aspectj bundles from your p2 repository. It seems that every time that you update your p2 repository with new bundles, you delete the metadata for the existing bundles. This breaks our builds. Please update your metadata with the new bundles instead completely replacing it. We need a stable aspectj p2 repository to allow our builds to proceed. This is the repo we consume bundles from http://download.eclipse.org/tools/ajdt/35/update
Would it be appropriate to create a stable p2 repository containing the AspectJ bundles only? This would be at a separate location and would be guaranteed not to change.
The implementation details don't matter to me, as long as it remains stable. The only two bundles we consume in our build are org.aspectj.weaver and org.aspectj.runtime.
OK. I have uploaded an aspectj-only update site to: http://download.eclipse.org/tools/ajdt/aspectj/update This update site contains the runtime, weaver, and ajde bundles, version 1.6.7.20091231194938. This update site will remain in place indefinitely. Please let me know if this is sufficient for the build.
Could you please make it an p2 repository instead of just an update site?
This is a p2 repository. Misused terminology. There is no site.xml and a content.jar and artifacts.jar are included.
Sorry, I was looking in the ajdt directory accidentally, not ajdt/aspectj. Could you please also put the older versions of these bundles in the repository and update the metadata. This is what we consume in our 3.6 map file today. plugin@org.aspectj.weaver,1.6.5=p2IU,id=org.aspectj.weaver,version=1.6.6.20090930185500,repository=http://download.eclipse.org/tools/ajdt/35/update plugin@org.aspectj.runtime,1.6.5=p2IU,id=org.aspectj.runtime,version=1.6.6.20090930185500,repository=http://download.eclipse.org/tools/ajdt/35/update
The update site has been updated to include both versions of the features.
I ran a test build and had a compile error. Tom looked at it and the org.aspectj.weaver bundle is specified as a jarred bundle in the repo when it fact it should be specified as directory in the metadata. Can you please fix your repository?
How do I specify that a bundle should be installed unpacked when it is not associated with a feature? When it is associated with a feature, then I know to add the unpacked="true" line to the feature.xml, but how can this be done otherwise? Alternatively, is there any chance you can update the map files to use the more recent version of AspectJ? The more recent version is associated with a feature and they are specified as unpacked. Also, the newer version has a few extra bug fixes in it (although I do not believe that they affect the building of Equinox Aspects).
You can specify that the bundle should be in zipped form in the manifest. Eclipse-BundleShape : dir The resulting content.xml that is generated from your build should specify the following for your bundle. <instruction key='zipped'> true </instruction> As for moving up to a newer version of the aspectj bundles, that decision is up to Tom. I thought the purpose of this new repository was to have older and stable versions of your bundles for us to consume :-)
(In reply to comment #10) > You can specify that the bundle should be in zipped form in the manifest. > > Eclipse-BundleShape : dir > > The resulting content.xml that is generated from your build should specify the > following for your bundle. > > <instruction key='zipped'> > true > </instruction> > > As for moving up to a newer version of the aspectj bundles, that decision is up > to Tom. I thought the purpose of this new repository was to have older and > stable versions of your bundles for us to consume :-) Ultimately I will leave this up to Martin. This is the first release which we will have graduated aspect weaving stuff. In my opinion we MUST have a repeatable build for this release very soon though. Part of having a repeatable build is that we can ensure that we compile against the same set of dependencies indefinitely for the code which we contribute to each integration builds. If Martin is confident that compiling against the latest versions of aspects does not prevent the weaving stuff from running on the older versions (which we express are supported in our constraint version ranges) then I do not have an issue moving up in versions. But our goal should be that this is the last time we need to do this. Only if our weaving stuff actually depends on a newer version of aspectj for functional reason should we be forced to move up versions to compile against in my opinion.
I am happy with changing the map to build the weaving feature against the more recent version of AspectJ now. Once this change happened and the build succeeded, we should stay with that version for the build until there is a real reason to change this (new version of equinox weaving requiring newer version of AspectJ, for example). From my point of view those changes will not happen for the Helios release. Since I am not sure about the process of changing the map files, who is in charge of that? Should I do the change or would you do that, Kim? Thank you all for helping with this equinox weaving build!!!
Yes, we would be in charge of updating our map files. I would echo Tom's comments regarding a repeatable build. It is essential for this to be in place for the Helios release.
Great. As I said before, this repository will remain available for as long as required by Equinox Aspects (ie- forever). Please let me know when the map files have been updated and I will close the bug.
Thanks, I was able to build with the 1.6.7 versions of the bundles. Closing.
