-
Notifications
You must be signed in to change notification settings - Fork 42
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
[WFLY-17651] Add a new "Getting Started" archetype. #26
Conversation
We would need a Helm Chart to deploy the application on Kubernetes (instead of a plain container image deployment). The Helm chart could be as simple as:
The underlying question is how far do you want to push the getting started experience? If its's up to local development, the image is fine. |
@jmesnil I think after this the next discussion is documentation of user stories, as the Helm chart is so simple I don't think it fits in the archetype, instead it feels like it is a next user story re using a Helm Chart to deploy the project. |
...resources/archetype-resources/src/test/java/org/wildfly/security/examples/test/SampleIT.java
Outdated
Show resolved
Hide resolved
wildfly-getting-started-archetype/src/test/resources/projects/basic/goal.txt
Outdated
Show resolved
Hide resolved
* Rely on the provisioned server + deployments to run the integration tests * Use a single managed Arquillian container to run the tests * Do not use profiles for testing, with this settings, there is no reason that integration tests should be skipped. Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Update testing strategy
Thanks @jmesnil I have merged that first PR |
@darranl thanks! If you look at the GitHub action, you will now have the execution of the |
to use the same package and prefix that the application classes. Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
...resources/archetype-resources/src/test/java/org/wildfly/security/examples/test/SampleIT.java
Outdated
Show resolved
Hide resolved
Update packaging of the projects tests
@jmesnil second PR merged ;-) thank you |
Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
* Use `org.wildfly.examples` for the `groupId` and `package` property * Use `getting-started` for the `artifactId` property * Use `1.0.0-SNAPSHOT` for the `version` property By default, the project will use these value to genereate the project and the command is simply: ``` mvn archetype:generate -DarchetypeGroupId=org.wildfly.archetype -DarchetypeArtifactId=wildfly-getting-started-archetype ``` It is still possible to update these values with a system property (eg `-DgroupId=org.acme`) or interactively by rejecting the properties configuration and specify new values. Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Use the artifactId instead of the hard-coded `login-form` Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Use name instead of runtimeName to deploy the application. RuntimeName is deprecated and would not work well with wildfly:dev goal Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
This lets the user know where that page is coming from. If their app is not a frontend, they will likely want to get rid of this page (and associated css resources). Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
this is so fast that it looks weird Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Add a CDI injection Add an unit test to test the CDI service This sets up the user to do both unit testing (before creating the war) and integration testing (against the deployed app) Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
@darranl you need to bump the wildfly-maven-plugin to |
@jmesnil sorry I had made that change locally, hadn't pushed the last commit. |
Update generated project README
Default properties
Update arquillian.xml
<!-- other plugin versions --> | ||
<version.compiler.plugin>3.9.0</version.compiler.plugin> | ||
<version.surefire.plugin>2.22.2</version.surefire.plugin> | ||
<version.failsafe.plugin>2.22.2</version.failsafe.plugin> |
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.
can be bumped to 3.1.2
<version.compiler.plugin>3.9.0</version.compiler.plugin> | ||
<version.surefire.plugin>2.22.2</version.surefire.plugin> | ||
<version.failsafe.plugin>2.22.2</version.failsafe.plugin> | ||
<version.war.plugin>3.3.2</version.war.plugin> |
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.
can be bumped to 3.4.0
</plugin> | ||
|
||
<!--Build configuration for the WAR plugin: --> | ||
<plugin> |
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.
@darranl the indentation is all over the place (I definitely mess it up in all my commits). Before merging, this pom.xml should be reindented.
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.
done in jmesnil@d792dd3
|
||
<!-- other plugin versions --> | ||
<version.compiler.plugin>3.9.0</version.compiler.plugin> | ||
<version.surefire.plugin>2.22.2</version.surefire.plugin> |
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.
afaict, this version is useless as the surefire plugin is not explicitly configured in this pom.xml.
*/ | ||
public class ${defaultClassPrefix}ServiceTest { | ||
|
||
${defaultClassPrefix}Service service = new ${defaultClassPrefix}Service(); |
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.
This is actually a stupid idea of mine to write such unit test for a CDI bean. This will break if the bean use any injection itself.
We should remove this test file completely
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.
or set it up as an Arquillian integration tests with a deployment, etc.
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.
done in darranl#7
The changes in arquillian.xml was making the test fails but this was not captured by the verify goal Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Signed-off-by: Jeff Mesnil <jmesnil@redhat.com>
Fix testing
@darranl starting with #40, all dependencies are configured in the parent pom.xml and propagated to the generated archetypes. This requires an update in your PR to move the generated pom.xml in a separate directory and some escaping of its variables. This should be very similar to what was done for the jakartaee-webapp archetype (starting from https://github.com/wildfly/wildfly-archetypes/pull/40/files#diff-03e5203acbea22fcd42193af53307eb5b7ac9ffd50ede79de2bf4ad7b4e4cd64) |
done in jmesnil@d792dd3 |
<dependency> | ||
<groupId>org.jboss.resteasy</groupId> | ||
<artifactId>resteasy-client</artifactId> | ||
<version>6.2.4.Final</version> |
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.
For consistency, I would move this version to the properties section
FYI I am going to close this PR as I opened #47 as a continuation after merging in main and syncing from Jeff's topic branch. |
https://issues.redhat.com/browse/WFLY-17651
Starting off as a draft as a couple of additional points still to consider: