Note sure if this will gelp you much - we're a Gradle user, and don't use 
intellij. But the basic principles are the same.

When we migrated to the latest GWT we also updated our top level gradle 
build file to have a gwtSuperDev task which does all the heavy lifting for 
us:

    task gwtSuperDev(dependsOn: 'build') {
        // probably a nicer way of getting these (e.g through project 
sourcepaths)
        def gwtapi_src = file('tas/gwtapi/src')
        def webui_src = file('webui/src')

        doLast {
            def compilerArgs = [
                        "-strict", "-noincremental", "-noprecompile", 
                        "-src", "${gwtapi_src}/", 
                        "-src", "${webui_src}/", 
                        "com.ascert.webui.vt.VtWebUi-dev" 
                        ]

            javaexec {
                main = 'com.google.gwt.dev.codeserver.CodeServer'
                // Leverage the Gradle create classpaths for gwtapi and 
webui subprojects
                // Make sure GWT build libs are at the front to ensure the 
vanilla GWT jetty classes are used by codeserver
                classpath += configurations.gwtBuild
                // These classpaths will duplicate some of the above, but 
doing this way ensures our custom jetty does not get 
                // picked up by GWT codeserver, which causes class 
inconsistencies.
                classpath += 
project(':proj:webui').configurations.compileClasspath
                classpath += 
project(':proj:tas:gwtapi').configurations.compileClasspath

                maxHeapSize = "1000m"

                args = compilerArgs.flatten()
            }
        }
    }

Our 2 main source trees are defined by gwtapi_src and webui_src. The 
com.ascert.webui.vt.VtWebUi-dev 
is our dev GWT XML file name. It's slightly different to our prod one as it 
has debug flags on and only creates a single large permutation.

That's really the main part. We also have the source modules on the 
classpath as :proj:webui and :proj:gwtapi - for reasons as per the comments.

The only other crucial part is the configurations.gwtBuild. This is a 
gradle configuration with all the JARs needed for codeserver (gwt_dev, 
gwt_user, various js lib jars such as GXT etc.). It's really just a 
convenient way of handling classpath JARs and nothing more. If/when we 
update the versions of any of those, the above automatically pulls in the 
updated dependency versions.

There's really nothing that special about CodeServer apart from making sure 
all your own sources and JARs are on the classpath, plus the standard GWT 
ones and any 3rd party libs you use. Although the above is for Gradle, the 
same principles and approach ought to apply for MVN or any other build tool.

Good luck!

-Rob


On Monday 15 April 2024 at 10:13:19 UTC+1 Mathias wrote:

> Hi Thomas
>
> unfortunately, I'm still stuck. I thought I'd attack the Lombok dependency 
> first, since that's a third-party it depends on. I don't suppose you've 
> ever been exposed to that? 
> I tried setting the 
> *<classpathScope>compile</classpathScope> *to the "configuration" setting 
> of the plugin def in pluginmanagement of the root pom. That didn't help. 
> (neither compile+runtime)
>
> In the intellij GWT-plugin I got it working while running by setting the 
> argument "-javaagent:/...path..../lombok-1.16.14.jar=ECJ , not sure if that 
> could change anything. I mean this breaks at compile so I don't know.
>
> I have gone through the configuration line-by line with both your 
> archetype project and the NaluKit Marco tipped me about. I can't see any 
> relevant difference. I don't have *<type>gwt-lib</type> *on any 
> dependency, but neither does any of the other projects I look at.
>
> I also tried adding lombok dependency to the plugin, it didn't help either.
>
> I am basically stuck, this is not great. Would you have time to look at 
> the plugin config if I pasted it?
>
> On Friday 12 April 2024 at 11:20:01 UTC+2 Thomas Broyer wrote:
>
>> On Friday, April 12, 2024 at 7:50:42 AM UTC+2 Mathias wrote:
>>
>> -My dependencies should be ok since i can build it with the plugin, so 
>> i'm a bit at a loss as to how make this work.
>>
>>
>> Dependencies for gwt:compile and gwt:codeserver aren't the same: 
>> https://tbroyer.github.io/gwt-maven-plugin/codeserver.html
>> You might have to either adjust the <scope> of dependencies (e.g. from 
>> provided to compile) or adjust the gwt:codeserver's classpathScope (e.g. 
>> from runtime to compile+runtime or compile)
>>  
>>
>> as a final aside:
>> The "neither a gwt-lib or jar" warning messages in the error log below - 
>> i still get it if i add the gwt-lib type to the dependency, and the 
>> archetype project prints the same error when created.
>>
>>
>> Note that it's an info, not a warning 😉
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/ec616909-c88d-4c00-b164-3f1b7795bd86n%40googlegroups.com.

Reply via email to