Looks like this is a slight misunderstanding. I meant to use BND or Bundlor in the build script to generate the manifest every time. And test the resulting OSGi bundle in a real OSGi runtime just once (manually, before this is committed). Is that OK with you?
Thank you. > Hi, > > > > > I'd be ok with a one time manual test to verify it is basically correct. > I previously used bundlor but was not in a position to verify the output so I > never committed it. Ideally I wanted to integrate bundlor invocation into the > build process so that when occasionally a new package is added or one > deleted, the manifest stays in step. Rather than just run bundlor once and > commit those fixed manifests. However, if a 'one off run' is simplest then > I'd be ok to use it for aspectjrt.jar as the package set for that hardly ever > changes. > > > > > > cheers, > > > Andy > > > > > > On 11 January 2013 11:11, M. P. > wrote: > > > > > I'd assume they have an environment in which to verify the > correctness of what is being created. > > > Do mean an automatic test suite or one-time manual testing? > > Automatic tests would be very nice but they would require serious > machinery such as the OSGi runtime. > And maybe these bundles (aspectrt, weaver, etc) are simple enough so > that it is safe to assume that tools such as BND and Bundlor generate valid > manifests? > > What do you think? > > Thanks. > > > > > > The weaver also needs one (and I suppose it does no harm to get > it right for tools and matcher too). > > > > > > > > > This has long been on the list of TODOs (see bugs like > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=338034) - I even > prototyped the implementation with bundlor ( > > > > http://www.springsource.org/bundlor). I created some basic versions > for testing but I don't believe the users got back to me about whether what > was being generated was correct. Traditionally users just seemed to go the > EBR and collect the versions from there which had had their manifests > regenerated. I'd be happy for someone to take this on and sort it out > properly for AspectJ, I'm more than happy to help them progress it - I'd > assume they have an environment in which to verify the correctness of what is > being created. > > > > > > > > > The AspectJ build process is a bit arcane, which can make > something you'd think would be easy, rather tricky, but I'll help a brave > soul battle through that. > > > > > > > > > cheers, > > > > > > Andy > > > > On 10 January 2013 06:51, M. P. > > > > > > > wrote: > > > > > >> The aspectjrt.jar does not have a valid OSGi manifest at the > moemnt. It would be nice if it did. > > >> In order to make it OSGi compliant the manifest should get > a few more headers such as Export-Package. > > >> I saw that the aspectjrt.jar manifest is generated from > this file > > >> > > http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/aspectj5rt/aspectj5rt.mf.txt > > >> Since the packages listed in Export-Package should have > versions adding this header to the manifest template is problemat because > when the version placeholders are replaced with the real values the format of > the manifest may become invalid. > > >> So how do you feel about generating the manifest in the > build script via > > >> > http://ant.apache.org/manual/Tasks/manifest.html? > > >> > > >> Thanks. > > >> _______________________________________________ > > >> aspectj-users mailing list > > >> > [email protected] > > >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
