What is the best practice to make components created by JHipster available to other projects?

Question

I'm exploring JHipster, the Spring Boot + AngularJS application generator based on Yeoman.

So far, it's been quite interesting and fun. I've been able to get a vanilla webapp up and running without too much trouble.

Now I want to take a step further, moving the entities, repositories, and services away from the original webapp project.

The webapp project generated by JHipster declares spring-boot-parent as its parent project:

<parent>
    <artifactId>spring-boot-starter-parent</artifactId>
    <groupId>org.springframework.boot</groupId>
    <version>1.3.1.RELEASE</version>
    <relativePath />
</parent>

So I changed it to my own parent project, which looks something like:

<parent>
    <groupId>br.net.neuromancer.bigpolis</groupId>
    <artifactId>bigpolis-parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</parent>

Immediately, I was swamped with Maven build exceptions. :(

I then followed the steps described on Spring Boot - parent pom when you already have a parent pom

I could get to the point where the project builds ok, but errors still showed up while running mvn spring:boot. I was just getting too much trouble for little gain, so I decided to rollback the changes.

Instead I declared spring-boot-parent as the parent of my own parent.

Though this strategy seems to work both for building and running, now I have two major questions.

First, what are the implications of declaring spring-boot-parent as the main parent for all my sub-projects ? Not that I dislike the idea so much, since most (if not all) of the sub-projects do depend on Spring Boot anyway.

But are there any side effects to this strategy that I should be aware?

The second question regards JHipster more closely.

What would be the best practices to make certain components available to non-JHipster projects? Entities, repositories, and services seldom belong exclusively to the webapp, and should be shared with other non-frontend components.

Could I move them to a separate project, perhaps losing the refactoring functionality provided by Yeoman?

Or should I declare the JHipster project as a regular dependency, just letting all the Angular stuff gets packed along the WAR? Somehow that doesn't seem too efficient.

Any pointers, thoughts or comments on what I've just described will be really appreciated. Thanks for reading this far... :)

Follow up a few days later...

I'd like to apologize for asking unrelated questions in the same post. Making JHipster modules available elsewhere is a topic which deserves a post of its own.

That said, here is some follow-up about the Maven parenting issue.

I finally decided against making spring-boot-starter-parent the parent of my own parent:

I prefer to avoid the introduction of too many unnecessary dependencies to other modules, which might rightfully not even care about spring-boot-starter at all.

So I rolled back the earlier changes, then ran the Maven dependency:resolve target to get a list of transitive dependencies for the original setup.

I then added this section to my JHipster pom.xml:

    <dependency>
        <!-- Import dependency management from Spring Boot -->
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
    </dependency>

I had to explicitly declare missing version tags, until the builds within and outside Eclipse were happy.

Only then I ran again mvn dependency:resolution.

The comparison with the previous transitive dependencies list gave me good hints on the causes for errors I was getting on my first attempt.

I patiently fixed each mismatch, declaring variables and dependencies on my POM, until I had exactly the same versions for all dependencies on both setups.

After this manual labor, I was able to get the spring-boot:run target alive again. :)

Contrary to what was stated elsewhere, I did not have to re-configure plugins. But I guess it was only my good luck. I can see why the advice stands.

The downside is that the new POM ended up much larger (and more complex) than before.

https://github.com/javayuga/BigPolis/blob/master/bigpolis-parent/tserd14Browser/pom.xml

I'm pretty sure I can still do more cleanup, but results are enough to let me move on.

I'd like to thank everyone who responded, giving me some food for thought. :)

Answer 1

Question1: Well it really depends. If you keep as your main parent, spring-boot-parent that means that all your sub-module will inherit from it. So is this OK? Is there any case that a submodule is not spring related at all? You need to think about that cases. If they are all spring related, most probably you will be alright, and I am saying most probably since this particular parent even in spring related projects- might fit 100% where you might need to do something very specific (corner cases). The cleanest solution would be to import this parent as 'BOM' as the previous topic suggests. The reason that does not work is that you need to configure the plugins on your own.

Answer 2

As for your first question, are all of your creations going to be Spring-Boot projects? That defines whether the parent needs to be Spring-Boot. The parent is there to save you the trouble of specifying dependencies.

Your second question is about unknown side-effects. If you specify the parent, you should look at it and understand it.

For your third question, it sounds like you need to learn how to create your own generators. I'm doing about the same thing as you. I first created a JHipster app to learn on. I've created a bunch now. I have one I delete and re-create, hack, overwrite, etc. called "goof". Every time I want to test something, I mkdir goof, cd goof, and yo jhipster. I have already written a Mule component (REST client) that talks to the API that's described in the Swagger API rendering using the admin login. I'm going to make a stripped down JHipster that's loses all the Angular stuff and only hosts the API. But, it won't be JHipster anymore, it will be my thing. I'm going to learn how to create a Yeoman generator and it will be my creation not JHipster's. Use JHipster because it's there, do your thing (using Spring-Boot parent if needed) but make your own generator for each thing you make. It sound's like you want your own generator to me. JHipster is complex and it's open source. Hack it up and learn from it. But go learn more about Yeoman generators.