Skip to content
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

Integrate dev mode with the Boost plugin #530

Merged
merged 1 commit into from
Sep 10, 2019

Conversation

awisniew90
Copy link
Contributor

A boost user will be able to directly call Liberty dev mode via:

mvn io.openliberty.tools:liberty-maven-plugin:3.1.M1-SNAPSHOT:dev (for example)

If the Boost plugin is defined in the pom, Liberty dev mode will call boost:package when changes to the pom are made.

@awisniew90 awisniew90 force-pushed the boost_dev_proto branch 2 times, most recently from 499c759 to e214c56 Compare September 4, 2019 02:07
File pomFile = new File(project.getFile().getAbsolutePath());
ProjectBuildingResult build = mavenProjectBuilder.build(pomFile,
session.getProjectBuildingRequest().setResolveDependencies(true));
boostProject = build.getProject();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So how/why this is different from the non-Boost path using DevMojo.loadProject(File) to reload the POM? Is it mainly because we're trying to fluff up objects needed by the mojo executor? Some other reason?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right - we are passing an actual maven project object to Boost via the mojo executor, so we need that project to have all of its dependency information resolved (i.e. versions when boms are being used). DevMojo.loadProject(File) does not do that, which is ok for that path because it uses an artifact resolver later on to resolve each individual dependency. For our case, we need to use the MavenProjectBuilder which builds a new maven project object with dependency versions correctly resolved.

Copy link
Member

@mattbsox mattbsox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@chyt
Copy link
Contributor

chyt commented Sep 6, 2019

One thing that stands out to me is that we are using the presence of the Boost plugin in the MavenProject in order to decide whether or not we should run the boost mojos. Does this still work if we are invoking Boost dev mode directly from the command line without defining it in the pom?

@scottkurz
Copy link
Member

One thing that stands out to me is that we are using the presence of the Boost plugin in the MavenProject in order to decide whether or not we should run the boost mojos. Does this still work if we are invoking Boost dev mode directly from the command line without defining it in the pom?

Not sure what you mean by "invoking Boost dev mode directly"... we don't have a 'dev' goal in Boost, only in LMP.

@awisniew90
Copy link
Contributor Author

Appveyor is failing with several compilation errors which seem unrelated to this change. Are these known issues?

@scottkurz
Copy link
Member

Appveyor is failing with several compilation errors which seem unrelated to this change. Are these known issues?

Haven't looked at past builds but I see:

[00:11:25] [INFO] [ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.0-M3-SNAPSHOT:clean (clean-server) on project basic-runtime-version-property-override-it: CWWKM2031E: Cannot delete file C:\projects\ci-maven\liberty-maven-plugin\target\it\basic-runtime-version-property-override-it\target\liberty\wlp\usr\servers\defaultServer\logs\console.log. -> [Help 1]
[00:11:25] [INFO] [ERROR]

which, with the fact that it's running on Windows, seems suspiciously like an environmental issue.

@cherylking
Copy link
Member

I have not seen compilation errors in AppVeyor, but I do see this in many recent builds (also seems like an environment issue):

Screen Shot 2019-09-10 at 7 54 57 AM

@awisniew90
Copy link
Contributor Author

I rebased and the compilation failures are resolved now, but there is one failing test only on OL 19.0.0.3. I don't see this failure locally. Might just be a fluke, but am looking into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants