vaadin / platform Goto Github PK

Generate and deploy javadoc for the vaadin artifact in addition to vaadin-core. The whole platform javadoc should be made available in vaadin.com/api. Related to #153 and #105.

@ZheSun88 commented on Tue Jun 19 2018

This is basically the reverse change for the issue #298
remove the separate release configuration for spring-boot-starter(snapshot and publish),
revert POM setting.

@pleku commented on Tue Jun 19 2018

This was proposed by @mstahv as per recommended by @snicoll (?).

If we do this, eg. just release the vaadin-spring-boot-starter as an artifact together with the add-on and put both to the vaadin platform BOM, then the users will have to declare both the vaadin-spring-boot-starter and the vaadin-core as dependency to get everything in, like the component Java APIs. This is because the vaadin-spring-boot-starter does not anymore depend on the vaadin-core and thus it only depends on the add-on (and transitively on Flow, but not on components).

Or then we add all the component integrations as a dependency to the vaadin-spring-boot-starter, which makes it a bit weird IMO, like almost a "competing" thing to vaadin-core.

Please, how should it be @mstahv & @snicoll ?

@snicoll commented on Tue Jun 19 2018

This was proposed by @mstahv as per recommended by @snicoll (?).

The only thing that rings a bell is regarding the pluginManagement in the Vaadin bom. In Vaadin 8, there is dependency management for the starter and, IMO, you should keep that with 10 as removing it is a breaking change.

I am not sure I understand how that discussion is related to this particular issue though.

@pleku commented on Tue Jun 19 2018

The only thing that rings a bell is regarding the pluginManagement in the Vaadin bom. In Vaadin 8, there is dependency management for the starter and, IMO, you should keep that with 10 as removing it is a breaking change.

Yes that is true, and that is what we had originally also for V10. But currently since in V10 the framework (flow) doesn't include the components nor have those as a dependency, those need to be declared separately. That is what the platform dependencies are for, eg. vaadin-core, it combines versions of Flow and the component integrations. See https://github.com/vaadin/platform/blob/master/vaadin-core/pom.xml

That is why we moved the vaadin-spring-boot-starter to be outside of the vaadin-bom and made it use it and have dependencies for vaadin-core and vaadin-spring-boot. The starter was following the platform versioning.

I am not sure I understand how that discussion is related to this particular issue though?

The issue is that if we move the starter to be back in the vaadin-bom, then you still have to declare vaadin-core as a dependency, and not just vaadin-spring-boot-starter to get all the things you need. Or we need to add eg. the component dependencies to the vaadin-spring-boot-starter.

@snicoll commented on Tue Jun 19 2018

Sorry, I still don't understand why adding the starter to the vaadin-bom means that the starter can't rely on vaadin-core. From a naming perspective it looks broken as I would definitely expect something called vaadin-bom to provide dependency management for vaadin-core.

If you decide to require a separate bom, then so be it but my general recommendation about this is as follows:

• The purpose of the starter is to bring a reasonable set of dependencies for the getting started use case. If you believe that vaadin-core is part of this list (or has to be for backward compatible reason), then it must be provided by the starter
• There was a BOM available that manages both the Vaadin framework versions and the Spring integration version (via the starter). I'd appreciate if you keep it that way. Having a bom for everything the starter manages but the starter feels broken to me. Again, that doesn't mean it has to be the same bom coordinates but I certainly appreciate if that was the case.

@pleku commented on Tue Jun 19 2018

vaadin-bom to provide dependency management for vaadin-core.

It does so.

What makes it weird to me, sorry it might be just due to my limited knowledge, is that then we'd have to release the vaadin-spring-boot-starter with a dependency to the previous version of the vaadin-core, than what will get released in the next platform release, in which the starter will also be a part of.

In each platform release first the vaadin-bom, is released and then the vaadin-core which uses the released vaadin-bom.

Thus, when you declare a dependency to vaadin-spring-boot-starter and use the vaadin-bom eg, 10.0.1, I presume (but I'm not sure) that the BOM overrides the dependencies for the transitive dependency of vaadin-core, which will be for that particular vaadin-spring-boot-starter the previous version, eg. 10.0.0.

Oh how fun Maven is (sorry again)

@snicoll commented on Tue Jun 19 2018

In each platform release first the vaadin-bom, is released and then the vaadin-core which uses the released vaadin-bom.

Sorry to comment on a situation I don't fully understand but that looks broken to me. The very purpose of a BOM is to be a public contract for your users. If you release the bom first and then vaadin-core, does the bom refers to a version of vaadin-core that is not yet available?

The valid process for a BOM is to release the various components and at the very end the BOM that defines the various versions to use for a particular version of the bom (here the Vaadin version). An alternative is to have the BOM as part of the release process of the rest of those various components so that they are all released in one go.

@mstahv commented on Thu Jun 21 2018

Maybe the issue is that vaadin-core uses vaadin-bom (and vica versa). There is kind of a circular dependency. I guess we should change it so that vaadin-core should define the versions of its dependencies without the bom (maybe define versions as properties in parent -> can be defined just once for both core and bom). Just throwing ideas.

@pleku commented on Thu Jun 21 2018

Yes, there is a circular dependency.

We've now added the starter to the platform BOM d28eee6

But the starter is still released separately from the platform, which is an issue as it should be inside the platform. We'll fix that by moving the starter from this repository to the platform.

@mstahv commented on Thu Jun 21 2018

👍 That probably makes it easier to do the release properly. Land this before attacking that: vaadin/spring#323 (review)

@ZheSun88 commented on Mon Jun 25 2018

till now, i think this ticket can be closed.

@mstahv commented on Mon Jun 25 2018

The starters still isn't moved to platform repository, is there a separate issue for that?

@ZheSun88 commented on Mon Jun 25 2018

I will reopen this issue.

@pleku commented on Mon Jun 25 2018

There has been a mistake in the platform BOM, simply just a typo in the version property for the vaadin-spring-boot-starter, thus the platform BOM 10.0.0 declares a non-existing version of vaadin-spring-boot-starter.

There will soon be a new platform & vaadin-spring-boot-starter releases, version 10.0.1, which fixes that.

@denis-anisimov commented on Thu Jul 26 2018

I don't understand what should be done in the end.
There is a long discussion but the final agreement is unclear.

@snicoll commented on Thu Jul 26 2018

Let me try to summarize my thoughts from a start.spring.io and general Maven perspective.

Vaadin 8 offers a vaadin-bom that provides dependency management for Vaadin artifacts. This includes the Spring support and the starter version. If a user imports this bom then Vaadin's opinions in term of dependency management are applied. They can therefore add the starter without bothering about the version. If they want to use an optional Vaadin artifact, they can add it without bothering about the version and the bom makes sure things are consistent.

This issue is about how Vaadin 10 broke that. I am asking to restore to this behaviour and, if not possible, discuss why that is and what options are available.

One important point in the discussion is "Vaadin artifacts". A "Vaadin" bom can't really have an opinion about third party dependencies (for instance SLF4J) unless Vaadin considers itself a "platform". If they do, that's fine but I'd argue that there is a need for what vaadin-bom used to be in 8.

Vaadin 10 has been removed from start.spring.io for this reason and I hope to see it re-added soon. Let me know if I can help in any way.

@denis-anisimov commented on Thu Jul 26 2018

Sure.
This is a description of desired behavior.
But we should have here in the ticket final design decision how exactly it should be done.

And this is what my comment about: there should be a clear instructions what to do (and this is request for our team).
At the moment there is a lot of comments with various opinions/suggestions/thoughts but no final clear agreed solution how to solve this ticket. That's what I'm requesting from our team.

@pleku commented on Mon Aug 06 2018

At the moment there is a lot of comments with various opinions/suggestions/thoughts but no final clear agreed solution how to solve this ticket. That's what I'm requesting from our team.

What is still remaining is:

But the starter is still released separately from the platform, which is an issue as it should be inside the platform. We'll fix that by moving the starter from this repository to the platform.

So thus the starter module should be moved and released in the platform, instead of here.

@denis-anisimov commented on Mon Aug 06 2018

Should this ticket be moved into platform then ?

@pleku commented on Mon Aug 06 2018

I don't think it matters that much, but sure.

Hi, i think a color picker would be very useful. So i made it, by extending the ComboBox class. Hope it is useful to someone or something similar could be added in future

import com.vaadin.flow.component.Component;
import com.vaadin.flow.component.button.Button;
import com.vaadin.flow.component.combobox.ComboBox;
import com.vaadin.flow.component.dialog.Dialog;
import com.vaadin.flow.component.html.Div;
import com.vaadin.flow.component.textfield.TextField;
import com.vaadin.flow.data.renderer.ComponentRenderer;

public class ColorComboBox extends ComboBox<String>  {
	
	public ColorComboBox(String label) {
	 
		this.setLabel(label);
		this.setItems("#e6194b", "#3cb44b", "#ffe119", "#4363d8", "#f58231", "#911eb4", "#46f0f0", "#f032e6", "#bcf60c", 
				"#fabebe", "#008080", "#e6beff", "#9a6324", "#fffac8", "#800000", "#aaffc3", "#808000", "#ffd8b1", "#000075", "#808080", "#ffffff", "#000000");
	 
		
		this.addValueChangeListener(event -> {
			this.getElement().getStyle().set("--lumo-body-text-color", event.getValue());
		});
		
		this.setRenderer(new ComponentRenderer<Component, String>(item -> {
		    Div colorDiv = new Div();
		    colorDiv.setText(item);
		    colorDiv.setWidth("100%");
		    colorDiv.getStyle().set("background", item);
		    colorDiv.getStyle().set("color", labelColor(item));
		    colorDiv.getStyle().set("border", "5px solid "+item);
		    colorDiv.getStyle().set("border-radius", "3px");
		    return colorDiv;
		}));
		
	}
	
	private String labelColor(String hex) {
		
	    if (hex.indexOf('#') == 0) {
	        hex = hex.replace("#", "");
	    }
 
	    int r = Integer.parseInt(hex.substring(0, 2), 16);
	    int g = Integer.parseInt(hex.substring(2, 4), 16);
	    int b = Integer.parseInt(hex.substring(4, 6), 16);
	  
        // http://stackoverflow.com/a/3943023/112731
        return (r * 0.299 + g * 0.587 + b * 0.114) > 186
            ? "#000000"
            : "#FFFFFF";
		 
	}
	
}

Split the platform BOM into two parts

Spring BOM

• Flow + components
• Pro (inc. TB with old Selenium)
• No WebJars
• No SLF4J
• Not compatible with enforcer

Vaadin BOM

• Includes Spring BOM
• WebJars
• TB with new Selenium
• SLF4J
• Compatible with enforcer

Same as #257 but for V10

• Create a 10.0 branch
• Protect it the same way as master in GitHub
• Change current build confs to use that
• Change create build confs to release 11.x from master

Used snapshot version of spring is v10 snapshot version, instead of right one.

Root of cause is in versioning of vaadin-spring not working with automatic snapshot -version generation.

Website feedback:

link

This should be generator-polymer-init-vaadin-elements-app

After fixing this, please close the issue vaadin/vaadin.com#51

Currently platform build generates 10.0 snapshot with old Flow version (and potentially some other dependencies' snapshots are also outdated).

This makes it impossible to verify starters against the newest Flow snapshot.

We need to:

• create protected 10.0 branch from the current master so that we can release fixes for the 10.0 version
• bump all the versions (in pom.xml, templates and versions.json) in master branch to use the latest snapshots and have 11.0 platform version there
• update flow-starters to use that version
• update all Bender jobs affected

There is a test for that in Vaadin 7/8, it should be ported here

Currently the BOM references two non-existing versions of vaadin-charts-flow and vaadin-board-flow.

Here is the specifics:

 Could not resolve all files for configuration ':compileClasspath'.
    > Could not find com.vaadin:vaadin-charts-flow:6.0.0.beta1.
      Searched in the following locations:
          https://repo.maven.apache.org/maven2/com/vaadin/vaadin-charts-flow/6.0.0.beta1/vaadin-charts-flow-6.0.0.beta1.pom
          https://repo.maven.apache.org/maven2/com/vaadin/vaadin-charts-flow/6.0.0.beta1/vaadin-charts-flow-6.0.0.beta1.jar
          https://maven.vaadin.com/vaadin-prereleases/com/vaadin/vaadin-charts-flow/6.0.0.beta1/vaadin-charts-flow-6.0.0.beta1.pom
          https://maven.vaadin.com/vaadin-prereleases/com/vaadin/vaadin-charts-flow/6.0.0.beta1/vaadin-charts-flow-6.0.0.beta1.jar
      Required by:
          project : > com.vaadin:vaadin:10.0.0.beta2
    > Could not find com.vaadin:vaadin-board-flow:1.0.0.beta2.
      Searched in the following locations:
          https://repo.maven.apache.org/maven2/com/vaadin/vaadin-board-flow/1.0.0.beta2/vaadin-board-flow-1.0.0.beta2.pom
          https://repo.maven.apache.org/maven2/com/vaadin/vaadin-board-flow/1.0.0.beta2/vaadin-board-flow-1.0.0.beta2.jar
          https://maven.vaadin.com/vaadin-prereleases/com/vaadin/vaadin-board-flow/1.0.0.beta2/vaadin-board-flow-1.0.0.beta2.pom
          https://maven.vaadin.com/vaadin-prereleases/com/vaadin/vaadin-board-flow/1.0.0.beta2/vaadin-board-flow-1.0.0.beta2.jar
      Required by:
          project : > com.vaadin:vaadin:10.0.0.beta2

It would be a good idea to change the release process so that the BOM is updated last with verified versions of the dependencies. Otherwise you will break everyones build every time you release for those who depend on the latest version.

Especially for maintenance releases, it would be nice to see a list of updated parts and their new version numbers linking to their release notes under the Changes since previous version heading

There is a workaround to do a compare between two versions and then navigating to the release notes from the list of all components.

Create a platform specific readme. The readme should describe what the platform is, what it contains and link to https://github.com/vaadin/vaadin + vaadin.com.

Contents should be described as a table:

• Flow
• Flow components
• Testbench
• Designer

Hello,

Spring Boot is only creating server side code (with or without Vaadin depending on the option selected).

So now people are adopting jHipster which gives a UI bundle as well.
So suggesting Vaadin be integrated with jHipster and appropriate code generated.

thanks
Jeevan

It would be a good habit for all artifacts published in maven central to reference only artifacts that are available in maven central.

This causes issue like these:
spring-io/initializr#694

When you try to change header columns position, on google chrome you can drag to few positions, not all positions, seems to be blocked in some cases, really weird.

Same problem does not happen on firefox

The BOM should include the Webjar of vaadin-valo-theme in a version compatible with the already included Vaadin Elements Webjar (currently v2.0.0-alpha3).

The release script should:

• For JS
  • For each section in the metadata file
    • Tag release based on the staging-#version# branch
    • Push the tag
    • Delete the staging branch
• For Java
  • Publish the staging repository containing boms and poms
• Tag the platform changeset with the release version number

Currently com.vaadin:vaadin:10.0-SNAPSHOT has a compile dependency on com:vaadin:flow-server-production-mode which causes Flow applications to always run in production mode even if builds were created for development.
This for example, might cause issues when applications try to use dependency filters to target bundles only in production as such bundles will not exist in development builds.

I'm not sure to which repo or team the Java API, and their examples are, so I write this generally to the platform.

On https://vaadin.com/components/vaadin-button/java-examples, there is a broken image which looks bad.

Platform PR's should be validated with vaadin.com.

• Build platform snapshot on PR
• Use those to build&test vaadin.com
• Don't block the PR if the build fails, since vaadin.com might need to be fixed

Integrate #247 and #251 to V11.

In the documentation (https://github.com/vaadin/flow/blob/master/flow-documentation/flow-components/tutorial-flow-components-setup.asciidoc) only excluding webjars per element is described. How to exclude them all?

Use same CamelCase as other components like ComboBox or ListBox

For each section in the metadata file, generate a Maven bom

Using the metadata file created in #2, generate one section-bom.pom using the section as the artifact id and a <dependencyManagement> tag with version information for all sub artifacts which define a javaVersion. Dependencies which exist in the metadata file itself (e.g. vaadin-core) should be marked as <type>import</type>

In addition to the bom file, a section.pom should be generated for each section. This imports the corresponding bom file and defines a <dependencies> section with all dependencies included in the bom.

Finally the generated boms and poms are pushed to a Sonatype staging repository for testing and release

• Create a protected 11.0 branch
• Create build configuration for 11.0 branch
• Update master platform versions for 12.0
• Make sure there is a build configuration to release 12 snapshot from master
• Make sure there is a build configuration to release 12 (alpha) from master

Once all of v10 are done, release platform 10.0.3. Remember to update vaadin.com as well.

The javadocs are generated after #105 but those are not deployed anywhere, would expect those to be found from here https://maven.vaadin.com/vaadin-prereleases/com/vaadin/vaadin-core/10.0.0.beta9/

Split the platform BOM into two parts

Spring BOM

• Flow + components
• Pro (inc. TB with old Selenium)
• No WebJars
• No SLF4J
• Not compatible with enforcer

Vaadin BOM

• Includes Spring BOM
• WebJars
• TB with new Selenium
• SLF4J
• Compatible with enforcer

Currently the release notes don't list mobile firefox as a supported browser. Would be better to explicitly tell that it is not supported as long as we have no plans in supporting it.

It is rather cumbersome to test some particular feature (bugfix) in the project that depends on a platform: you have to override lots of dependencies (especially when it comes to components) to get a working build.

Also, having a snapshot build will allow us to test things easily on any part of the platform being changed.

When doing mvn dependency:tree for a project using Vaadin 10.0.1, the output contains org.webjars.bowergithub.vaadin:vaadin-item:jar:2.0.0:compile (version selected from constraint [2.0.0,3)), indicating that the bom does not define a vaadin version for the vaadin-item webjar even though it is a transitive dependency of vaadin-combo-box.

Could be a good idea to avoid similar situations in the future by adding a test that verifies that the output of dependency:tree doesn't contain the string version selected from constraint.

Currently release notes states under Application servers the following: IBM WebSphere Application Server 8.5 Liberty and 9.

In order to avoid confusion over supported versions, this could be stated as IBM WebSphere Application Server 8.5 Liberty Profile and 9, as Liberty could be taken as the Continuous Delivery stream version (currently 18.0.0.2)

All three starters need to be checked with platform snapshot: nightly and on each PR to the platform.

IT tests for two starters are available at https://github.com/vaadin/flow-starters

Things to consider:

• Starters cannot have tests in their master branch due to license restrictions of the ProTools and fear of overcomplicating pom.xml for customers.
• Starters' tests might get broken by some changes in Flow and it might be considered as ok (breaking changes). In this case, we should be able to adjust IT tests or starters' code, otherwise we risk masking some other error by failing tests.

As a part of the platform release process, make sure https://www.npmjs.com/package/@vaadin/vaadin-core and https://www.npmjs.com/package/@vaadin/vaadin get updated.

In our in-house project, binding of a Checkbox to a boolean bean property no longer seems to work.

I have an old copy of the bakery starter project based on 10.0.0.beta3.

I added a boolean field called archived to the User entity:

  public boolean isArchived() { 
    return archived; 
  } 
 
  public void setArchived(boolean archived) { 
    this.archived = archived; 
  } 
 
  private boolean archived; 

I added a checkbox to user-form.html:

  <vaadin-checkbox id="archived">Archived</vaadin-checkbox> 

Then in UserForm.java I added the checkbox and a binding:

  @Id("archived")
  private Checkbox archived; 

and in setBinder() I added a new binding for the new field:

binder.bind(archived, "archived");

This works as expected and I can edit a user and set and Unser the archived property.
See below:

Now, if I do the same with the latest starter, based on rc5, you'll notice that the archived checkbox is not being set when the dialog is re-opened:

I've attached the projects referenced above:
vaadin-bakery-app_beta3_working.zip

my-starter-project_rc5_not_working.zip

Thanks.

David.

Reading release 12.0.0.alpha2 notes seems like vaadin-context-menu-flow components being available, but importing the BOM and adding

<dependency>
    <groupId>com.vaadin</groupId>
    <artifactId>vaadin-context-menu-flow</artifactId>
</dependency>

results in a missing version.

From log

executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin

using nexus-staging-maven-plugin skipNexusStagingDeployMojo will skip deploy for all modules if set to skip for the last module
fortunately vaadin-platform-test is not the last module in the reactor

The readme should:

• Describe what Vaadin 10 is (elements part and Java part)
• Contain build statuses for all core and pro elements
• Link to Flow and other relevant projects

Hi,
There is an issue on v 10.0.4 that was not present on 10.0.2.

V10.0.2
Use bakery application. Write a custom not managed route (for example sue dashboard1 instead of dashboard). You have the CustomRouteNotFoundError message

Updating the Bakery app to 10.0.4 we have the error trace instead

The same code on Vaadin 10.0.2 works fine while using 10.0.4 give me the exception on the UI.

Something about exception handling broke off from 10.0.2 to 10.0.4

Platform PR's should be validated with all the starters. Let's begin with Bakery.

• Build platform snapshot on PR
• Use those to build&test Bakery
• Don't block the PR if the build fails, since Bakery might need to be fixed

• What's new and noteworthy
• Material theme

Using the metadata file created in #2, generate one bower.json file for each section, containing the defined dependencies. #version# in the file should be replaced by the current release version, given as a parameter to the script. The generated bower.json should also contain all versions for all dependencies, e.g. lock down the used Polymer dependency to a specific version (2.0.2). Must also make sure that all generated bower.json files use the same Polymer version, i.e. vaadin cannot use Polymer 2.0.1 when vaadin-core uses 2.0.2 or vice versa

For each section

• clone the corresponding GitHub repository
• create a new temporary branch named staging-#version#
• commit the generated bower.json
• push the changes

[WARNING] The POM for com.vaadin:vaadin:jar:10.0.0.alpha9 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details

Instead of trying to list all the starters we have in the readme (or release notes?), we should just link to vaadin.com/start so we have one less place to maintain that list.

It is already outdated so it probably should just be removed completely.