Deploying to org.gwtproject.* groupId

[Colin Alworth]

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.

[Thomas Broyer]

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.

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

[Thomas Broyer]

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)

[Colin Alworth]

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

[Thomas Broyer]

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)

[Jens]

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.

[Colin Alworth]

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.

[Jens]

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.

[Goktug Gokdogan]

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 <jens.ne...@gmail.com> 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+unsubscribe@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.

[Colin Alworth]

Sounds like there is enough diversity of opinion that this discussion should go on - first step seems to be deciding if we think the CLA and/or gerrit-style review is important for all artifacts deployed to org.gwtproject.

For the time being, it sounds like individual groupIds are the way forward, with the expectation of migrating projects to org.gwtproject and github.com/gwtproject once they reach a certain level of quality and stability, once we decide what that is. As per our name use policy, that should fall to the steering committee to decide, but I at least would welcome more feedback from contributors on what those standards might look like.

Likewise from that name use document, we should avoid the use of org.gwtproject packages as well until that time. This might make migration a little trickier (changing packages multiple times) as we refactor various modules out from gwt-user. For my part, I would like to see this line blurred slightly or at least clarified - code which started its life in com.google.gwt but isn't presently "controlled" by the committee due it it being in progress should perhaps not be restricted in this way (in the same way that Vaadin ships a GWT fork, but still uses com.google.gwt packages for compatibility). We could phrase this in individual projects as "This code came from GWT, and is incubating here until it is contributed back to GWT", making it clear that the project is not intended to be a third party tool, but is using the name in good faith that this will be again part of GWT soon.

[Thomas Broyer]

On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:

Sounds like there is enough diversity of opinion that this discussion should go on - first step seems to be deciding if we think the CLA

Some links about CLAs:

https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ & https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/

https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/

http://contributoragreements.org/

Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), https://www.clahub.com/

As a) purely "community-driven projects", that b) won't even be used by Google (their original author), I would say that we don't need CLAs (also, the choice of the Apache License protects the users from a lot of things already).

That said, IANAL, and I'm not doing any work here on behalf of my employer; so people for whom CLAs are important should weigh in.

 

and/or gerrit-style review is important for all artifacts deployed to org.gwtproject.

I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub pull requests have gotten a whole lot better those past years, and I have absolutely no problem using them instead of Gerrit; which is a barrier to entry that many don't even try passing (Go has had the same issue, they built tooling around it instead, and documentation, and despite that it's apparently still seen as a barrier to entry to many –Chrome and Android are different, as they're much bigger beasts already).

Keeping in mind that gwt.googlesource.com is maintained by Google which wouldn't be involved in those projects, this poses the problem of who would admin Gerrit, and whether Google would host it indefinitely for us (Google is using pull requests for a lot of projects, and this includes j2cl –still a private repository–, jsinterop-base, jsinterop-generator, and elemental2).

This all pushes for using GitHub pull requests.

Now, from my PoV, each project maintainer would be free to choose how to manage code in their repo (see below): whether to use PRs for everything (never push to master), choosing a branching and merging strategies (I for one would use rebase and/or squash, possibly manually to squash some commits and preserve others, and follow "trunk based development" –this is actually what we do for GWT already; I'd love to see everyone embrace the same view, but I'm not sure forcing a "standard" is the way to go –bikeshedding, etc.), and versioning and release strategies (I think everyone would agree on using semver, but what about maintaining several versions in parallel? releasing at a scheduled cadence –like Guava and Dagger do for instance– vs. "release when it's ready", etc.)

For the time being, it sounds like individual groupIds are the way forward, with the expectation of migrating projects to org.gwtproject and github.com/gwtproject once they reach a certain level of quality and stability, once we decide what that is.

As far as I'm concerned, I'm formatting all my code using google-java-format (and enforce it in build) and checking it with Error Prone (FindBugs could possibly be a good addition).

Wrt google-java-format, just like gofmt for Go, rustfmt for Rust, prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents bikeshedding on the formatting. I don't always like how it formats things, but at least I don't have to worry about it. “Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.”

Similarly for Error Prone, nothing to configure, just let it fail your build (early, really early).

But that's only a fraction of code quality (see also branching strategies above for another fraction).

With smaller projects, I think we might be able to run tests on BrowserStack or SauceLabs, through Travis.

Now, I'd like to advocate for more autonomy and responsibility for maintainers: manage their project the way they want, release when they want,  use Maven or Gradle as they prefer, etc. This means that there might be projects that are more stable and/or of greater quality than others (but so are modules inside gwt-user already actually).

Jenkins CI host all their plugin in their GitHub organization, and I don't remember someone being angry at the diverse levels of quality, stability, etc. Everyone seems to understand that they're maintained by different people and not "products from Jenkins". (btw, they don't seem to have a CLA either).

 

As per our name use policy, that should fall to the steering committee to decide, but I at least would welcome more feedback from contributors on what those standards might look like.

This is a good question Colin!

Fwiw, I never had the intention to ever publish my work on gwt-{http,window,history,events,places} to any (binary) repository before I contributed it "back" to the @gwtproject organization. I had no reason to keep them private, so made them public, but I don't really expect anyone to use them yet, other than to experiment and give feedback to help make them better. It always was my intention to contribute them to @gwtproject, which is why I chose those gwt-* names and used the org.gwtproject package (and groupId).

 

Likewise from that name use document, we should avoid the use of org.gwtproject packages as well until that time. This might make migration a little trickier (changing packages multiple times) as we refactor various modules out from gwt-user. For my part, I would like to see this line blurred slightly or at least clarified - code which started its life in com.google.gwt but isn't presently "controlled" by the committee due it it being in progress should perhaps not be restricted in this way (in the same way that Vaadin ships a GWT fork, but still uses com.google.gwt packages for compatibility). We could phrase this in individual projects as "This code came from GWT, and is incubating here until it is contributed back to GWT", making it clear that the project is not intended to be a third party tool, but is using the name in good faith that this will be again part of GWT soon.

Sounds good.

(won't do that for the above-mentioned projects though, as I'd like to see them moved to @gwtproject sooner rather than later; unless I'm asked to do so anyway)

As soon as we start hosting projects in the @gwtproject org, this won't really be a problem either: with Andrei' proposal to ask for the repo and then start contributing to it.

Though, what about GitHub forks that people use solely for contributing pull requests?

[Colin Alworth]

On Friday, November 17, 2017 at 10:37:59 AM UTC-6, Thomas Broyer wrote:

On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:

Sounds like there is enough diversity of opinion that this discussion should go on - first step seems to be deciding if we think the CLA

Some links about CLAs:

https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ & https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/

https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/

http://contributoragreements.org/

Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), https://www.clahub.com/

As a) purely "community-driven projects", that b) won't even be used by Google (their original author), I would say that we don't need CLAs (also, the choice of the Apache License protects the users from a lot of things already).

That said, IANAL, and I'm not doing any work here on behalf of my employer; so people for whom CLAs are important should weigh in.

 

and/or gerrit-style review is important for all artifacts deployed to org.gwtproject.

I *love* Gerrit, and use it daily at work; but I cannot ignore that GitHub pull requests have gotten a whole lot better those past years, and I have absolutely no problem using them instead of Gerrit; which is a barrier to entry that many don't even try passing (Go has had the same issue, they built tooling around it instead, and documentation, and despite that it's apparently still seen as a barrier to entry to many –Chrome and Android are different, as they're much bigger beasts already).

Keeping in mind that gwt.googlesource.com is maintained by Google which wouldn't be involved in those projects, this poses the problem of who would admin Gerrit, and whether Google would host it indefinitely for us (Google is using pull requests for a lot of projects, and this includes j2cl –still a private repository–, jsinterop-base, jsinterop-generator, and elemental2).

This all pushes for using GitHub pull requests.

Now, from my PoV, each project maintainer would be free to choose how to manage code in their repo (see below): whether to use PRs for everything (never push to master), choosing a branching and merging strategies (I for one would use rebase and/or squash, possibly manually to squash some commits and preserve others, and follow "trunk based development" –this is actually what we do for GWT already; I'd love to see everyone embrace the same view, but I'm not sure forcing a "standard" is the way to go –bikeshedding, etc.), and versioning and release strategies (I think everyone would agree on using semver, but what about maintaining several versions in parallel? releasing at a scheduled cadence –like Guava and Dagger do for instance– vs. "release when it's ready", etc.)

For the time being, it sounds like individual groupIds are the way forward, with the expectation of migrating projects to org.gwtproject and github.com/gwtproject once they reach a certain level of quality and stability, once we decide what that is.

As far as I'm concerned, I'm formatting all my code using google-java-format (and enforce it in build) and checking it with Error Prone (FindBugs could possibly be a good addition).

Wrt google-java-format, just like gofmt for Go, rustfmt for Rust, prettier+eslint for JS/CSS/etc., ktlint for Kotlin, etc. prevents bikeshedding on the formatting. I don't always like how it formats things, but at least I don't have to worry about it. “Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.”

Similarly for Error Prone, nothing to configure, just let it fail your build (early, really early).

But that's only a fraction of code quality (see also branching strategies above for another fraction).

With smaller projects, I think we might be able to run tests on BrowserStack or SauceLabs, through Travis.

Now, I'd like to advocate for more autonomy and responsibility for maintainers: manage their project the way they want, release when they want,  use Maven or Gradle as they prefer, etc. This means that there might be projects that are more stable and/or of greater quality than others (but so are modules inside gwt-user already actually).

Jenkins CI host all their plugin in their GitHub organization, and I don't remember someone being angry at the diverse levels of quality, stability, etc. Everyone seems to understand that they're maintained by different people and not "products from Jenkins". (btw, they don't seem to have a CLA either).

All sounds reasonable, but I'd want to see the committee agree as a group, and our next meeting isn't for a bout 4 weeks. Might be nice to have more process around those "maintainers" as well - adding/removing, ensuring they are active, any dispute resolution. I might be putting the cart before the horse, we can probably allocate a bunch of projects up front and worry about this in a few months.

As per our name use policy, that should fall to the steering committee to decide, but I at least would welcome more feedback from contributors on what those standards might look like.

This is a good question Colin!

Fwiw, I never had the intention to ever publish my work on gwt-{http,window,history,events,places} to any (binary) repository before I contributed it "back" to the @gwtproject organization. I had no reason to keep them private, so made them public, but I don't really expect anyone to use them yet, other than to experiment and give feedback to help make them better. It always was my intention to contribute them to @gwtproject, which is why I chose those gwt-* names and used the org.gwtproject package (and groupId).

 

Likewise from that name use document, we should avoid the use of org.gwtproject packages as well until that time. This might make migration a little trickier (changing packages multiple times) as we refactor various modules out from gwt-user. For my part, I would like to see this line blurred slightly or at least clarified - code which started its life in com.google.gwt but isn't presently "controlled" by the committee due it it being in progress should perhaps not be restricted in this way (in the same way that Vaadin ships a GWT fork, but still uses com.google.gwt packages for compatibility). We could phrase this in individual projects as "This code came from GWT, and is incubating here until it is contributed back to GWT", making it clear that the project is not intended to be a third party tool, but is using the name in good faith that this will be again part of GWT soon.

Sounds good.

(won't do that for the above-mentioned projects though, as I'd like to see them moved to @gwtproject sooner rather than later; unless I'm asked to do so anyway)

As soon as we start hosting projects in the @gwtproject org, this won't really be a problem either: with Andrei' proposal to ask for the repo and then start contributing to it.

Though, what about GitHub forks that people use solely for contributing pull requests?

External gihub forks seem to be following the same spirit of the rule as Vaadin's GWT fork I think, they just manage the release differently, and are clear that they are shipping GWT, just with a different groupId, so I'm inclined to go with it.

Likewise given Jens's and Goktug's remarks on standards and communication, I'd personally like to see more dialog on the topic before making a concrete decision and handing out control of repositories under gwtproject. Given how permanent it is to deploy to central, maybe we consider just snapshot releases for now, or third party maven repos?

[Thomas Broyer]

On Friday, November 17, 2017 at 5:37:59 PM UTC+1, Thomas Broyer wrote:

On Friday, November 17, 2017 at 4:11:18 PM UTC+1, Colin Alworth wrote:

Sounds like there is enough diversity of opinion that this discussion should go on - first step seems to be deciding if we think the CLA

Some links about CLAs:

https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ & https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/

https://web.archive.org/web/20150917011232/http://www.computerworlduk.com/blogs/simon-says/should-open-source-communities-avoid-contributor-agreements-3569648/

http://contributoragreements.org/

Some tools to manage CLAs: https://cla-assistant.io/ (by SAP), https://www.clahub.com/

As a) purely "community-driven projects", that b) won't even be used by Google (their original author), I would say that we don't need CLAs (also, the choice of the Apache License protects the users from a lot of things already).

That said, IANAL, and I'm not doing any work here on behalf of my employer; so people for whom CLAs are important should weigh in.

Fwiw, Gradle, as a project lead by a company (Gradle, Inc.), which is not our case, just ditched CLAs in favor of https://developercertificate.org: https://discuss.gradle.org/t/change-in-the-contribution-process/25011