Resolving cycle dependency between gwt-safehtml & gwt-safecss

[Frank Hossfeld]

To prepare GWT for j2cl we need to move the modules out of GWT, replace generators with ATP, etc. This is in progress and the first modules (SNAPSHOT) are released.

Migrating gwt-safehtml and gwt-safecss runs into a problem, cause gwt-safehtml depends on gwt-safecss and gwt-safecss depends on gwt-safehtml. This is a serious issue, cause one can not be build and tested without the other. 

To solve this issue, we are looking for solutions.

One solution might be to move the tests out of gwt-safehtml. But then gwt-safehtml needs to be build and deployed before the tests run and might be deployed with failing tests. That looks like a bad solution.  At the moment the idea is to move the sources and tests from gwt-safecss into gwt-safehtml and delete gwt-safecss. This will remove the cycle dependency between these two modules, but doing so, the module will be the first module that contains two old modules in one new.

Any other ideas how to solve this issue?

[Juan Pablo Gardella]

Not too much options I think, see https://stackoverflow.com/questions/55429921/how-to-fix-cyclic-dependency-between-java-modules

Maybe a new common shared module (maven artifact in this case) or merge safehtml and safecss into a new one and let them deprecated.

Juan

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8d6c785-c8d9-4eba-8cc2-0b42ecac1124o%40googlegroups.com.

[Colin Alworth]

One potential option could be moving the tests into gwt-safecss, and only release them together - the release process through sonatype will permit you to push more than one set of artifacts, test them in the staging repo, and then release to central together. That would imply using either local artifacts to build gwt-safecss (instead of pulling from central), or temporarily adding the staging repo to the pom.

It does seem simpler to just merge to gwt-safehtml - especially since I doubt that gwt-safecss is often used by itself.

[Juan Pablo Gardella]

+1 to merge them. It seems the simplest solution.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8b4addde-bf52-4a88-b38f-fd2c0493f9f9n%40googlegroups.com.

[Matt Davis]

+1 to merge. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2BkiFscwn64KFDxxoqNx5hKRWCVQZ08HkS9GkbZvw6%3D%3D_5YcWA%40mail.gmail.com.

[Michael Conrad]

As CSS and HTML are so closely tied to each other in use, having them as separate modules makes me think of excessive DB normalization (and the potential evils thereof).

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKAo3tSKeM_bywaLaQPqujdYwSe-DfGy-47JPTJnB1q%2BQHcxrA%40mail.gmail.com.

[Thomas Broyer]

AFAICT, safecss depends on SafeUri only, which currently is in com.google.gwt.safehtml, and safehtml depends on both SafeUri and SafeStyles (though only for their class names during codegen, so optional except for tests).

This means that either:

1. we split up a gwt-safeuri (with UriUtils, SafeUri, SafeUriString, IsSafeUri, etc.)
2. we split up a gwt-safehtml-templates so we can have safehtml-templates depend on both safehtml and safecss, with safecss depending on safehtml (for its safeuri)
3. we merge everything despite having separate packages and gwt.xml
4. we put everything in the same project, but still separate artifacts, so we can have tests (split into their own submodule) depend on both safehtml and safecss without having safehtml depending on safecss (given that we also need the reverse)
5. we do nothing. The dependency cycle actually only exists when none of the projects have been published (even as snapshots), so publish safehtml without the dependency (and with the corresponding tests disabled; possibly split into a separate submodule so you can easily ignore them) and then you can build safecss and publish it, and finally run safehtml tests. Once we've past the snapshots phase and actually have tagged versions, this means safehtml will always be one release of safecss behind.

Options 1, 2, and 4 are not mutually exclusive actually.

I'd personally go with all 1, 2, and 4 options, which provide fine-grain modularity for users, and a coarser one for developers (develop, test, and release everything at once). Migration from com.google.gwt to org.gwtproject would be slightly more complex than a blind "replace com.google.gwt.safehtml with org.gwtproject.safehtml", but that's already the case for gwt-event.

[Colin Alworth]

I may be putting words in Frank's mouth, but I believe the proposal to "merge" these is only to bring them into a single git repository, rather than one repository per module - so option #4 is specifically what he is proposing (with lots of room for optional other changes like 1, 2). We still very much want separate artifacts for these (many small-but-not-tiny artifacts is ideal for j2cl), and since the cycle is just around tests that seems complete enough (especially given the current annoyances in testing j2cl vs gwt2).

--

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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/10f49ebb-6824-4f2e-ba55-468566c6c156o%40googlegroups.com.

[Vegegoku]

I see the merge of both into one as the simplest solutions, so +1 to the merge

[Chani Liet]

i am agree with Vevegoku, atm gwt-resources depends on gwt-safecss and gwt-safehtml.

--

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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/052a3925-34b5-4ee1-b84b-c49a47c82a49o%40googlegroups.com.

[Frank Hossfeld]

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.

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?  

     

[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)

[Frank Hossfeld]

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.*'.