Hi, Jandex 2.4.0.Final was released on Wed (with a couple of bigger changes that are technically breaking, but not for ordinary Jandex API callers: 3 new methods on `IndexView`, new storage format version) and now it’s time to talk about $SUBJ. As you might have noticed, I’m slowly taking over Jandex maintenance from Jason. We have agreed that it’s time to do a 3.0 release with some changes that are visibly breaking for everyone. Hence this wide distribution. You can find the current plan for 3.0 here: https://github.com/wildfly/jandex/milestone/3 <https://github.com/wildfly/jandex/milestone/3>;, but I’ll repeat the important points here: - Move to SmallRye, both on GitHub and in the Maven coordinates space. The `groupId` will change, but the package name will not. This has the potential to cause nondeterministic classpath, so configuring Enforcer to ban `org.jboss:jandex` will be a good idea.

- Move to Java 8 as the base.

- Uniform API to access annotations. Currently, each `AnnotationTarget` has a slightly different set of methods to access annotations, and I’d really like to unify that.

- `Indexer.index()` will no longer return `ClassInfo`. The very existence of this return type prevents doing post-processing in `Indexer.complete()`, which we’d need to do to properly resolve some recursive generic declarations. The recently introduced `Index.of()` methods are a nicer way to quickly construct an index for test purposes.

- Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be visible in the index. Hopefully this is just an FYI.

- I’d like to merge the Maven plugin into the main codebase, and hopefully also the `typeannotation-test` artifact. Also, Jandex will use (at this point, more like continue using) GitHub Issues for issue tracking. The JANDEX project in Red Hat JIRA will be decommissioned. Of course, the purpose of this email is to let you voice any concerns you may have. Feel free to either reply to this email, or file an issue in the existing Jandex repo on GitHub (it will be transferred to SmallRye, so nothing will get lost), or add a comment to one of the existing issues. Thanks, LT _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

pá 27. 8. 2021 v 12:47 odesílatel Martin Kouba <mkouba(a)redhat.com <mailto:mkouba@redhat.com>> napsal: On 27. 08. 21 10:21, Ladislav Thon wrote: > - Move to SmallRye, both on GitHub and in the Maven coordinates space. > The `groupId` will change, but the package name will not. This has the > potential to cause nondeterministic classpath, so configuring Enforcer > to ban `org.jboss:jandex` will be a good idea. Hm, so `io.smallrye:jandex` is the new GA? I'm asking because some smallrye projects use the `smallrye-` prefix in the artifactId and some use a more specific groupId, e.g `io.smallrye.config`. Using `io.smallrye:jandex` would be my preference, but I can be convinced otherwise :-) Feel free to add a suggestion to https://github.com/wildfly/jandex/issues/124 <https://github.com/wildfly/jandex/issues/124>;. > - `Indexer.index()` will no longer return `ClassInfo`. The very > existence of this return type prevents doing post-processing in > `Indexer.complete()`, which we’d need to do to properly resolve some > recursive generic declarations. The recently introduced `Index.of()` > methods are a nicer way to quickly construct an index for test purposes. Note that in Quarkus we don't use the Indexer.index() for test purposes but to lazily index classes on the class path that are missing in the index built from the app. I'm not totally sure what you mean here, but would `Indexer.index()` returning `void` prevent you from doing that?

You can still construct a full index and then lookup the class form it, no? (From Jandex perspective, indeed we can't assume we'll be given a complete classpath. So `Indexer.complete()` doing post-processing may still be unable to fully resolve everything. Such is the fact of life.) > - Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be > visible in the index. Hopefully this is just an FYI. Hm, I'm +1 on this but wouldn't this result in much bigger indexes? I don't think it would be _much_ bigger, mostly because there isn't much runtime-invisible annotations out there. Mike Edgar, who is contributing the feature, says the memory impact is minimal. I haven't personally done any measurement. Feel free to look at and/or comment in https://github.com/wildfly/jandex/pull/129 <https://github.com/wildfly/jandex/pull/129>;. Thanks for your comments! LT

Does moving it to SmallRye mean it's going to end up with SmallRye dependencies? Currently it doesn't really have any dependencies so I don't expect it will, but I'm curious as SmallRye leaks in Jakarta dependencies which could be problematic for namespace changes. On Fri, Aug 27, 2021 at 1:22 AM Ladislav Thon <lthon(a)redhat.com&gt; wrote: > Hi, > > Jandex 2.4.0.Final was released on Wed (with a couple of bigger changes > that are technically breaking, but not for ordinary Jandex API callers: 3 > new methods on `IndexView`, new storage format version) and now it’s time > to talk about $SUBJ. > > As you might have noticed, I’m slowly taking over Jandex maintenance from > Jason. We have agreed that it’s time to do a 3.0 release with some changes > that are visibly breaking for everyone. Hence this wide distribution. > > You can find the current plan for 3.0 here: > https://github.com/wildfly/jandex/milestone/3, but I’ll repeat the > important points here: > > - Move to SmallRye, both on GitHub and in the Maven coordinates space. > The `groupId` will change, but the package name will not. This has the > potential to cause nondeterministic classpath, so configuring Enforcer to > ban `org.jboss:jandex` will be a good idea. > - Move to Java 8 as the base. > - Uniform API to access annotations. Currently, each `AnnotationTarget` > has a slightly different set of methods to access annotations, and I’d > really like to unify that. > - `Indexer.index()` will no longer return `ClassInfo`. The very existence > of this return type prevents doing post-processing in `Indexer.complete()`, > which we’d need to do to properly resolve some recursive generic > declarations. The recently introduced `Index.of()` methods are a nicer way > to quickly construct an index for test purposes. > - Runtime-invisible annotations (i.e., `RetentionPolicy.CLASS`) will be > visible in the index. Hopefully this is just an FYI. > - I’d like to merge the Maven plugin into the main codebase, and > hopefully also the `typeannotation-test` artifact. > > Also, Jandex will use (at this point, more like continue using) GitHub > Issues for issue tracking. The JANDEX project in Red Hat JIRA will be > decommissioned. > > Of course, the purpose of this email is to let you voice any concerns you > may have. Feel free to either reply to this email, or file an issue in the > existing Jandex repo on GitHub (it will be transferred to SmallRye, so > nothing will get lost), or add a comment to one of the existing issues. > > Thanks, > > LT > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- James R. Perkins JBoss by Red Hat _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s