date:20171115

2017-11-15 Thread 'Goktug Gokdogan' via GWT Contributors

The gwt-site-webapp also has such configuration; it's used for the 
menu/navigation at http://www.gwtproject.org

https://gwt.googlesource.com/gwt-site-webapp (see pom.xml and *.gwt.xml files)

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Deploying symbolMaps in a production build

2017-11-15 Thread Ignacio Baca Moreno-Torres

https://github.com/ibaca/rxcanvas-gwt 

On Thursday, November 16, 2017 at 12:08:44 AM UTC+1, Ignacio Baca 
Moreno-Torres wrote:
>
> FYI this project is a working example of deploying a gwt app with source 
> maps. The pom is configured to included both the source map and the java 
> sources. I use site.sh to deploy as a github page.
>
> On Wednesday, November 15, 2017 at 9:40:26 PM UTC+1, AJ wrote:
>>
>> Thanks Colin.
>> That look like exactly what I need.
>> This will be a 'production' url we use to debug the issue and then 
>> re-deploy the 'real' build once we have stepped the code and found the 
>> offending null point.
>>
>> Nice to know about the stack trace.
>>
>> Thank you very much for the very detailed reply.
>>
>>
>>

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Deploying symbolMaps in a production build

2017-11-15 Thread Ignacio Baca Moreno-Torres

FYI this project is a working example of deploying a gwt app with source 
maps. The pom is configured to included both the source map and the java 
sources. I use site.sh to deploy as a github page.

On Wednesday, November 15, 2017 at 9:40:26 PM UTC+1, AJ wrote:
>
> Thanks Colin.
> That look like exactly what I need.
> This will be a 'production' url we use to debug the issue and then 
> re-deploy the 'real' build once we have stepped the code and found the 
> offending null point.
>
> Nice to know about the stack trace.
>
> Thank you very much for the very detailed reply.
>
>
>

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Deploying symbolMaps in a production build

2017-11-15 Thread AJ

Thanks Colin.
That look like exactly what I need.
This will be a 'production' url we use to debug the issue and then 
re-deploy the 'real' build once we have stepped the code and found the 
offending null point.

Nice to know about the stack trace.

Thank you very much for the very detailed reply.


-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Deploying to org.gwtproject.* groupId

It could be hard to communicate and set expectations with a live
work-in-progress gwt-project repository and via publishing on maven
central. I agree with Jens on first setting up a foundation, rules and also
maturing what GWT3 is; and in the meantime let people iterate in their own
repos which will set expectation accordingly.

On Wed, Nov 15, 2017 at 9:31 AM, Jens  wrote:

> Oh and if its just about making these small projects more discoverable
> then one could also create a single project, e.g. gwtproject/gwt3-migration
> and use the wiki for documentation and/or git submodules to link in all
> these small projects as well.
>
> -- 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/ee2066ec-2b18-
> 4921-8476-6a2195cffecc%40googlegroups.com
> 
> .
>
> 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%3DyUA1v4ZO8f0QRTok-g0vfSWDr_2v-8W%3D8Qc7hg4SOOAT4Mw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deploying symbolMaps in a production build

Symbol maps are distinct from source maps, the serve different purposes. 
Sourcemaps, when deployed with your actual source, allow the browser to ask 
the server for your Java source, so you can see if when you debug - this 
may not be something most production applications want their customers to 
be able to find.

In contrast, symbol maps are used by the server, so when the client sends 
the server a stack trace, it can figure out what that stack trace should 
have looked like in Java (see 
com.google.gwt.core.server.StackTraceDeobfuscator). This will work without 
enabling sourcemaps.

The "// #sourceURL=" is used to say to the browser "pretend that this 
string you are eval()ing is actually a file with this name and path". If 
used in conjunction with sourcemaps, then *if you have deployed sourcemaps*, 
viewing the source in your browser will show all Java classes.

To turn on production sourcemaps, add this to your .gwt.xml file (assuming 
the CrossSiteIframeLinker, which it appears you are using) if you just want 
them always on (assumes one permutation):

If you have more than one permutation, you'll want to set up a pattern in 
here, based on the docs in CrossSiteIframeLinker.gwt.xml:

This only adds the missing "// #sourceMappingURL=" to your output, but the 
sourcemaps has to actually be there for you to use it, and in the right 
place - using those custom URL features will help you change where it goes. 

Keep in mind that your webserver will not serve any content in WEB-INF/, so 
you'll need to build those somewhere else for the client to see it (see the 
-deploy flag). You would also need to add all of your java sources, and 
they are also expected to be found in the same directory as the sourcemap 
file, and remember that this may allow your users to see the app's sources.

On Tuesday, November 14, 2017 at 7:34:40 AM UTC-6, AJ wrote:
>
> Hello,
> I have an issue that only manifests in a deployed GWT application and so 
> am trying to enable source maps in the production build.
>
> I have added...
>
> 
> 
>
> ...to the project.ui.xml file and have passed -saveSource to the compiler
>
> In my war I see the WEB-INF/deploy/ProjectName/symbolMaps folder
>  containing 1A2B3C.symbolMap and 1A2B3C_sourceMap0.json
>
> My understanding is that I need to have the following comment at the 
> bottom of the various generated javascript files which are pulled in by the 
> bootstrap code
> //# sourceMappingURL=myUrl
>
> so I should see that at the bottom of 1A2B3C.cache.js found in the project 
> folder of the war (same folder as myProject.nocache.js)
>
> What I see at the end of that file is...
>
> //# sourceURL=Utmc-0.js
>
> ... and this is what is delivered in chrome devtools when I try to find 
> the source
>
> Has anyone else tried this and, if so, what am I missing?
>
>

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

Oh and if its just about making these small projects more discoverable then 
one could also create a single project, e.g. gwtproject/gwt3-migration and 
use the wiki for documentation and/or git submodules to link in all these 
small projects as well.

-- 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/ee2066ec-2b18-4921-8476-6a2195cffecc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

I've been over your gwt-events - looked good from 30 mins or so of poking 
around, but largely copy/paste, so that makes sense right?

Removing old browsers seems reasonable - if we get issues filed asking for 
old browser support, we can deal with that as needed, but these are meant 
to be modern builds of modules that still have support for old browsers. 
GWT 3 won't support the modern browsers, and even IE11 doesn't support 
Promises, so implementing Scheduler.scheduleFinally might not be possible 
without JSNI and $entry anyway... That's always been my understanding of 
the approach at least.

I'll read those other three today, but if the tests pass and the API holds 
(aside from renaming packages), it sounds like they could already be out 
there and ready for use ;). So what's the holdup? I'm being facetious, but 
I'm hoping we can make a plan that even we active contributors can follow, 
and set an easy example for others to follow.

That said, with Jens's reply in mind: If we want a CLA for projects that 
get under gwtproject.org, if we want strict code review (though I did put 
the checkstyle in my sample project), I'm going to advocate strongly for 
individual projects and personal groupIds to start with, until people who 
want to build that process are happy with it and have it deployed. The 
downside of having strict standards seems clear: not even active 
contributors are trying to meet them. At least Git gives us the ability to 
look back in history, and see where code came from in an external project, 
make sure everyone is on board with moving to gwtproject.

On Wednesday, November 15, 2017 at 11:14:34 AM UTC-6, Thomas Broyer wrote:
>
>
>
> On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>>
>> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
>> projects so far in their own repos, and not in github.com/gwtproject - I 
>> was following that example. If you guys are ready to move them now and ship 
>> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
>> objection.
>>
>> My main goal was to lower the barrier to entry - if we don't ship things 
>> that aren't under gwtproject, and we don't even put *our own projects* 
>> on gwtproject, I was concerned about how this might look to external 
>> contributors, especially given how many small projects we're going to need 
>> to have started and finished in the near future. 
>>
>> If you guys can move your projects and get them out on central,
>>
>
> I'd prefer if someone reviewed them before (particularly gwt-events; 
> gwt-http, gwt-window and gwt-history have nothing controversial in there 
> IIRC, except maybe for the fact I removed support for "old browsers" –they 
> should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
> Also wrt the choice of groupId and artifactId.
> If you'd prefer that I don't wait before I move them, that works for me; 
> but I'd rather have a second pair of (critical) eyes look at the code 
> before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
> the org.gwtproject groupId, and grant release rights to a few people; who 
> does that?)
>
> I'll change my yet-unpublished advice to be "start the project in your own 
>> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
>> to be created in gwtproject, then push your sources there in a large pull 
>> request"?
>>
>
> I'd rather go for the second advice then.
>
> (fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
> gwt-window and gwt-history, and have it show clearly and cleanly in the 
> commit history; it took some time but at least they can serve as examples)
>

-- 
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/ac438217-1e68-4d98-9b4f-b53fded66538%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

You don't build a house starting with the windows, you need a solid
foundation.

IMHO you/we first need to figure out how these smaller projects should be
handled in the future. Does the gwtproject organization enforce
requirements on these projects or are they totally independent and just
sharing a common groupId? Does gwtproject organization still forces CLAs?
Who would store them? Still Google even though they will probably become
less involved into gwtproject.org in the future once they are fully moved
to J2CL? Is it allowed for maintainers to switch from CLA to DCO and use
pull requests + Github review instead? Or should maintainers store CLAs on
their own? Maybe it is easier to put everything under the gwtproject
umbrella into the same repository so a future "Complete GWT SDK" is easier
to manage/build.

Maybe most questions have already been answered behind closed doors but for
me personally there is just to much unanswered questions that I wouldn't
push anything to org.gwtproject and instead leave things as they are:
experiments of contributors using their own groupIds. First figure out and
set in stone the way gwtproject organization, contribution and possibly
centralized releases (like eclipse releases) should work in the future.

IMHO official libs must go through some official, defined process to ensure
quality.

-- 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/dd643fda-f7ff-4d49-b9d8-78a34320029a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId



On Wednesday, November 15, 2017 at 6:02:03 PM UTC+1, Colin Alworth wrote:
>
> Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
> projects so far in their own repos, and not in github.com/gwtproject - I 
> was following that example. If you guys are ready to move them now and ship 
> them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
> objection.
>
> My main goal was to lower the barrier to entry - if we don't ship things 
> that aren't under gwtproject, and we don't even put *our own projects* on 
> gwtproject, I was concerned about how this might look to external 
> contributors, especially given how many small projects we're going to need 
> to have started and finished in the near future. 
>
> If you guys can move your projects and get them out on central,
>

I'd prefer if someone reviewed them before (particularly gwt-events; 
gwt-http, gwt-window and gwt-history have nothing controversial in there 
IIRC, except maybe for the fact I removed support for "old browsers" –they 
should theoretically work in IE10+, Firefox ESR, and evergreen browsers).
Also wrt the choice of groupId and artifactId.
If you'd prefer that I don't wait before I move them, that works for me; 
but I'd rather have a second pair of (critical) eyes look at the code 
before I push anything to Central (btw, we need to ask Sonatype OSSRH for 
the org.gwtproject groupId, and grant release rights to a few people; who 
does that?)

I'll change my yet-unpublished advice to be "start the project in your own 
> repo, and ask it be moved once it is ready" or perhaps "ask for a new repo 
> to be created in gwtproject, then push your sources there in a large pull 
> request"?
>

I'd rather go for the second advice then.

(fwiw, I tried to follow your yet-unpublished blog post for gwt-http, 
gwt-window and gwt-history, and have it show clearly and cleanly in the 
commit history; it took some time but at least they can serve as examples)

-- 
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/c2e3904a-8eee-4257-b7a9-a3b9d91d570d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

Thanks guys - I guess I'm confused as to why Daniel and Thomas have their 
projects so far in their own repos, and not in github.com/gwtproject - I 
was following that example. If you guys are ready to move them now and ship 
them (0.9 or 1.0-beta-n, either works for me) to central, then I have no 
objection.

My main goal was to lower the barrier to entry - if we don't ship things 
that aren't under gwtproject, and we don't even put *our own projects* on 
gwtproject, I was concerned about how this might look to external 
contributors, especially given how many small projects we're going to need 
to have started and finished in the near future. 

If you guys can move your projects and get them out on central, I'll change 
my yet-unpublished advice to be "start the project in your own repo, and 
ask it be moved once it is ready" or perhaps "ask for a new repo to be 
created in gwtproject, then push your sources there in a large pull 
request"?

-- 
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/7e14e048-a2ba-4d56-b314-909a19cc55b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

On Wednesday, November 15, 2017 at 5:40:11 PM UTC+1, Andrei Korzhevskii 
wrote:
>
> I vote for boring way, ie allocate these (module) projects on github and 
> follow usual pull requests workflow and deploy it as snapshots during 
> development.
> Reasoning is that I don't see much sense in spreading community efforts in 
> multiple projects and then picking the right one.
>

That would work too (basically what my "review and move" suggestion does, 
but with pull requests).
But it doesn't really prevent spreading community efforts; there still 
needs some coordination to prevent two people from starting working on the 
same project (Colin has a spreadsheet already for that coordination effort, 
so there's no real need for "picking the right one" in the end)

-- 
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/84f8e9df-122d-450a-af2e-821f19f7e1df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId

2017-11-15 Thread Andrei Korzhevskii

I vote for boring way, ie allocate these (module) projects on github and 
follow usual pull requests workflow and deploy it as snapshots during 
development.
Reasoning is that I don't see much sense in spreading community efforts in 
multiple projects and then picking the right one.

-- 
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/a889ecc5-ec3f-41f9-a7f5-99b4f0bcbfba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: Deploying to org.gwtproject.* groupId



On Wednesday, November 15, 2017 at 5:00:59 PM UTC+1, Colin Alworth wrote:
>
> I'm about to put out a blog post with a bunch of details on how one might 
> port gwt-user.jar modules out (thanks to the hard work of those who have 
> started this effort already, especially Dan Kurka and Thomas Broyer), and 
> once those are ready to be consumed, we'll certainly want the various 
> artifacts on maven central. The goal in this is to start motivating 
> contributors and community members to assist in the migration work 
> necessary to get us within reach of a GWT 3 ecosystem.
>
> The topic of "where we deploy early efforts" has come up a few times 
> behind relatively closed doors - multiple times in steering calls, and of 
> course at length at GwtCon this year. So, opening it up for broad 
> discussion: should we expect to start pushing release to org.gwtproject.* 
> right away, and if not, are we encouraging individual contributors to push 
> to their own groupIds until we *are* ready?
>
> Case for org.gwtproject: "centralized" jenkins server with creds to push, 
> making it easy to add a project (automatically?) and get it out there so 
> others can use it. Might want some manual checks on what is going out (or 
> else whoever is responsible for the groupId will look silly if it turns out 
> we are shipping malware), which implies full or partial review (manual 
> process) of each release before pushing the button. Makes it clear right 
> away to people searching maven central that they have found the right new 
> modules, since they are all under the org.gwtproject umbrella.
>
> Case for individual groupIds: makes it clear to early adopters that these 
> are "incubator" projects, and they should probably vet them themselves, or 
> they are relying on the community and goodwill of other developers, and 
> that these migrated modules are *not* official - at least not yet. Lower 
> friction, gets snapshots and releases out faster.
>
> No matter how we go, I am certain that we'll want to push to 
> org.gwtproject once these modules are stabilizing and we (gwt maintainers 
> and contributors) are confident in the code being shipped. 
>
> Thoughts? Which ever way we go, I'd like to see the already ready-for-use 
> artifacts deployed within a few days - if that is too soon for 
> org.gwtproject, then I think that makes the choice clear, or else who knows 
> how long we'll be waiting.
>

I don't really have a strong opinion, except that:

   - IFF we go with org.gwtproject, then we should only publish 0.* 
   versions (or possibly 1.0.0-beta-* versions).
   - I would also expect all projects under the org.gwtproject groupId to 
   be hosted in the https://github.com/gwtproject GitHub organization (or 
   gwt.googlesource.com, but I don't even know who exactly has admin rights to 
   create new projects there) and with a first "review" step by a GWT core 
   contributor (besides the author). So this is maybe too soon if you want to 
   get things out "within a few days".
   - Fwiw, I'm happy with using JitPack for my 
   "experiments": https://jitpack.io/#tbroyer/gwt-events, 
   https://jitpack.io/#tbroyer/gwt-http, 
https://jitpack.io/#tbroyer/gwt-window, https://jitpack.io/#tbroyer/gwt-history 
   (fwiw, I've been using Gradle composite builds before I pushed code to 
   GitHub; something you can do with Maven using an ad-hoc aggregator POM)

So, IMO, the steps are, in order:

   1. review candidate projects (the review includes the choice of groupId 
   and artifactId; for example, should it be org.gwtproject.event or 
   org.gwtproject.events? gwt-event or gwt-events? or maybe just 'event' or 
   'events'? gwt-event-compat or gwt-compat-event? org.gwtproject.window or 
   org.gwtproject.user.window? or just org.gwtproject?)
   2. move projects to gwtproject organization
   3. deploy snapshots to Sonatype OSSRH (or any other Maven repo, like 
   BinTray/JCenter, but OSSRH is already widely used I believe); I'd expect 
   this to be consistent across every org.gwtproject artifact. Possibly setup 
   build.gwtproject.org to deploy snapshots automatically (but probably use 
   Travis CI for pull requests).
   4. cut pre-releases (I'd only expect us to release a 1.0 final once we 
   get to a state where it's usable with j2cl –and this includes settling 
   first on how artifacts should look like for j2cl; but I'm open to 
   discussion on this, e.g. release 1.0 for gwt2 only, and a 2.0 with j2cl 
   support, depending on the needed changes to get that support, might not be 
   needed at all)

Those steps would also apply to candidate projects from the community in 
the future.

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

[gwt-contrib] Deploying to org.gwtproject.* groupId

I'm about to put out a blog post with a bunch of details on how one might
port gwt-user.jar modules out (thanks to the hard work of those who have
started this effort already, especially Dan Kurka and Thomas Broyer), and
once those are ready to be consumed, we'll certainly want the various
artifacts on maven central. The goal in this is to start motivating
contributors and community members to assist in the migration work
necessary to get us within reach of a GWT 3 ecosystem.

The topic of "where we deploy early efforts" has come up a few times behind
relatively closed doors - multiple times in steering calls, and of course
at length at GwtCon this year. So, opening it up for broad discussion:
should we expect to start pushing release to org.gwtproject.* right away,
and if not, are we encouraging individual contributors to push to their own
groupIds until we *are* ready?

Case for org.gwtproject: "centralized" jenkins server with creds to push,
making it easy to add a project (automatically?) and get it out there so
others can use it. Might want some manual checks on what is going out (or
else whoever is responsible for the groupId will look silly if it turns out
we are shipping malware), which implies full or partial review (manual
process) of each release before pushing the button. Makes it clear right
away to people searching maven central that they have found the right new
modules, since they are all under the org.gwtproject umbrella.

Case for individual groupIds: makes it clear to early adopters that these
are "incubator" projects, and they should probably vet them themselves, or
they are relying on the community and goodwill of other developers, and
that these migrated modules are *not* official - at least not yet. Lower
friction, gets snapshots and releases out faster.

No matter how we go, I am certain that we'll want to push to org.gwtproject
once these modules are stabilizing and we (gwt maintainers and
contributors) are confident in the code being shipped.

Thoughts? Which ever way we go, I'd like to see the already ready-for-use
artifacts deployed within a few days - if that is too soon for
org.gwtproject, then I think that makes the choice clear, or else who knows
how long we'll be waiting.

--
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/88b63997-3178-4d63-9f32-61cf531461c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT



On Wednesday, November 15, 2017 at 11:19:56 AM UTC+1, Jens wrote:
>
>
> Thanks for the early response. Can you give an example of getData(String 
>> key) method.
>>
>
> Sure, assuming your values are only strings you can do
>
> public native String getData(String key) /*-{
>   return this.data[key];
> }-*/;
>
> If your values can also be number, boolean, JS Object you need additional 
> methods, possibly also doing some type checking. 
>
> Given that JSNI won't work in future GWT I would really take a look at 
> jsinterop.base.JsPropertyMap which is a generic class to work on JavaScript 
> objects.
>
> https://github.com/google/jsinterop-base/blob/master/java/jsinterop/base/JsPropertyMap.java
>

@JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
public class Result {
  String[] columns; // or JsArrayLike
  JsPropertyMap data;
}

That should be enough (and much much simpler/shorter than with JSNI).

Migrating a JSNI getData(String):String to JsInterop would be quite easy 
too:

@JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
public class Result {
  @JsProperty public native String[] getColumns();
  @JsOverlay public String getData(String key) {
return getData().get(key);
  }
  @JsProperty private native JsPropertyMap getData();
}



-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT

2017-11-15 Thread Kirill Prazdnikov

JSNI is not recommended. 

If you can assign types, go with JsInterop, if not -> then you have a map 
String->?

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT

2017-11-15 Thread Abhishek Banerjee

Thanks a bunch!!

On Wednesday, 15 November 2017 15:49:56 UTC+5:30, Jens wrote:
>
>
> Thanks for the early response. Can you give an example of getData(String 
>> key) method.
>>
>
> Sure, assuming your values are only strings you can do
>
> public native String getData(String key) /*-{
>   return this.data[key];
> }-*/;
>
> If your values can also be number, boolean, JS Object you need additional 
> methods, possibly also doing some type checking. 
>
> Given that JSNI won't work in future GWT I would really take a look at 
> jsinterop.base.JsPropertyMap which is a generic class to work on JavaScript 
> objects.
>
> https://github.com/google/jsinterop-base/blob/master/java/jsinterop/base/JsPropertyMap.java
>
> -- J.
>

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT



> Thanks for the early response. Can you give an example of getData(String 
> key) method.
>

Sure, assuming your values are only strings you can do

public native String getData(String key) /*-{
  return this.data[key];
}-*/;

If your values can also be number, boolean, JS Object you need additional 
methods, possibly also doing some type checking. 

Given that JSNI won't work in future GWT I would really take a look at 
jsinterop.base.JsPropertyMap which is a generic class to work on JavaScript 
objects.
https://github.com/google/jsinterop-base/blob/master/java/jsinterop/base/JsPropertyMap.java

-- J.

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT

2017-11-15 Thread Abhishek Banerjee

Thanks for the early response. Can you give an example of getData(String 
key) method.

On Wednesday, 15 November 2017 14:49:56 UTC+5:30, Jens wrote:
>
> You can use JSONObject, a custom JavaScriptObject with JSNI getColumns() 
> and getData(String key) methods or use JsPropertyMap from jsinterop.base 
> library.
>
> -- J.
>

-- 
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 post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamic values in json parsing with GWT