spring-cloud / spring-cloud-dataflow-build Goto Github PK

We didn't take spring-cloud-build-tools concept for our dataflow build and that's required for checkstyle(it would come from classpath) if we want to have a common one and not hardcode config location(needed to run builds from module directories).

As main pom were copied from spring-cloud-build we still have some things left there which have no meaning in a dataflow build. Should polish this pom.

• Spring Boot has been updated to 2.5.2

Looking packages:

io.pivotal.cfenv
io.pivotal.spring.cloud

Boot 2.4.0 should go with cloud train 2020.0.0-M6(when it's out). Boot 2.4.1 and Cloud 2020.0.0 GA is tentatively out before holidays.

Boot 2.4.1 and when cloud atop of it goes GA.

• Spring Boot has been updated to 2.4.7
• Spring Cloud has been updated to 2020.0.3
• Java CFEnv has been updated to 2.3.0
• spring-cloud-services-config-client-autoconfigure has been updated to 3.2.1

We should bump a version and handle common way to active integration tests.

This is a similar work for parent splitting not needing to rely on spring-cloud-dependencies-parent.

Boot 2.4.x finally removed junit4 deps so we want to bring it back directly into top-level build so that we don't need to modify every umbrella project.

Essentially we'd like to process test resources similarly to normal resources:

	<build>
		<testResources>
			<testResource>
				<directory>${basedir}/src/test/resources</directory>
				<filtering>true</filtering>
				<includes>
					<include>**/application*.yml</include>
					<include>**/application*.properties</include>
				</includes>
			</testResource>
			<testResource>
				<directory>${basedir}/src/test/resources</directory>
				<excludes>
					<exclude>**/application*.yml</exclude>
					<exclude>**/application*.properties</exclude>
				</excludes>
			</testResource>
		</testResources>
	</build>

So that in a projects you would not need to modify poms if these files do things like property resolving, etc.

Backport #28

What we want accomplish is that when staging build is done, some fu in build files should help to make sure that we have restricted resolution not leak snapshots into milestones, milestones into releases and staging build should also resolve from staging repo as we want to build whole "train" before promoting.

The 2.3.0 RC1 is available, 2.3.0 GA is planned for May 14th. Let's get the 2.3.0 RC1 pulled in sooner than later for SCDF 2.6.x.

Mileage may vary between surefire and failsafe but it'd be nice to have common config what juni5 tags are excluded automatically. Not sure if failsafe honors any tags but surefire does. Think plan is totally move away from failsafe in favour of tags.

spring-cloud-dataflow-build-tools is defined as a version in a plugin management and we need to check that next release changes that to 2.5.0.M1. If our release build doesn't do it we need to figure out something else.