Modifying the User object in the JHipster mini-book

1,849 views
Skip to first unread message

Matt Raible

unread,
Oct 7, 2016, 11:30:31 PM10/7/16
to JHipster dev team
Hey all,

As you might know, I finished the rough draft of updates for the JHipster mini-book this week. One of the tech reviewers had this feedback:


In Chapter 2 in the “Points this week” section you are modifying the User.java object that ships with JHipster. While I understand why you did this for this particular case, I usually recommend people avoid modifying the User.java object (and the JHI_USER table) because it potentially makes future JHipster upgrades more difficult. In most cases I try to steer people into making a new table with a many-to-one relationship back to the JHipster User. (I know in this case it is a one-to-one) Perhaps it would be worth a note mentioning something along these lines.


I’ve included the relevant section of Chapter 2 in a <quote> at the bottom of this email.

I did this mostly because I'm creating a new application (using v3.8.0) to upgrade an old application (v2.19.0). I tried doing an upgrade, but it turned out to be too complicated.

I created 21-Points Health last year as part of the 1.0 version of the book. Ideally, I'd like to create a branch in the current project on GitHub and copy all the new stuff into it. I'm guessing I'll have to 1) create a branch, 2) delete all the old files and 3) copy the new files in. However, I don't want to lose the old commit history, or the new commit history, so I'm not sure how to handle the .git directory in the branch. Do I just copy over it and everything should work? It'd be nice to create a PR that shows everything that changed between the last version and this version.

Then there's the deployment to Heroku and the fact that I'm hoping to retain all my data. With the current codebase, I believe the schemas match. If there's any issues, I think it will be because of the timestamps on the liquibase changelog files. I'm hoping to export my Heroku Postgres database to a local instance to verify it all works smoothly.

I could take this suggestion and change things so Preferences fetches by user id, then the User object wouldn't need modification. However, I'd likely have to create a migration that changes the old schema to one that doesn't have a preferences_id in the user table. This is probably the right thing to do, but I likely wouldn't mention it in the book. It might make a good blog post though!

What are your thoughts on the best way to handle this in the book? Should I correct my mistakes of the past, or just add a note to the book explaining why I did it this way? The book currently reads as if I’m developing the app for the first time with JHipster 3.x.

As far as creating a PR for the new app -> old app on GitHub, has anyone done something similar? I imagine deploying the new app to Heroku will be a bit easier since I can (hopefully) test things by exporting my prod database to a local instance first.

Thanks in advance for any advice!

Matt

<quote>
You might notice the goal is hardcoded to 10 in the progress bar's HTML. To fix this, I needed to add the ability
to fetch the user's preferences. To make it easier to access a user's preferences, I modified `User.java` and added
a references to `Preferences`.

[source,java]
.src/main/java/org/jhipster/health/domain/User.java
----
@OneToOne(cascade = CascadeType.ALL)
@JsonIgnore
private Preferences preferences;

public Preferences getPreferences() {
return preferences;
}

public void setPreferences(Preferences preferences) {
this.preferences = preferences;
}
----

Then I added a column to the `JHI_USER` table and a relationship to the `PREFERENCES` tables.

[source,xml]
.src/main/resources/config/liquibase/changelog/20160831021015_added_entity_Preferences.xml
----
<changeSet author="mraible (generated)" id="1440176725177-1">
<addColumn tableName="JHI_USER">
<column name="preferences_id" type="int8"/>
</addColumn>
</changeSet>
<changeSet author="mraible (generated)" id="1440176725177-2">
<addForeignKeyConstraint baseColumnNames="preferences_id" baseTableName="JHI_USER"
constraintName="FK_1r5e40mq4hwtlyd9lemghc8su" deferrable="false"
initiallyDeferred="false" referencedColumnNames="id"
referencedTableName="PREFERENCES"/>
</changeSet>
----

To ensure mapping a `User` object to a `UserDTO`, I added the a reference to this property in `UserMapper.java`:

[source,diff]
.src/main/java/org/jhipster/health/service/mapper/UserMapper.java
----
@Mapping(target = "password", ignore = true)
+ @Mapping(target = "preferences", ignore = true)
User userDTOToUser(UserDTO userDTO);
----

I created a new method in `PreferencesResource.java` to return the user's preferences
(or a default weekly goal of 10 points if no preferences are defined).

[source,java]
.src/main/java/org/jhipster/health/web/rest/PreferencesResource.java
----
/**
* GET /my-preferences -> get the current user's preferences.
*/
@RequestMapping(value = "/my-preferences")
@Timed
public ResponseEntity<Preferences> getUserPreferences() {
String username = SecurityUtils.getCurrentUserLogin();
log.debug("REST request to get Preferences : {}", username);
User user = userRepository.findOneByLogin(username).get();

if (user.getPreferences() != null) {
return new ResponseEntity<>(user.getPreferences(), HttpStatus.OK);
} else {
Preferences defaultPreferences = new Preferences();
defaultPreferences.setWeeklyGoal(10); // default
return new ResponseEntity<>(defaultPreferences, HttpStatus.OK);
}
}
——
</quote>

Julien Dubois

unread,
Oct 10, 2016, 12:10:49 PM10/10/16
to Matt Raible, JHipster dev team
Yes, I see many people doing this.

Let me summarize my ideas:

- The original idea is that we just do a scaffolding tool, so you should modify the User entity
- People want to follow the JHipster ugrades, and that causes quite a lot of trouble -> in that case doing an one-to-one relationship to a "BusinessUser" entity (or something similar), is a good idea, and that seems pretty popular

Pros:
- you can do upgrades
- you separate the "security" user from a "business" user, and that's also a good separation of concerns

Cons:
- you have 2 entities that are always used together
- that means more relationships, and maybe performance/lazy loading issues

I haven't used this at all, but I also have that idea of doing inheritance instead of a relationship. It would probably have the same performance issues (need to check), but the concept looks better to me.

We need to spend more time thinking about this, and yes we should have some official recommendation, as it's a common use case.

Julien



--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/90A48E1E-678E-4191-81C0-02B7BD30D999%40raibledesigns.com.
For more options, visit https://groups.google.com/d/optout.



--
Julien Dubois

Matt Raible

unread,
Oct 10, 2016, 12:42:12 PM10/10/16
to Julien Dubois, JHipster dev team
I figured it was best to “do the right thing” so I refactored the example in the book to remove the new methods and column on the User object.


As far as moving the repository from Bitbucket to a branch on GitHub (in the existing 21-points project), I tried that last night and it failed. I used the brute force method: create branch on GitHub, delete all files, copy all files from Bitbucket project. It resulted in a bunch of missing files and directories. I believe it should be possible, maybe I just need to use git commands and push the Bitbucket repo to a new remote server/branch? If all else fails, I’ll just remove the repo from GitHub and recreate it. There won’t be a PR to show what’s changed b/w the JHipster 2.x and 3.x version, but oh well.

I also tried exporting my Heroku database to a local instance and then starting 21-Points with its prod profile (pointing to the local PostgreSQL instance). It fails because Liquibase.

2016-10-10 10:38:11.813  WARN 40615 --- [           main] ationConfigEmbeddedWebApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/jhipster/health/config/DatabaseConfiguration.class]: Invocation of init method failed; nested exception is liquibase.exception.ValidationFailedException: Validation Failed:
     1 change sets check sum
          classpath:config/liquibase/changelog/00000000000000_initial_schema.xml::00000000000001::jhipster is now: 7:d72dc3c6981867677dcbea2910c6d9c7

2016-10-10 10:38:11.821  WARN 40615 --- [           main] o.s.boot.SpringApplication               : Error handling failed (Error creating bean with name 'delegatingApplicationListener' defined in class path resource [org/springframework/security/config/annotation/web/configuration/WebSecurityConfiguration.class]: BeanPostProcessor before instantiation of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.cache.annotation.ProxyCachingConfiguration': Initialization of bean failed; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'org.springframework.context.annotation.ConfigurationClassPostProcessor.importRegistry' is defined)
2016-10-10 10:38:11.842 ERROR 40615 --- [           main] o.s.boot.SpringApplication               : Application startup failed

I tried changing this file to have:

<changeSet id="7:d72dc3c6981867677dcbea2910c6d9c7" author="jhipster">

Then it fails with:

2016-10-10 10:40:07.395 ERROR 40878 --- [           main] liquibase                                : classpath:config/liquibase/master.xml: classpath:config/liquibase/changelog/00000000000000_initial_schema.xml::7:d72dc3c6981867677dcbea2910c6d9c7::jhipster: Change Set classpath:config/liquibase/changelog/00000000000000_initial_schema.xml::7:d72dc3c6981867677dcbea2910c6d9c7::jhipster failed.  Error: ERROR: relation "jhi_user" already exists [Failed SQL: CREATE TABLE public.jhi_user (id BIGSERIAL NOT NULL, login VARCHAR(50) NOT NULL, password_hash VARCHAR(60), first_name VARCHAR(50), last_name VARCHAR(50), email VARCHAR(100), activated BOOLEAN NOT NULL, lang_key VARCHAR(5), activation_key VARCHAR(20), reset_key VARCHAR(20), created_by VARCHAR(50) NOT NULL, created_date TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL, reset_date TIMESTAMP WITHOUT TIME ZONE, last_modified_by VARCHAR(50), last_modified_date TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW(), CONSTRAINT PK_JHI_USER PRIMARY KEY (id), UNIQUE (login), UNIQUE (email))]

Can I look in my prod database and copy the changeset numbers to local files to prevent these errors? If not, what’s the best way to migrate my old data into my new schema?

Thanks,

Matt

Mathieu Abou-Aichi

unread,
Oct 10, 2016, 12:42:58 PM10/10/16
to Julien Dubois, Matt Raible, JHipster dev team
I like the OtO idea. The locked user (the real one, which is the one currently generated) wouldn't have to know about its modifiable counterpart (the one people always to tweak). Inheritance could be acceptable too... But both solutions have pros and cons. It could be something the user answers, if it's not too much trouble implementing of course (questions, questions, questions...). Or, the user deals with it herself/himself with a how-to in the docs about how to do it... This could prevent a lof issues.
--
Mathieu ABOU-AICHI

Mathieu Abou-Aichi

unread,
Oct 10, 2016, 12:46:23 PM10/10/16
to Matt Raible, Julien Dubois, JHipster dev team
Matt, did you have something like a corrupted index?
--
Mathieu ABOU-AICHI

Deepu K Sasidharan

unread,
Oct 10, 2016, 1:37:10 PM10/10/16
to Mathieu Abou-Aichi, Matt Raible, Julien Dubois, JHipster dev team
Matt,

Did you try this
  1. Checkout bitbucket repo in a local clone
  2. Change its remote origin to point to the github repo you want to push to
  3. checkout a new branch from master
  4. make a dummy commit and force push to origin (so you should have this new branch in your github repo with code from bitbucket repo)
  5. create a PR from the new branch 2 master (So the PR will show wat changed assuming your current github master is 3.x code and bitbucket code in the branch is 2.x or vice versa)
  6. You might have trouble merging this, so just checkout the master of bitbucket clone again and force push


Thanks & Regards,
Deepu

Matt Raible

unread,
Nov 15, 2016, 10:20:05 PM11/15/16
to Deepu K Sasidharan, Mathieu Abou-Aichi, Julien Dubois, JHipster dev team
Hi Deepu,

Since the book was going through editing and none of the code change, I didn’t get a chance to try this until now. I made it through steps 4, but when I try to do #5, I get an error saying there isn’t anything to compare. Screenshot attached.

Matt Raible

unread,
Nov 16, 2016, 9:15:28 AM11/16/16
to Deepu K Sasidharan, Mathieu Abou-Aichi, Julien Dubois, JHipster dev team
On a related note, this branch is failing in Travis CI and I can’t figure out why. “./gradlew test” fails with the following error:

:test FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':test'.
> Process 'Gradle Test Executor 2' finished with non-zero exit value 137
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 2 mins 55.691 secs
I tried upgrading to Gradle Wrapper 3.2, but that didn’t help.

It works fine when I run it locally.

Frederik Hahne

unread,
Nov 16, 2016, 9:24:37 AM11/16/16
to jhipst...@googlegroups.com
Does it only fail on travis or locally too?

Am 16.11.2016 um 15:15 schrieb Matt Raible:
> On a related note, this branch is failing in Travis CI and I can’t
> figure out why. “./gradlew test” fails with the following error:
>
> :testFAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':test'.
>> Process 'Gradle Test Executor 2' finished with non-zero exit value 137
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
> BUILD FAILED
> Total time: 2 mins 55.691 secs
>
> I tried upgrading to Gradle Wrapper 3.2, but that didn’t help.
>
> It works fine when I run it locally.
>
> https://travis-ci.org/mraible/21-points#L741
>
>> On Nov 15, 2016, at 8:20 PM, Matt Raible <ma...@raibledesigns.com
>> <mailto:ma...@raibledesigns.com>> wrote:
>>
>> Hi Deepu,
>>
>> Since the book was going through editing and none of the code change,
>> I didn’t get a chance to try this until now. I made it through steps
>> 4, but when I try to do #5, I get an error saying there isn’t anything
>> to compare. Screenshot attached.
>>
>>
>>
>>> On Oct 10, 2016, at 11:37 AM, Deepu K Sasidharan
>>> <deepu.k.s...@gmail.com <mailto:deepu.k.s...@gmail.com>>
>>> wrote:
>>>
>>> Matt,
>>>
>>> Did you try this
>>>
>>> 1. Checkout bitbucket repo in a local clone
>>> 2. Change its remote origin to point to the github repo you want to
>>> push to
>>> 3. checkout a new branch from master
>>> 4. make a dummy commit and force push to origin (so you should have
>>> this new branch in your github repo with code from bitbucket repo)
>>> 5. create a PR from the new branch 2 master (So the PR will show wat
>>> changed assuming your current github master is 3.x code and
>>> bitbucket code in the branch is 2.x or vice versa)
>>> 6. You might have trouble merging this, so just checkout the master
>>> of bitbucket clone again and force push
>>>
>>>
>>>
>>> Thanks & Regards,
>>> Deepu
>>>
>>> On Mon, Oct 10, 2016 at 10:16 PM, Mathieu Abou-Aichi
>>> <mathi...@free.fr <mailto:mathi...@free.fr>> wrote:
>>>
>>> Matt, did you have something like a corrupted index?
>>>
>>> Le 10 octobre 2016 18:42:03 GMT+02:00, Matt Raible
>>> <ma...@raibledesigns.com <mailto:ma...@raibledesigns.com>> a écrit :
>>>> <julien...@gmail.com <mailto:julien...@gmail.com>>
>>>> jhipster-dev...@googlegroups.com
>>>> <mailto:jhipster-dev%2Bunsu...@googlegroups.com>.
>>>> To post to this group, send email to
>>>> jhipst...@googlegroups.com
>>>> <mailto:jhipst...@googlegroups.com>.
>>>> <https://groups.google.com/d/msgid/jhipster-dev/90A48E1E-678E-4191-81C0-02B7BD30D999%40raibledesigns.com>.
>>>> For more options, visit
>>>> https://groups.google.com/d/optout
>>>> <https://groups.google.com/d/optout>.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Julien Dubois
>>>>
>>>> Twitter: @juliendubois <http://twitter.com/#!/juliendubois>
>>>> Phone: +33 (0)6 25 02 34 18
>>>>
>>>
>>>
>>>
>>> --
>>> Mathieu ABOU-AICHI
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "JHipster dev team" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to jhipster-dev...@googlegroups.com
>>> <mailto:jhipster-dev...@googlegroups.com>.
>>> To post to this group, send email to
>>> jhipst...@googlegroups.com <mailto:jhipst...@googlegroups.com>.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jhipster-dev/2028082D-2063-412F-AB3D-3974C8213C69%40free.fr
>>> <https://groups.google.com/d/msgid/jhipster-dev/2028082D-2063-412F-AB3D-3974C8213C69%40free.fr?utm_medium=email&utm_source=footer>.
>>>
>>> For more options, visit https://groups.google.com/d/optout
>>> <https://groups.google.com/d/optout>.
>>>
>>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "JHipster dev team" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jhipster-dev...@googlegroups.com
> <mailto:jhipster-dev...@googlegroups.com>.
> To post to this group, send email to jhipst...@googlegroups.com
> <mailto:jhipst...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jhipster-dev/12E2CDA8-8067-408F-A423-6490B4B6BA32%40raibledesigns.com
> <https://groups.google.com/d/msgid/jhipster-dev/12E2CDA8-8067-408F-A423-6490B4B6BA32%40raibledesigns.com?utm_medium=email&utm_source=footer>.
0x3297A5C5.asc
signature.asc

Matt Raible

unread,
Nov 16, 2016, 1:15:19 PM11/16/16
to Frederik Hahne, jhipst...@googlegroups.com
It only fails on Travis.

To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/9971006d-f702-7755-805e-c3bfc834711a%40gmail.com.

For more options, visit https://groups.google.com/d/optout.
<0x3297A5C5.asc>

Matt Raible

unread,
Nov 16, 2016, 5:51:28 PM11/16/16
to Frederik Hahne, jhipst...@googlegroups.com
Here’s the stracktrace I see in Travis after changing “./gradlew test” to “./gradlew test --stacktrace”

Can’t really tell what’s happening. 


:testClasses
:test FAILED

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':test'.
> Process 'Gradle Test Executor 2' finished with non-zero exit value 137
* Try:
Run with --info or --debug option to get more log output.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':test'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:84)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:61)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:45)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:233)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:74)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:55)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:113)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:197)
at org.gradle.internal.Factories$1.create(Factories.java:25)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:194)
at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:36)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:118)
at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:112)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:98)
at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:66)
at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:44)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:29)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:244)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:217)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:33)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:210)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:174)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:31)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:108)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Caused by: org.gradle.process.internal.ExecException: Process 'Gradle Test Executor 2' finished with non-zero exit value 137
at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:369)
at org.gradle.process.internal.worker.DefaultWorkerProcess.waitForStop(DefaultWorkerProcess.java:165)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.stop(ForkingTestClassProcessor.java:120)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.endBatch(RestartEveryNTestClassProcessor.java:63)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.stop(RestartEveryNTestClassProcessor.java:57)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
BUILD FAILED
Total time: 2 mins 38.171 secs
The command "./gradlew test --stacktrace" exited with 1.

Matt Raible

unread,
Nov 16, 2016, 11:08:09 PM11/16/16
to Frederik Hahne, jhipst...@googlegroups.com
I was able to fix this by adding “./gradlew clean” before “./gradlew test”.


Funny thing is I found it because I was reviewing the JHipster Mini-Book and noticed this difference between the previous script and my new one.

Since I can’t create a PR to merge my jhipster-3 branch into master, what do y’all think the best way to get jhipster-3 onto master? I’m thinking something like:

1. Tag master as the 1.0 release
2. Delete master
3. Rename jhipster-3 to master and push
4. Tag master as 2.0 release

Thanks,

Matt
Reply all
Reply to author
Forward
0 new messages