[gwt-contrib] Google Code alternative
In 4 month code.google.com will be read only and as time can pass by fast I think we might want to start discussing some alternatives. Bug tracker: 1.) Install any reasonable bug tracking software on bugs.gwtproject.org. That software should have a good API so we can migrate issues easily and possibly integrate with Gerrit: assigned issue to next release version once a review is submitted, mark issue as fixed once the review is merged and reopen the issue if a git revert has been done. That would keep the bug tracker more up-to-date without manual work. Although not really needed but a nice side effect might be that the IDE can connect to the API to show issues in the IDE and possibly assign them to you if you want to work on some issues. 2.) Move issues to Github although I am not sure if that is possible if you only have a mirror project on Github. If its not possible with just a mirror, the hardcore solution would be to fully move to Github and use some Gerrit/Github integration. A nice side effect would be that we could allow pull requests which are then reviewed in Gerrit. SVN tools project: Get rid of it for future builds. We could upload libs on bintray and use ANT to download only the ones you need to build the current checkout of gwt. Might be a bit clunky for now but if GWT switches to a build system that understands maven repos we already have libs in place on bintray. If doing so we would probably have https://bintray.com/gwtproject/libs. In order to be able to build older GWT releases from source we still need a backup of the current SVN tools repo. As it will be a read only backup it is probably fine to just convert it to git and put it on googlesource.com What do you guys think? -- J. -- 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/2d59da73-f0d3-4b84-bcc4-737c2f5c8e19%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Google Code alternative
On Thursday, April 23, 2015 at 9:41:59 PM UTC+2, Jens wrote: In 4 month code.google.com will be read only and as time can pass by fast I think we might want to start discussing some alternatives. I missed the last 2 (or 3?) Steering Committee meetings, and the minutes have not been published (or I missed them too), so I don't know if the topic has been discussed; but I had proposed that we discussed it. Bug tracker: 1.) Install any reasonable bug tracking software on bugs.gwtproject.org. That software should have a good API so we can migrate issues easily and possibly integrate with Gerrit: assigned issue to next release version once a review is submitted, mark issue as fixed once the review is merged and reopen the issue if a git revert has been done. That would keep the bug tracker more up-to-date without manual work. Although not really needed but a nice side effect might be that the IDE can connect to the API to show issues in the IDE and possibly assign them to you if you want to work on some issues. While integration with Gerrit would be a plus, that can be done similarly to how we do it with Jenkins as long as the bugtracker has an API. 2.) Move issues to Github although I am not sure if that is possible if you only have a mirror project on Github. If its not possible with just a mirror, the hardcore solution would be to fully move to Github and use some Gerrit/Github integration. A nice side effect would be that we could allow pull requests which are then reviewed in Gerrit. I'd propose we just move to GitHub: we already have an organization with a repo mirror there; we could just use gwtproject/gwt to track issues in addition to the repo mirror (and split website and gwt proper issues among the projects) Of course there are also Lighthousapp.com and the likes (Atlassian JIRA?). I don't think we want to host a bug tracker ourselves. FWIW, Go has moved to GitHub with code hosted at googlesource.com, and Bazel is using a similar setup, so it's likely that we'll see better integration in the future. Chromium and Gerrit will have similar issues. Chromium is a bit special wrt Google Code Hosting https://groups.google.com/a/chromium.org/d/topic/chromium-dev/YwwkpYyyMzU/discussion but Gerrit hasn't yet made the switch and I haven't see any discussion since the announce of Code Hosting shutting down https://groups.google.com/d/topic/repo-discuss/CWXtpoNROGI/discussion I seem to recall another discussion on the Gerrit mailing list where Luca Milanesio was proposing installing his Gerrit+GitHub integration on googlesource.com. SVN tools project: Get rid of it for future builds. We could upload libs on bintray and use ANT to download only the ones you need to build the current checkout of gwt. Might be a bit clunky for now but if GWT switches to a build system that understands maven repos we already have libs in place on bintray. If doing so we would probably have https://bintray.com/gwtproject/libs. In order to be able to build older GWT releases from source we still need a backup of the current SVN tools repo. As it will be a read only backup it is probably fine to just convert it to git and put it on googlesource.com …or just copied to Google Drive? or maybe just made available from the server that also host our Jenkins? The folder is 409Mb currently, not that much. There's also the downloads. We could upload them to either GitHub releases, or Central, for archival; or anywhere else (Google Cloud Storage? this is what Gerrit uses for its downloads) New releases should probably go right to Central, including the SDK (as a ZIP). -- 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/bf6db5a8-b63b-4f81-966f-a4c9e16877cd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Google Code alternative
At least on Google side we were assuming we will move to Github for issue tracking but I don't know if that came up in any steering committee discussions. On Thu, Apr 23, 2015 at 12:41 PM, Jens jens.nehlme...@gmail.com wrote: In 4 month code.google.com will be read only and as time can pass by fast I think we might want to start discussing some alternatives. Bug tracker: 1.) Install any reasonable bug tracking software on bugs.gwtproject.org. That software should have a good API so we can migrate issues easily and possibly integrate with Gerrit: assigned issue to next release version once a review is submitted, mark issue as fixed once the review is merged and reopen the issue if a git revert has been done. That would keep the bug tracker more up-to-date without manual work. Although not really needed but a nice side effect might be that the IDE can connect to the API to show issues in the IDE and possibly assign them to you if you want to work on some issues. 2.) Move issues to Github although I am not sure if that is possible if you only have a mirror project on Github. If its not possible with just a mirror, the hardcore solution would be to fully move to Github and use some Gerrit/Github integration. A nice side effect would be that we could allow pull requests which are then reviewed in Gerrit. SVN tools project: Get rid of it for future builds. We could upload libs on bintray and use ANT to download only the ones you need to build the current checkout of gwt. Might be a bit clunky for now but if GWT switches to a build system that understands maven repos we already have libs in place on bintray. If doing so we would probably have https://bintray.com/gwtproject/libs. In order to be able to build older GWT releases from source we still need a backup of the current SVN tools repo. As it will be a read only backup it is probably fine to just convert it to git and put it on googlesource.com What do you guys think? -- J. -- 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/2d59da73-f0d3-4b84-bcc4-737c2f5c8e19%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/2d59da73-f0d3-4b84-bcc4-737c2f5c8e19%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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%3DyUA2YeQukQDuLYbd4g%3DcAMusje7WV8ExbSY_64OukmERvHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files
Ok. It doesn't always happen to me, but I am using eclipse Luna on Ubuntu 14.04. I noticed it personally while testing magic method injection, but it has also happened at work with a standard 2.7 SDK. What I noticed is when I have a lot of files open, even if I am editing another file in a project not included in GWT, it is marked stale. I know this because I added a bunch of debugging logs while working on magic method injection, and noticed the timestamp updates. A co-worker has also reported the same issue with running full builds on a unit cache. So, it's not in SDM in particular, it's in MinimalRebuildCache (which looks only at timestamps). Once you can get enough files open that eclipse decides to touch your GWT files when saving other files, then a rebuild always happens. Then I close eclipse, and it stops happening. With my debug logging, and eclipse open, editing a file that is included, a bunch of other files were marked stale. With eclipse closed, editing the same file, and only that file was marked stale. I don't have a 100% reliable set of reproduction steps, but I have seen it on different machines using different builds = 2.7 -- 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/c7521c9c-2f25-4683-b85a-b4399268c4c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files
Oh, any my work machine is Windows, and one coworker who reported it is on mac. Both work builds are on plain 2.7 -- 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/b134cab2-4449-426a-b8e0-c0fdf6a52365%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release
I'm attempting to follow along. No real input, other than I did not realize the (perhaps obvious) nuance of JS interop handling both importing (e.g. wrapping DOM and existing libraries) and exporting. And how callbacks are both-ish. Huh. - Stephen On Wed, 22 Apr 2015 21:34:27 -0700 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: On Wed, Apr 22, 2015 at 3:06 AM, Jens jens.nehlme...@gmail.com wrote: - exports vs. export is a bit misleading. One must be used with interfaces/classes the other with methods. That issue only exists because @Js alone has no real meaning. Mostly agreed though @Js alone has meaning. As there are no exports, the methods can be pruned. This difference will be more significant when we change the output style to be more idiomatic javascript and have a closer integration with Closure compiler in the future. Yeah ok probably bad wording from my side. @Js is equivalent to @JsImport. What I wanted to express is that the export flag is kind of bad because its a marker and the act of marking something for export should already be covered by applying the corresponding annotation. So if you would have @JsExport then applying @JsExport automatically means that it is marked for export. You don't need that boolean flag then. You would end up with @JsExport(STATIC_MEMBERS) for types and @JsExport for members which seems more straight forward (yes I know @JsExport(STATIC_MEMBERS) applied to a member seems strange but you would have the same issue with @Js). Also see next inline answer. IIUC, even if we go with the Option 1, you are arguing JsExport should be separate than JsType. I disagree with that. With the new semantics, JsExport requires JsType; that is better to be explicit; when it is explicit JsExport alone doesn't have a meaning. 'marking' on top of JsType seems better to me as an attribute in JsType but I'll think more about that. - You have to type more because it is always annotation name + property + value if you can't stick with the default @Js. I'm assuming you are comparing Option 1 and Option 2 (see my recent email). Based on that I'm not sure which part you are referring. Can you give an example? I think what bugs me most are the boolean properties that are used as markers, e.g. @Js(property = true) @JsProperty @Js(export = true, property = true) @JsExport @JsProperty @Js(export = false) @Js(ignore = true) @JsIgnore It simply reads better without these flags. It is not so much an issue for more complex examples, e.g. @Js(exports = ALL, namespace = GLOBAL, name = Foo) @JsExport(ALL) @JsNamespace(GLOBAL) @JsName(Foo) I think this comes to more of aesthetics and personal preferences. Multiple annotations easily convert into an annotation hell where you can easily hit 3 annotations for members; and I can even come up with cases where you need even 4: @JsExport @JsNamepace(...) @JsName(..) @JsProperty Also single @JsIgnore doesn't have the same level of expressibility as setting export and ignore independently. Also then you have the problem when you apply JsIgnore on top of JsName or JsProperty. - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS and STATIC_MEMBERS. When I want to export a class I want to export its public API. Yes, that was my assumption as well and that's how I started. But looking at real life code inside Google, especially in places where the code is shared by different platforms, I see people choosing to only export instance members or static members. I will need to re-evaluate this after we migrate all Google code to new annotations. Interesting. Wondering why that is the case. Given that it is just a shortcut to avoid lots of @Js(ignore=true) or @Js(export = true) annotations it is not so much of an issue. However I am wondering if the shared Java code would end up better if we enforce the all public API will be exported unless you opt out using @JsIgnore route. For example a developer would then have created a static factory class and then choose to export that factory or not. But I guess we'll just trust the guys with the real world code and if you think its a good idea to have these shortcuts then fine. Personally what describes JsInterop best is the alternative using the import/export concepts. So I would stick with: Import/Export types: @JsImport: can only be applied on interfaces. @JsExport: always exports all public API in a given scope (package, class, method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore can be used to opt-out selectively. Configure import/export: @JsNamespace: import/export from/to namespace @JsName: workaround reserved keywords @JsProperty: mark method as JS property @JsIgnore: opt-out of
Re: [gwt-contrib] Incremental compiler refreshes triggered by IDE touching files
Hi James, This seemed like a pretty interesting thread. Do you still suspect it's an issue? I remember turning on the right logging ~6-12 months ago to see files get incrementally compiled/etc. with SDM first came out, but it's been awhile... I use Eclipse, so if you can refresh my memory with some steps to reproduce this, I'll see if it's happening on my end. Thanks, Stephen On Wed, 15 Apr 2015 19:04:12 -0700 (PDT) James Nelson ja...@wetheinter.net wrote: Whilst digging around trying to make some stuff go faster, I noticed something odd... I was getting a bunch of extra types getting marked stale at the beginning of a recompile, and at work, recompiles triggered even when no changes were made to Gwt-related files. So, a little debugging and I noticed that we're computing the initial stale types using timestamps. And, my IDE (yes, sigh, eclipse) is actually touching the files even when I'm not explicitly saving them. This causes these types to look stale despite there being no changes. When I close my IDE and manually edit a file via text editor, there are no longer extraneous files being marked stale. It is understandable to use timestamps when recalculating stale types after a rebind, but for the initial staleness check in UnifyAst, I think paying a little extra for file hashes instead of time stamps might save a lot of extra time recompiling files that did not actually change. If we want to save some wall time, we could calculate all the initial file hashes in a background thread on the initial compile (or store them as we load them), and then only look at the hashes if there is a timestamp difference. This would let us use timestamps as a heuristic for checking hashes. I'm not sure if IntelliJ has better respect for touching files than eclipse, but it seems like a pretty common use case for a file to get touched without changing. -- 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/20150423091130.0856026f%40sh9. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: How to build Elementals
With ant clean dist-dev work fine; the compilter build all jar. I'm using a Centos 6.4 vm for build, with Python 2.6.6. Il giorno mercoledì 22 aprile 2015 18:34:47 UTC+2, Jens ha scritto: Well the ant command is correct. Are you sure there are no other errors during build? A python script should have run during the build that generates the missing folder and its content. -- J. -- 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/95f52448-35b9-48b6-9f05-62d44321ef2c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: JsInterop @JsExport constructor works when statically compiled, fails under SDM
Oops. Couple of updates: - the second project has now stopped working in static web mode (ctors no longer exported) - I omitted to mention that the relevant test scripts can be invoked by clicking the 'Test Parent-Child' button in the first project and the 'Test ParentX-ChildX' button in the second project --A -- 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/f54b112c-5150-4011-8d71-7e0c960119d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: JsInterop @JsExport constructor works when statically compiled, fails under SDM
Oops. Couple of updates: - I omitted to mention that the relevant test scripts can be invoked by clicking the 'Test Parent-Child' button in the first project and the 'Test ParentX-ChildX' button in the second project, invoking the test_parentx_childx() function. - I'd inadvertently messed up the test_parentx_childx() script in the second project. To match the current code line 56 of LibraryApp.html should read: var ns = model/*org.eclipse.example.library.app.client.impl*/; // default namespace commented out --A -- 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/e43b8676-2f1d-4b60-9703-46b4dca00583%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: JsInterop @JsExport constructor works when statically compiled, fails under SDM
I'm little bit confused. So does it work with regular compile (without SDM) or not? If it doesn't work with regular compile, can you send us GwtTestCase that reproduces the problem? On Thu, Apr 23, 2015 at 6:35 AM, apr...@tibco.com wrote: Oops. Couple of updates: - I omitted to mention that the relevant test scripts can be invoked by clicking the 'Test Parent-Child' button in the first project and the 'Test ParentX-ChildX' button in the second project, invoking the test_parentx_childx() function. - I'd inadvertently messed up the test_parentx_childx() script in the second project. To match the current code line 56 of LibraryApp.html should read: var ns = model/*org.eclipse.example.library.app.client.impl*/; // default namespace commented out --A -- 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/e43b8676-2f1d-4b60-9703-46b4dca00583%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/e43b8676-2f1d-4b60-9703-46b4dca00583%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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%3DyUA2OoSX8d7n9%3Dp9w654zJY4SHRn55BAzkMpsNWag6K_BNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
