{"action":"created","issue":{"url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/16","repository_url":"https://api.github.com/repos/vavr-io/vavr-gwt","labels_url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/16/comments","events_url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/16/events","html_url":"https://github.com/vavr-io/vavr-gwt/issues/16","id":345195822,"node_id":"MDU6SXNzdWUzNDUxOTU4MjI=","number":16,"title":"Add a pre-build step in order to mark certain core Vavr methods as @GwtIncompatible","user":{"login":"danieldietrich","id":743833,"node_id":"MDQ6VXNlcjc0MzgzMw==","avatar_url":"https://avatars0.githubusercontent.com/u/743833?v=4","gravatar_id":"","url":"https://api.github.com/users/danieldietrich","html_url":"https://github.com/danieldietrich","followers_url":"https://api.github.com/users/danieldietrich/followers","following_url":"https://api.github.com/users/danieldietrich/following{/other_user}","gists_url":"https://api.github.com/users/danieldietrich/gists{/gist_id}","starred_url":"https://api.github.com/users/danieldietrich/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danieldietrich/subscriptions","organizations_url":"https://api.github.com/users/danieldietrich/orgs","repos_url":"https://api.github.com/users/danieldietrich/repos","events_url":"https://api.github.com/users/danieldietrich/events{/privacy}","received_events_url":"https://api.github.com/users/danieldietrich/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2018-07-27T11:45:07Z","updated_at":"2018-08-05T22:59:02Z","closed_at":null,"author_association":"MEMBER","body":"Hi,\r\n\r\nwith modularization, I want to get rid of the _@GwtIncompatible_ annotations of the core Vavr lib.\r\n\r\n**Goal/Acceptance Criteria:**\r\n\r\nLet the GWT compiler know which methods are not compatible without using the `@GwtIncompatible` annotation(s) _within the core Vavr library_. For example this could be achieved by adding a pre-build step to the vavr-gwt Maven build.\r\n\r\nSee [this Twitter conversation](https://twitter.com/danieldietrich/status/1022791797410545664) about how to use [ByteBuddy]() to solve this issue.\r\n\r\nIn detail, I would suggest to explode the dependencies of vavr-gwt into the file system in a pre-build step. Furthermore we are able to rewrite/enhance the classes of our dependencies by dynamically annotating the according methods with vavr-gwt's own _@GwtIncompatible_ annotation. After that, the GWT compiler is expected to work as desired.\r\n\r\nI will add the list of methods later here."},"comment":{"url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/comments/410554693","html_url":"https://github.com/vavr-io/vavr-gwt/issues/16#issuecomment-410554693","issue_url":"https://api.github.com/repos/vavr-io/vavr-gwt/issues/16","id":410554693,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMDU1NDY5Mw==","user":{"login":"ibaca","id":1042225,"node_id":"MDQ6VXNlcjEwNDIyMjU=","avatar_url":"https://avatars0.githubusercontent.com/u/1042225?v=4","gravatar_id":"","url":"https://api.github.com/users/ibaca","html_url":"https://github.com/ibaca","followers_url":"https://api.github.com/users/ibaca/followers","following_url":"https://api.github.com/users/ibaca/following{/other_user}","gists_url":"https://api.github.com/users/ibaca/gists{/gist_id}","starred_url":"https://api.github.com/users/ibaca/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ibaca/subscriptions","organizations_url":"https://api.github.com/users/ibaca/orgs","repos_url":"https://api.github.com/users/ibaca/repos","events_url":"https://api.github.com/users/ibaca/events{/privacy}","received_events_url":"https://api.github.com/users/ibaca/received_events","type":"User","site_admin":false},"created_at":"2018-08-05T22:59:02Z","updated_at":"2018-08-05T22:59:02Z","author_association":"NONE","body":"But the RxJava GWT was not a decision, they don't want to modify its own source code so the last resort was to apply this cloning strategy. The cloning strategy is a nightmare, whatever change you made in the origin project will end up easily as a conflict. And you need to make releases per-version with this conflicting rebased codebase.\r\n\r\nAnd the cohesion is debatable. The @GwtIncompatible is just an annotation, no logic, just a flag that means that this method is compatible or not. So it might be considered \"high cohesion\" when you put this incompatibility flag in the source that is incompatible. OTOH, if you have a separated module referencing all the other modules specifying which elements are compatible or incompatible, might be considered \"low cohesion\".\r\n\r\nI see this more as the error-prone annotations. So if you are going to use the errorprone annotations to run the errorprone reports, did you put all those annotations in a separated project rebasing all those annotations just because are used with a different purpose. Those annotations describe the source code, and when you as a project decides to use those reports, you also accept to put those annotations in your source code. I see GWT compatibility flags the same way.\r\n\r\nAdding those annotations in the original source code make it much easier."}}
{"actor":{"display_login":"ibaca"}}