Re: [gwt-contrib] Required JDK version to build GWT?

['Goktug Gokdogan' via GWT Contributors]

I was clarifying what I was expecting the setup to look like wrt different
versions supported.
I agree that the granularity of the supported version doesn't need to be
lower than what is useful to us (which I think is driven by both LTS and
also by GWT releases).

On Mon, Jun 29, 2020 at 7:47 PM Colin Alworth 
wrote:

> Right - the excludes via ant are certainly an option ("use ant filters"),
> my main hope is to avoid adding another stanza of xml for the emulation for
> each release. Cutting out Java7 and adding a "java 11 or higher" to lump
> all the java 9, 10, 11 tests in would at least be a net equal in XML from
> what we have today (since compiling under Java 7 isn't an option), but
> still a bit messier than I'd like - especially if we agree that "run all
> internal tests in Java11" is reasonable (plus another few build steps to
> validate the build under other versions of Java).
>
> If that isn't deemed reasonably, we'll need a Java9 check (for the new
> of() methods), Java 10 check (new optional methods, collections copyOf),
> Java 11 check (string methods) to get caught up with the JDT we're using
> today, and 12, 13, 14 are out now, with 15 soon. Again, not impossible,
> just perhaps messy - and unwinding the "java8" flag (which really seems to
> mean "newer than java7") is less fun than I'd like.
>
> --
>   Colin Alworth
>   co...@colinalworth.com
>
>
>
> On Mon, Jun 29, 2020, at 9:21 PM, 'Goktug Gokdogan' via GWT Contributors
> wrote:
>
> wrt running tests:
> See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern
> used in JRE earlier; and the CI was updated to run in both 7 and 8 at the
> same time.
>
> PS: Compiler tests ("jjs.test.Java8Test") was different because we really
> needed to run the compiler tests with new syntax inside Google which didn't
> have the Java8 VM at the time. It wasn't a deal breaker to be not able run
> Java8 JRE tests at the time so they are not super sourced.
>
> I recommend the same approach.
>
>
> On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:
>
> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
> longer possible to build GWT with Java7, and similarly the decision was
> made to no longer officially support running on Java7
> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
> believe).
>
> There is still some defunct wiring in the build to handle Java 7 vs Java 8
> though, mostly with regards to running tests - since we first javac our
> java classes, and then run gwtc on them, we need to make sure that the java
> version being use can correctly compile those tests.
>
> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
> of the existing work on this: the main remaining piece is to decide how to
> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
> "example", "gwt.include", and "tip". None of this compiles after Java 8,
> since Java 9 came with a new, incompatible API to build custom tags, so
> either we drop Java 8 support for building the toolkit, require _only_ Java
> 8 to build, support two parallel copies of the custom doc wiring, or drop
> the doc wiring entirely and remove these custom tags throughout the
> codebase.
>
> Since the release of GWT 2.9 and my own work on the above ticket, I've
> been picking back up some Java 9/10/11 JRE emulation work that I had
> previously paused, and I'm running into the issue described at the top - if
> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase,
> you'll get a compile error.
>
> Two basic ways I can easily see to fix this: we can make two copies of
> each test, one as an empty "real" java type and one as supersource, or we
> can guard those tests behind java version args in the build glue like we
> did for Java7 vs Java8. The first option is clunky, and while I see this
> was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't
> done for JRE emulation tests, and I assume there was a reason for that. The
> second option requires changing our CI to build+test on some new JRE...
>
> ...and given the constraints of the Java LTS system, and the java 8/9
> divide for custom doclet stuff, it seems like the clearest win is to move
> all the way to Java11, though continue to target java 8 releases, and test
> on all JREs up until current.
>
> So that's my pitch. For completeness, some other options that seem
> workable, keeping in mind that at present there are about 3 important JRE
> versions to support well: Java 8, Java 11, and the current stable release.
>  * Require Java8 for javadoc, supersource tests
>  * Allow any JRE 8+, use ant filters for tests for each version, maintain
> two javadoc builds
>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on
> java9+ builds
>
> Other technical ways to deal with this, or have a missed an easier
> solution to one of these problems?
>
>
> --
> You received this message because you are subscribed to the Google

Re: [gwt-contrib] Required JDK version to build GWT?

[Colin Alworth]

Right - the excludes via ant are certainly an option ("use ant filters"), my 
main hope is to avoid adding another stanza of xml for the emulation for each 
release. Cutting out Java7 and adding a "java 11 or higher" to lump all the 
java 9, 10, 11 tests in would at least be a net equal in XML from what we have 
today (since compiling under Java 7 isn't an option), but still a bit messier 
than I'd like - especially if we agree that "run all internal tests in Java11" 
is reasonable (plus another few build steps to validate the build under other 
versions of Java). 

If that isn't deemed reasonably, we'll need a Java9 check (for the new of() 
methods), Java 10 check (new optional methods, collections copyOf), Java 11 
check (string methods) to get caught up with the JDT we're using today, and 12, 
13, 14 are out now, with 15 soon. Again, not impossible, just perhaps messy - 
and unwinding the "java8" flag (which really seems to mean "newer than java7") 
is less fun than I'd like.

-- 
 Colin Alworth
co...@colinalworth.com



On Mon, Jun 29, 2020, at 9:21 PM, 'Goktug Gokdogan' via GWT Contributors wrote:
> wrt running tests:
> See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern used in 
> JRE earlier; and the CI was updated to run in both 7 and 8 at the same time.
> 
> PS: Compiler tests ("jjs.test.Java8Test") was different because we really 
> needed to run the compiler tests with new syntax inside Google which didn't 
> have the Java8 VM at the time. It wasn't a deal breaker to be not able run 
> Java8 JRE tests at the time so they are not super sourced.
> 
> I recommend the same approach.
> 
> 
> On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:
>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no 
>> longer possible to build GWT with Java7, and similarly the decision was made 
>> to no longer officially support running on Java7 (jsinterop-annotations use 
>> of "TYPE_USE", newer jetty version too I believe). 
>> 
>> There is still some defunct wiring in the build to handle Java 7 vs Java 8 
>> though, mostly with regards to running tests - since we first javac our java 
>> classes, and then run gwtc on them, we need to make sure that the java 
>> version being use can correctly compile those tests.
>> 
>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some of 
>> the existing work on this: the main remaining piece is to decide how to 
>> handle javadoc. GWT has its own custom doclet to handle a few custom tags, 
>> "example", "gwt.include", and "tip". None of this compiles after Java 8, 
>> since Java 9 came with a new, incompatible API to build custom tags, so 
>> either we drop Java 8 support for building the toolkit, require _only_ Java 
>> 8 to build, support two parallel copies of the custom doc wiring, or drop 
>> the doc wiring entirely and remove these custom tags throughout the codebase.
>> 
>> Since the release of GWT 2.9 and my own work on the above ticket, I've been 
>> picking back up some Java 9/10/11 JRE emulation work that I had previously 
>> paused, and I'm running into the issue described at the top - if you write a 
>> test that calls Map.of() and run it on Java8 as a GWTTestCase, you'll get a 
>> compile error.
>> 
>> Two basic ways I can easily see to fix this: we can make two copies of each 
>> test, one as an empty "real" java type and one as supersource, or we can 
>> guard those tests behind java version args in the build glue like we did for 
>> Java7 vs Java8. The first option is clunky, and while I see this was done 
>> for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't done for JRE 
>> emulation tests, and I assume there was a reason for that. The second option 
>> requires changing our CI to build+test on some new JRE...
>> 
>> ...and given the constraints of the Java LTS system, and the java 8/9 divide 
>> for custom doclet stuff, it seems like the clearest win is to move all the 
>> way to Java11, though continue to target java 8 releases, and test on all 
>> JREs up until current.
>> 
>> So that's my pitch. For completeness, some other options that seem workable, 
>> keeping in mind that at present there are about 3 important JRE versions to 
>> support well: Java 8, Java 11, and the current stable release.
>>  * Require Java8 for javadoc, supersource tests
>>  * Allow any JRE 8+, use ant filters for tests for each version, maintain 
>> two javadoc builds
>>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on 
>> java9+ builds
>> 
>> Other technical ways to deal with this, or have a missed an easier solution 
>> to one of these problems?
>> 

>> --
>>  You received this message because you are subscribed to the Google Groups 
>> "GWT Contributors" group.
>>  To unsubscribe from this group and stop receiving emails from it, send an 
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>  To view this discussion on the web visit 
>> https://groups.google.

Re: [gwt-contrib] Required JDK version to build GWT?

[Matt Davis]

I agree with this statement: "it seems like the clearest win is to move all
the way to Java11, though continue to target java 8 releases, and test on
all JREs up until current."

On Mon, Jun 29, 2020 at 10:21 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> wrt running tests:
> See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern
> used in JRE earlier; and the CI was updated to run in both 7 and 8 at the
> same time.
>
> PS: Compiler tests ("jjs.test.Java8Test") was different because we really
> needed to run the compiler tests with new syntax inside Google which didn't
> have the Java8 VM at the time. It wasn't a deal breaker to be not able run
> Java8 JRE tests at the time so they are not super sourced.
>
> I recommend the same approach.
>
>
> On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:
>
>> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
>> longer possible to build GWT with Java7, and similarly the decision was
>> made to no longer officially support running on Java7
>> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
>> believe).
>>
>> There is still some defunct wiring in the build to handle Java 7 vs Java
>> 8 though, mostly with regards to running tests - since we first javac our
>> java classes, and then run gwtc on them, we need to make sure that the java
>> version being use can correctly compile those tests.
>>
>> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
>> of the existing work on this: the main remaining piece is to decide how to
>> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
>> "example", "gwt.include", and "tip". None of this compiles after Java 8,
>> since Java 9 came with a new, incompatible API to build custom tags, so
>> either we drop Java 8 support for building the toolkit, require _only_ Java
>> 8 to build, support two parallel copies of the custom doc wiring, or drop
>> the doc wiring entirely and remove these custom tags throughout the
>> codebase.
>>
>> Since the release of GWT 2.9 and my own work on the above ticket, I've
>> been picking back up some Java 9/10/11 JRE emulation work that I had
>> previously paused, and I'm running into the issue described at the top - if
>> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase,
>> you'll get a compile error.
>>
>> Two basic ways I can easily see to fix this: we can make two copies of
>> each test, one as an empty "real" java type and one as supersource, or we
>> can guard those tests behind java version args in the build glue like we
>> did for Java7 vs Java8. The first option is clunky, and while I see this
>> was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't
>> done for JRE emulation tests, and I assume there was a reason for that. The
>> second option requires changing our CI to build+test on some new JRE...
>>
>> ...and given the constraints of the Java LTS system, and the java 8/9
>> divide for custom doclet stuff, it seems like the clearest win is to move
>> all the way to Java11, though continue to target java 8 releases, and test
>> on all JREs up until current.
>>
>> So that's my pitch. For completeness, some other options that seem
>> workable, keeping in mind that at present there are about 3 important JRE
>> versions to support well: Java 8, Java 11, and the current stable release.
>>  * Require Java8 for javadoc, supersource tests
>>  * Allow any JRE 8+, use ant filters for tests for each version, maintain
>> two javadoc builds
>>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on
>> java9+ builds
>>
>> Other technical ways to deal with this, or have a missed an easier
>> solution to one of these problems?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1L4gAaaEkqgWnqL%3DiKDX_aUjX1L0WThdG4yuxUyHdQMQ%40mail.gmail.com
> 

Re: [gwt-contrib] Required JDK version to build GWT?

['Goktug Gokdogan' via GWT Contributors]

wrt running tests:
See https://gwt-review.googlesource.com/c/gwt/+/13861 for the pattern used
in JRE earlier; and the CI was updated to run in both 7 and 8 at the same
time.

PS: Compiler tests ("jjs.test.Java8Test") was different because we really
needed to run the compiler tests with new syntax inside Google which didn't
have the Java8 VM at the time. It wasn't a deal breaker to be not able run
Java8 JRE tests at the time so they are not super sourced.

I recommend the same approach.


On Mon, Jun 29, 2020 at 6:45 PM Colin Alworth  wrote:

> As of somewhere in the time leading up to the GWT 2.9.0 release, it is no
> longer possible to build GWT with Java7, and similarly the decision was
> made to no longer officially support running on Java7
> (jsinterop-annotations use of "TYPE_USE", newer jetty version too I
> believe).
>
> There is still some defunct wiring in the build to handle Java 7 vs Java 8
> though, mostly with regards to running tests - since we first javac our
> java classes, and then run gwtc on them, we need to make sure that the java
> version being use can correctly compile those tests.
>
> The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some
> of the existing work on this: the main remaining piece is to decide how to
> handle javadoc. GWT has its own custom doclet to handle a few custom tags,
> "example", "gwt.include", and "tip". None of this compiles after Java 8,
> since Java 9 came with a new, incompatible API to build custom tags, so
> either we drop Java 8 support for building the toolkit, require _only_ Java
> 8 to build, support two parallel copies of the custom doc wiring, or drop
> the doc wiring entirely and remove these custom tags throughout the
> codebase.
>
> Since the release of GWT 2.9 and my own work on the above ticket, I've
> been picking back up some Java 9/10/11 JRE emulation work that I had
> previously paused, and I'm running into the issue described at the top - if
> you write a test that calls Map.of() and run it on Java8 as a GWTTestCase,
> you'll get a compile error.
>
> Two basic ways I can easily see to fix this: we can make two copies of
> each test, one as an empty "real" java type and one as supersource, or we
> can guard those tests behind java version args in the build glue like we
> did for Java7 vs Java8. The first option is clunky, and while I see this
> was done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't
> done for JRE emulation tests, and I assume there was a reason for that. The
> second option requires changing our CI to build+test on some new JRE...
>
> ...and given the constraints of the Java LTS system, and the java 8/9
> divide for custom doclet stuff, it seems like the clearest win is to move
> all the way to Java11, though continue to target java 8 releases, and test
> on all JREs up until current.
>
> So that's my pitch. For completeness, some other options that seem
> workable, keeping in mind that at present there are about 3 important JRE
> versions to support well: Java 8, Java 11, and the current stable release.
>  * Require Java8 for javadoc, supersource tests
>  * Allow any JRE 8+, use ant filters for tests for each version, maintain
> two javadoc builds
>  * Allow any JRE 8+, use ant filters, only actually produce javadoc on
> java9+ builds
>
> Other technical ways to deal with this, or have a missed an easier
> solution to one of these problems?
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA1L4gAaaEkqgWnqL%3DiKDX_aUjX1L0WThdG4yuxUyHdQMQ%40mail.gmail.com.

[gwt-contrib] Required JDK version to build GWT?

[Colin Alworth]

As of somewhere in the time leading up to the GWT 2.9.0 release, it is no 
longer possible to build GWT with Java7, and similarly the decision was 
made to no longer officially support running on Java7 
(jsinterop-annotations use of "TYPE_USE", newer jetty version too I 
believe). 

There is still some defunct wiring in the build to handle Java 7 vs Java 8 
though, mostly with regards to running tests - since we first javac our 
java classes, and then run gwtc on them, we need to make sure that the java 
version being use can correctly compile those tests.

The issue https://github.com/gwtproject/gwt/issues/9683 is tracking some of 
the existing work on this: the main remaining piece is to decide how to 
handle javadoc. GWT has its own custom doclet to handle a few custom tags, 
"example", "gwt.include", and "tip". None of this compiles after Java 8, 
since Java 9 came with a new, incompatible API to build custom tags, so 
either we drop Java 8 support for building the toolkit, require _only_ Java 
8 to build, support two parallel copies of the custom doc wiring, or drop 
the doc wiring entirely and remove these custom tags throughout the 
codebase.

Since the release of GWT 2.9 and my own work on the above ticket, I've been 
picking back up some Java 9/10/11 JRE emulation work that I had previously 
paused, and I'm running into the issue described at the top - if you write 
a test that calls Map.of() and run it on Java8 as a GWTTestCase, you'll get 
a compile error.

Two basic ways I can easily see to fix this: we can make two copies of each 
test, one as an empty "real" java type and one as supersource, or we can 
guard those tests behind java version args in the build glue like we did 
for Java7 vs Java8. The first option is clunky, and while I see this was 
done for `com.google.gwt.dev.jjs.test.Java8Test`, it clearly wasn't done 
for JRE emulation tests, and I assume there was a reason for that. The 
second option requires changing our CI to build+test on some new JRE...

...and given the constraints of the Java LTS system, and the java 8/9 
divide for custom doclet stuff, it seems like the clearest win is to move 
all the way to Java11, though continue to target java 8 releases, and test 
on all JREs up until current.

So that's my pitch. For completeness, some other options that seem 
workable, keeping in mind that at present there are about 3 important JRE 
versions to support well: Java 8, Java 11, and the current stable release.
 * Require Java8 for javadoc, supersource tests
 * Allow any JRE 8+, use ant filters for tests for each version, maintain 
two javadoc builds
 * Allow any JRE 8+, use ant filters, only actually produce javadoc on 
java9+ builds

Other technical ways to deal with this, or have a missed an easier solution 
to one of these problems?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/0aa0701b-4287-4e4c-bbef-23952898c64an%40googlegroups.com.

Re: [gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

['Frank Hossfeld' via GWT Contributors]

>
> Personally I would go with 'org.gwtproject.gwt-safecss' as groupid. It 
>> will make it much easier for gwt users to work with the module.
>>
>> What do you think?
>>
>
> Do you really mean org.gwtproject.gwt-safecss as groupId‽ I.e. 
> org.gwtproject.gwt-safecss:gwt-safecss coordinates‽
>

Oh, sorry. I mean org.gwtproject.safecss. you are right.
 

> I'd be OK with org.gwtproject:gwt-safecss, but how about 
> org.gwtproject.safetypes grouping both gwt-safehtml and gwt-safecss? (and 
> possibly gwt-safeuri, gwt-safehtml-templates 
> gwt-safehtml-templates-processor if we split further)
> Or org.gwtproject.safe-html-types, inspired by 
> https://github.com/google/safe-html-types 
> 
> ?
>

I like the idea, renaming the repo to gwt-safe-html-types and using as 
group id 'org.gwtproject.safe.type.html', 'org.gwtproject.safe.type.css', 
'org.gwtproject.safe.type.uri' ... sounds good to me.  
 

> Or just keep using the "root" package name as the groupId: 
> org.gwtproject.safehtml:gwt-safehtml (and then annotation processor, etc.) 
> and org.gwtproject.safecss:gwt-safecss (and later possibly 
> org.gwtproject.safeuri:gwt-safeuri)
>

At the first look, I would go with  'org.gwtproject.safe.type.*'. 

 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/f44ee683-daad-4bc9-9098-c486438638bbo%40googlegroups.com.

Re: [gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

[Thomas Broyer]

On Monday, June 29, 2020 at 8:43:25 AM UTC+2 frank.h...@googlemail.com 
wrote:

> Thanks everybody for input. 
>
> As @Colin already mentioned I was talking about option 4 of Thomas list. I 
> have moved gwt-safecss as separate modules into gwt-safehtml. (Need to add 
> a note at the existing GitHub repo of gwt-safecss that the modules have 
> moved after the PR is merged). I made a PR: 
> https://github.com/Vertispan/gwt-safehtml/pull/6. Everybody is welcome to 
> discuss the PR. 
>
> There is one thing that needs to be discussed:
> Atm the name of the module is the last part of the groupid. For example 
> gwt-editor: 'org.gwtproject.editor'. So, we have an easy rule how the 
> groupid and artifatid is created. 
>
> Moving gwt-safecss into gwt-safehtml, we will have the first time two 
> modules in one repo. Both modules share the same parent Maven module.  If 
> we do nothing, the rule mentioned above will work for gwt-safehtml but not 
> for gwt-safecss. gwt-safecss has the groupid 'org.gwtproject.safehtml' 
> cause of the parent pom. I changed that, so that the groupid of gwt-safecss 
> is 'org.gwtproject.safecss'. But doing this is very unusual for a Maven 
> multi module project.
>

Actually, not that much.
Guice has com.google.inject and com.google.inject.extensions in the same 
reactor; Jetty has org.eclipse.jetty, org.eclipse.jetty.http2, 
org.eclipse.jetty.websocket, etc.
Actually, even org.apache.maven:maven-parent 
 
has submodules in different groupIds, including one that doesn't start with 
org.apache.maven (namely 
org.apache.apache.resources:apache-resources-bundles 

)
 

> Personally I would go with 'org.gwtproject.gwt-safecss' as groupid. It 
> will make it much easier for gwt users to work with the module.
>
> What do you think?
>

Do you really mean org.gwtproject.gwt-safecss as groupId‽ I.e. 
org.gwtproject.gwt-safecss:gwt-safecss coordinates‽
I'd be OK with org.gwtproject:gwt-safecss, but how about 
org.gwtproject.safetypes grouping both gwt-safehtml and gwt-safecss? (and 
possibly gwt-safeuri, gwt-safehtml-templates 
gwt-safehtml-templates-processor if we split further)
Or org.gwtproject.safe-html-types, inspired by 
https://github.com/google/safe-html-types?
Or just keep using the "root" package name as the groupId: 
org.gwtproject.safehtml:gwt-safehtml (and then annotation processor, etc.) 
and org.gwtproject.safecss:gwt-safecss (and later possibly 
org.gwtproject.safeuri:gwt-safeuri)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/35f86f90-d56f-42ce-b3b8-8f76085026d1n%40googlegroups.com.