-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix multi-module jar skip for spring-boot projects #1810
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just the one question.
liberty-maven-plugin/src/main/java/io/openliberty/tools/maven/ServerFeatureSupport.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth adding an IT here. We have the whole structure in src/it/dev-it/src/test/java/net/wasdev/wlp/test/dev/it... and the validation can be pretty simple to simply check that it wasn't skipped.
So basically run "liberty:dev" against a spring boot app. I only see two existing spring boot apps in the test source here, and none in the dev it structure. So we'd need to create a Spring Boot app in dev-it and validate that we are not skipping the execution. |
33453ac
to
5c45421
Compare
public class SpringBootDevTest extends BaseDevTest { | ||
|
||
@BeforeClass | ||
public static void setUpBeforeClass() throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to do more like mvn package liberty:dev
.
That said.. I think it might be a bad idea to include this test.. since someone later might assume it implies that we have support for dev mode in Spring Boot which we don't.
This would fit better as a test of 'run'. You still have to do a package with 'run' (so mvn package liberty:run
) but you don't have to use loose apps, and so it makes more sense than dev (since neither loose apps in general nor dev work with SB and LMP currently).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^^ What Scott said :-)
@@ -1342,7 +1342,11 @@ private void doDevMode() throws MojoExecutionException { | |||
|
|||
// In a multi-module build, dev mode will only be run on one project (the farthest downstream) and compile will | |||
// be run on any relative upstream projects. If this current project in the Maven Reactor is not one of those projects, skip it. | |||
List<MavenProject> relevantProjects = getRelevantMultiModuleProjects(graph); | |||
boolean skipJars = true; | |||
if("spring-boot-project".equals(getDeployPackages())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point, is this just an error, independently of whether we think we should skip? Or are we trying to make this correct imagining a future effort to add support for Spring Boot in dev mode?
@@ -119,7 +119,11 @@ private void generateFeatures() throws MojoExecutionException, PluginExecutionEx | |||
|
|||
// In a multi-module build, generate-features will only be run on one project (the farthest downstream). | |||
// If this current project in the Maven Reactor is not that project or any of its upstream projects, skip it. | |||
List<MavenProject> relevantProjects = getRelevantMultiModuleProjects(graph); | |||
boolean skipJars = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "generate-features" do something meaningful today at LMP v3.10, in the Spring Boot JAR case? Are we adding any value at all by complicating the path here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt we have tested this scenario. So what would perform the most like it did before the changes went in to skip jar modules? Do we want to not skip jar modules at all for now for generate-features
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that might cause problems since generate-features
is called from dev mode... so in the non-springboot case, we could flag a conflict in generate-features
(a jar and a war module without any downstream projects), that we didnt flag in the dev mode execution. So the two need to behave the same in that regard.
Since dev mode is not supported in the Springboot case, should we just add this SB check to the RunServerMojo and not for DevMojo and GenerateFeaturesMojo?
Sorry, not sure which comment to respond to so starting a new one:
let's just return the single module and keep going. This would solve the original case, the SB guide..which is single module.
|
5c45421
to
54269bc
Compare
Signed-off-by: Adam Wisniewski <awisniew@Adams-MacBook-Pro.local>
54269bc
to
746110c
Compare
No description provided.