[
https://issues.apache.org/jira/browse/IGNITE-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14496:
-----------------------------------
Fix Version/s: 3.0.0-alpha3
> Move configuration annotations to configuration-api
> ---------------------------------------------------
>
> Key: IGNITE-14496
> URL: https://issues.apache.org/jira/browse/IGNITE-14496
> Project: Ignite
> Issue Type: Sub-task
> Affects Versions: 3.0.0-alpha2
> Reporter: Semyon Danilov
> Assignee: Ivan Bessonov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Problem
> In this issue we need to move all API from *ignite-configuration* module into
> *ignite-api*. This comes with a price, we can't just move our classes. The
> problem is that code generator generates (in principal) two thing:
> * schema-based general interfaces:
> ** {{*View}}
> ** {{*Change}}
> ** {{*Configuration}}
> * schema-based implementations:
> ** {{*Node}}
> ** {{*ConfigurationImpl}}
> First set of interfaces depends on +other interfaces only+. This is good and
> pretty much all we need in resulting *ignite-api* sources.
> Second set of classes requires us to have classes like {{InnerNode}} or
> {{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
> for API. These 2 classes must be in another Java module and that's a problem.
> There are two approaches to solve the problem, I'll try my best to describe
> both.
> h3. Common problem for both solutions
> *ignite-configuration-annotation-processor* clearly depends on *ignite-api*
> in our case AND at the same time *ignite-api* should use annotation
> processing. We have cycling dependency. Right way of resolving it is to
> create module *ignite-configuration-api*. This shows us that having +all+ API
> in one module is probably not the best idea.
> h3. Solution 1 - split annotation processor into 2
> There's no doubt that we need processor that will generate first set of
> interfaces. We already have it. We could create a second annotation processor
> that will generate implementations into other modules, let's call it
> *impl-processor*. But Java annotation processing API can't do that directly.
> If we compile module *B* that depends on module *A*, only classes from *B*
> will be passed into environment of *impl-processor*. We have to options of
> how to resolve it:
> * use libraries like [classgraph|https://github.com/classgraph/classgraph],
> having *ignite-api* as hardcoded compiler dependency in annotation processor.
> Works in theory BUT there are issues:
> ** there's no clear way of distinguishing schemas that you should process in
> current module from those that you shouldn't;
> ** *ignite-api* dependency is hardcoded as an optional source of schemas,
> which is a questionable thing.
> * include package with desired schemas using maven helper plugin. This
> approach also has issues:
> ** now we understand how to configure it, but such configuration will
> require more manual steps and either separate package for modules schemas or
> include/exclude list in helper plugin configuration;
> ** we will have several identical **.class* files in target directories of
> different modules.
> h3. Solution 2 - leave only one annotation processor and generate everything
> else at runtime
> This approach requires 0 additional configuration. {{Node}} and
> {{ConfigurationImpl}} can be generated from schemas when you register new
> root key. We already have *ignite-bytecode* module so there's no need for
> additional libraries in dependencies. Usages of the module can be seen in
> module *ignite-schema*. I assume that writing tests will be much easier with
> runtime code generation. Also classes like {{InnerNode}} will probably become
> package-private. The problems are:
> * potential problems during debugging. I don't see it as a problem. Given
> that we'll cover everything with tests, generator code will be pretty stable;
> * generating code requires time. Doesn't look like it really needs a
> significant amount of time though;
> * we can start several nodes in a single JVM so there might be collisions of
> other issues. The problem is purely technical;
> * choice of {{ClassLoader}} for generated classes has to be very careful.
> Situation when generated configuration class cannot be loaded for some reason
> is unacceptable.
> h3. Solution 3 - just generate implementation classes into api module
>
> IMHO, second solution is better. The fact that API usage becomes better
> overweights the fact that we would need to generate different parts of
> configuration code using different tools.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
