Code generation not possible when underscore '_' in package name

[lukasjelonek]

Version

4.1.0

Context

I wanted to generate service proxies and got an exception when I have a underscore in my package name, e.g. com.example.my_app.services.

@ModuleGen(groupPackage = "com.example.my_app", name = "services")
package com.example.my_app.services;

import io.vertx.codegen.annotations.ModuleGen;

It causes the following exception:

io.vertx.codegen.CodeGenProcessor reportGenException
SCHWERWIEGEND: Could not generate model for com.example.my_app.services: Invalid group package name com.example.my_app
io.vertx.codegen.GenException: Invalid group package name com.example.my_app
        at io.vertx.codegen.ModuleModel.<init>(ModuleModel.java:58)
        at io.vertx.codegen.CodeGen.getModuleModel(CodeGen.java:261)
        at io.vertx.codegen.CodeGen.lambda$null$16(CodeGen.java:256)
        at io.vertx.codegen.CodeGen$$Lambda$343/0x00000000ae9a24b8.get(Unknown Source)       
        at io.vertx.codegen.CodeGen$ModelEntry.getValue(CodeGen.java:311)
        at io.vertx.codegen.CodeGen$ModelEntry.getValue(CodeGen.java:292)
        at io.vertx.codegen.CodeGenProcessor.lambda$process$8(CodeGenProcessor.java:233)     
        at io.vertx.codegen.CodeGenProcessor$$Lambda$267/0x00000000ae98a8f8.accept(Unknown Source)
        at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator$$Lambda$154/0x0000000000000000.accept(Unknown Source)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
        at java.base/java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1837)  
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:497)   
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:487)
        at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
        at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:739)
        at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:740)
        at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
        at io.vertx.codegen.CodeGenProcessor.process(CodeGenProcessor.java:231)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1025)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:940)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1269)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1384)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1261)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:935)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl$$Lambda$86/0x00000000ae3a9388.call(Unknown Source)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) 
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)    
        at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
        at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
        at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134)
        at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:187)      
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)   
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)   
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)   
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)       
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39) 
        at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)        
        at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)

Do you have a reproducer?

Steps to reproduce

1. Change package name in beer example to something with underscore https://github.com/vertx-howtos/service-proxy-howto
2. mvn clean compile

Extra

I checked the code and implemented a patch for the QualifiedCase-class to handle underscores. As I don't know where this might have side effects, I can't tell if it will solve the problem.

See: lukasjelonek@4fd4219

[vietj]

can you provide a PR and test other cases as well ?

[lukasjelonek]

Sure. What do you mean with other cases? The other case classes? I can implement it, if you can give me some hints what to check, as I am not familiar with all details in the project.

[vietj]

I think the main issue would be the Snake CASE because it relies on "_"

…

On Thu, Jun 17, 2021 at 9:58 AM Lukas Jelonek ***@***.***> wrote: Sure. What do you mean with other cases? The other case classes? I can implement it, if you can give me some hints what to check, as I am not familiar with all details in the project. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#338 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXDCTSUXYNBA6EWHWNUGLTTGTJHANCNFSM46V74VCQ> .

[lukasjelonek]

I have some questions on the details:

What is the used conversion flow?

• Unidirectional: Java model (qualified case, camel case) -> to other cases?
• Multidirectional: Any case -> any other case?

Depending on the flow it will be harder or easier to implement a solution.

Is it required that a conversion into another case and conversion back to the original case results in the identity?
e.g. toQualifiedCase(toSnakecase('foo.bar_baz')) == 'foo.bar_baz'? This will require an unambiguous represenstation of _ in snake-case and kebab-case

What about double underscores in snakecase output? Is that allowed or should it be reduced to a single underscore?
foo._bar => foo_bar or foo__bar?

What about underscores in KebabCase output? Are they allowed or should they be replaced with -?
foo.bar_juu => foo-bar_juu or foo-bar-juu?

foo__bar and foo-bar_juu require no additional code changes. The others require some additional processing of the atoms before formatting.

[vietj]

I think it can be used in both mode, e.g we have a new SQL template feature that allows the user to customize the case, so he can provide a custom case for mapping to data object

[mohamnag]

somehow I can remember this was already discussed a long time ago and somehow it ended up in "will not be implemented" result. However I just wanted to remind that this also is the case with field names. Field names starting with "_" will be just ignored by vertx codegen. which for example in my case means all mongo DB documents need a manual mapping from/to "_id". This kind of defeats the goal of codegen!

[vietj]

I will update the module package name generation because there is no reason that _ cannot be used for module name

[lukasjelonek]

I already started to implement it, but unfortunately I don't have the time at the moment to finish it (and it's not super important at the moment): lukasjelonek@4fd4219