Migrate Spring add-on to its own repository

[pleku]

The Flow Spring-addon modules and its test modules should be migrated to its own repository named vaadin-spring-flow, and rename all the artifact names to match the previous format: vaadin-spring or vaadin-spring-x. No addon or flow in the name anymore.

The vaadin-spring-boot-starter module should be depending on vaadin-bom dependency management and vaadin-core dependency, instead of Flow.
NOTE that you should still validate the vaadin-spring-boot-starter for in the build for the Spring add-on, thus you need to have a Maven profile which doesn't use the platform declared versions of the add-on & flow but instead the snapshot ones. Or have this by default, and have another profile for releasing the vaadin-spring-boot-starter.

Do not forget to migrate all the spring addon related issues to the new repository.

There needs to be at least these three builds added for the project:

• a validation build run for each PR
• a release build that releases the add-on artifacts
  • exclude test modules and the flow-spring-starter module
• a release build for flow-spring-starter

Another build, which is not mandatory but more like nice to have is:

• a snapshot build that is triggered for each flow snapshot

The release checklists need to be updated so that after each Flow release, we verify that the spring add-on still works and release it if necessary.

After each platform release, we should update the platform version to the starter and release that one.
The first release versions for this should be:

• 4.0.0.beta1

[mstahv]

Could the name remain the same before (as in V8 era)? As discussed internally in Vaadin, when talking to Java people, we kind of expect that they are using our Java offering as well so there is no need to underline Flow here. So I suggest the name to be still com.vaadin:vaadin-spring-boot-starter.

//cc: @snicoll

[snicoll]

This gets my preference as well. Unless you've renamed your offering to flow (and Vaadin is no longer the product that V8 represents), I'd like the name of the starter to remain the same.

Also it feels weird to refer to Vaadin and get something called flow as a dependency.

[pleku]

We will rename the add-on and the starter to use the same name. Thus eg. the starter will be

• renamed to com.vaadin:vaadin-spring-boot-starter
• use version 4.0-SNAPSHOT
  • and use eg. 4.0.0.beta1 for the first release of the starter

We will have to lock the previous major versions in github.com/vaadin/spring to

• version 1 FW 7
• version 2 FW 8.0 8.1
• version 3 FW 8.2 ->

[Artur-]

Using different repositories for the same artifactId sounds like begging for problems. If we go for the same name as before, I would definitely use the same repositories also.

[pleku]

Using different repositories for the same artifactId sounds like begging for problems. If we go for the same name as before, I would definitely use the same repositories also.

Any concrete examples to give out, except just fears ?
For having both in the same repository, there is also some fears.
For us it would be an inconvenience since there would be issues reported to the same place for two totally different implementations. It might be easier to the users, unless they want to keep tabs on what is happening.

Anyway, we still have some time to think this through, not rushing into anything, yet.

[snicoll]

Any concrete examples to give out, except just fears ?

It just is the same concept, isn't it? A new generation, with potentially a lot of changes but a user upgrading would find weird to have to jump to a totally different repo. If you are ok with keeping the same name (and I think you should) then I see no reason to use a completely different repository.

And the implementation part is an internal detail IMO (the inconvenience would be if two totally separate teams work on the two generations).

[pleku]

It just is the same concept, isn't it? A new generation, with potentially a lot of changes but a user upgrading would find weird to have to jump to a totally different repo. If you are ok with keeping the same name (and I think you should) then I see no reason to use a completely different repository.
And the implementation part is an internal detail IMO (the inconvenience would be if two totally separate teams work on the two generations).

The concept is the same, Vaadin is still Vaadin, but the Java product within that is different.

Eg. the migration from Vaadin 8 to 10 is not a "bump version and fix compilation errors", but a lot bigger task and requires more changes. Bigger than with previous major versions. And this is intentional, and thus the Java framework has been named also differently and follows a different versioning. But the users don't mostly see that, what they see is Vaadin and the version bump over major version 9.

At the moment we have two separate teams working on the V8 and V10 products.

For Vaadin Spring add-on users, I don't know which is the least inconvenient
a) using the same artifact id with a new major version and same repository, but not being able to bump version to latest without almost rewrite of app
b) using the same artifact id with new major version and jumping to another repository, but not being able to bump version to latest without almost rewrite of app
c) using another artifact id and jumping to another repository for V10

I think for most users the versions are coming from BOM and I hope they are not trying to handle those themselves. As long as they stick to BOM, they don't have any issues with bumping version to something that doesn't work.

[snicoll]

Thanks for the feedback.

Eg. the migration from Vaadin 8 to 10 is not a "bump version and fix compilation errors", but a lot bigger task and requires more changes.

I am aware of that. But if there is no such thing as vaadin-spring-boot-starter in 10 and what a Java developer would use with Vaadin is this project, then, IMO, it should be on the same repository and named similarly.

On the other hand, if you want to make a clear breakage with the infrastructure in 8, then having a different name is more than fair enough. But then that becomes Flow as a public name and not Vaadin then IMO.

I think for most users the versions are coming from BOM and I hope they are not trying to handle those themselves. As long as they stick to BOM, they don't have any issues with bumping version to something that doesn't work.

Sorry but the version argument has nothing to do with the name of the artifact. Or if it is, I don't understand why.

[pleku]

I'm leaning towards using the same name, and the same repository. Because:

• Mostly the users will know about Vaadin, not about Flow. I think they will be looking for / interested more in a Vaadin integration, not Flow integration (though latter is what they will get). There is only one Vaadin, but (sadly) there are lots of other things named Flow too..
• I don't foresee that we will, at least any time soon, make another Spring integration that would be eg. for only the frontend part, and thus then we would have multiple Spring integrations for one Vaadin version. I think the Spring integration for Vaadin will always be for the Java framework.

Having V7, V8 and V10 integrations in the same repository will cause some overhead for updating readmes for all branches (to state out what Vaadin version is this branch for) and build configurations.

Sorry but the version argument has nothing to do with the name of the artifact. Or if it is, I don't understand why.

I meant that as a user, I might try to update my Vaadin Spring add-on version, and by doing that get something that is not compatible with the Vaadin Java Framework version I'm using. But I think that should be handled by BOM, you just take the BOM and it manages the correct versions for you. If you do something else, then you need to know what versions are compatible together.

Thus the Vaadin Spring add-on for Vaadin 10, could just take the next available major version, which is 4.

[Legioth]

Thus the Vaadin Spring add-on for Vaadin 10, could just take the next available major version, which is 4.

Would it make sense to leave a "hole" in the version numbering to allow creating a couple of major versions specifically for Vaadin 8 in the future? Alternatively, the V8 add-on would have to be renamed to have a different artifact id if we ever have to create a new major version.

[snicoll]

+1 for leaving a hole.

Thanks for the feedback @pleku !

[pleku]

So the specs are:

• use https://github.com/vaadin/spring
• use same artifact names as before for V7 and V8 versions
  • Java package names should still be different, use what is now used for the Flow add-on
• version is 10.0
  • will be a big hole between the current V8 version 3.0 and V10 version
  • will not follow the Vaadin versioning

The practical steps:

• move the current master branch of the repository 3.0
  • make the branch protected etc.
  • update the validation build configuration travis (in the branch)
  • update the release build configuration (in bender)
  • create a delete commit afterwards
• move the addon code and tests from vaadin/flow to the master branch and set the version to 10.0
  • make a validation build
  • make snapshot against a new flow snapshot (like with components)
  • make a release build for bender
  • make a release with version 10.0.0.beta1, update release checklist for Flow
  • update the platform-bom for the released version
  • update all the starters to use the new artifact names
    • skeleton-starter-flow-spring
    • bakery-starter-flow-spring
    • flow-spring-tutorial
• Add the following details to READMEs on each of the following branches: 1.2, 2.1, 3.0, 10.0
  • What framework version this maps to
  • What other branches there might be for other framework versions
  • Refer to Vaadin 10, not Flow 1.0, expect in the branch for 10.0 (master)

[pleku]

vaadin-spring-10.0.0.beta1 has been released for V10 compatibility. Will be included in the V10 platform BOM next week.