Problem using accessor properties in Bnd macro expansion

GENERAL
1

Hi,

I am using Bnd 6.4.0 and have written a custom annotation like this:

@Header(name = "My-Foo", value = "${#value}")
@Target(PACKAGE)
@Retention(CLASS)
public @interface MyFoo {
    String value();
}

However, when I apply this annotation to one of my package-info.java files, Bnd does not process its macro as I expect, and I always end up with:

My-Foo: ${#value}

in my bundle’s manifest. I have no such difficulty using macros like ${@package}. Can anyone suggest what might be going wrong please?

Thanks,
Chris

2

Nothing but tumbleweed? :hushed:

I thought either I’d done something obviously wrong (although AFAICT it matches the documentation), or Bnd is forgetting to expand the #value macro for some reason.

Cheers,
Chris

Edit: In fact, I am starting to think that ${#value} just isn’t processed for @Header annotations, despite @Header also being a “bundle annotation”.

3

OK, I’ve run out of time to pursue this issue further. But from what I can tell, Bnd creates an aQute.bnd.osgi.Annotation instance for the Header annotation, but does not populate its elements field with a #value key. And hence the ${#value} macro cannot be expanded.

But “accessor properties” seem to work fine for the @Requirement annotation, so I must assume this is a bug in Bnd.

Cheers,
Chris

4

Sorry to leave you dangling. The answer is a bit disappointing, the Header meta annotation does not support access to the attributes of the annotated annotation (MyFoo in your example.)

See the line that processes this. For Header we do not merge the attributes like we do for the others.

Not sure why this exception was made. When I merge the attributes in the same way, it works like a charm.

If you think this is important, you should file an issue then we can find out who made this choice.

5

OK, thanks, I’ve raised #5530 for this.

From my perspective, the documentation clearly states that this works for bundle annotations, of which @Header is one. There is no mention of @Header being an exception to this.

Cheers,
Chris