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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment