In our experience, using automatic registration has not been very useful.
We also used generator and try to apply APT, but at some point we just
realised that it was a unjustified complication, because the advantages was
pretty questionable. This might not apply to your registry, but in our
case, we realised that with the automatic registration we end up loosing
various advantages like java refactoring and code usage inspections and
lose control on which resources should be added to the registry. This
disadvantages just to omit a line like registry.register(resource). So when
you give the user control of this line, which it's almost trivial and I
don't think it's logic duplication, it's also trivial to make modules
(something like '(Registry r) -> { r.register(resource1);
r.register(resource2); }' is enough), or do not register all the resources,
or has different modules for testing, etc. So we concluded that the
advantages of writing modules are much more than the auto-generating a bulk
registry.
On Saturday, October 8, 2016 at 9:40:04 PM UTC+2, Thomas Broyer wrote:
>
>
>
> On Saturday, October 8, 2016 at 12:14:29 AM UTC+2, Ahmad Bawaneh wrote:
>>
>> Dears,
>> We all know that GTW 3.0 will come with some major changes from the
>> current GWT, and so we find every were suggestions for how to be prepared
>> for these changes, and that is good, but here is my issue regarding the
>> removal of generators and the suggestion to replace them with Annotation
>> processors:
>>
>> I have been using generators to build some kind of registry, so a
>> developer can annotate a class with an annotation and using the generators
>> i generate the code that register that class in the registry to picked up
>> at run-time, which is the normal case here, but in my case developer write
>> there own modules in seperate projects and provides me with the final
>> artifact, and since in my generator i scan the class path i was able to
>> find the annotated classes within these third party jars and register them.
>>
>> that worked perfectly for me.
>>
>> now i have trying to replace my generators with annotation processors,
>> but annotation processors does not scan classes from third party jars as it
>> only works for source code, and now if i want things to work for me i have
>> to ask every one to write thier projects as part of my project - thier
>> projects source code should be part of my project -.
>>
>> and with this modularity is 100% been killed.
>>
>
> No.
> First, APT can work on already-compiled classes:
> http://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html
> The main issue here is that a) you have to know the class names you want
> to process (you can use a tool to scan a classpath, such as scannotation,
> to get that list) and b) most build tools don't have built-in support for
> passing class names to JavaC, rather than source files.
> But one would argue that classpath scanning is bad (at least if there's no
> alternative).
> A better approach is to use a service loader-like approach (not
> service-loader as you don't seem to be forcing a base class/interface):
> each JAR lists its classes in a specific file in META-INF, so you just have
> to read all such files from the classpath and you have the list of classes
> you need to process.
> But ideally, you'd rather have the "final user" explicitly list what it
> needs (a classpath scanner to create such a list would be one way to do it,
> but the developer could prefer tailoring the list by hand)
>
>
>> So is APT the right choice?
>>
>
> Probably not, or at least it would be only part of the solution. Some kind
> of "preprocessor" would be better suited (it could possibly generate a Java
> source file that'd later trigger an annotation processor).
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
