Single repo (new attempt)

[erikkemperman]

@jdubois To make my thinking more concrete, here's a proposal to put the jhipster serverside library and jhipster-dependencies in a single repository, with all plugin configuration managed in the same place.

This would resolve the co-dependency issue I mentioned here.

I've verified that maven-release-plugin, when running mvn release:prepare from the top directory, correctly replaces all the right version properties, so I would expect mvn release:perform to work well and release all three artifacts simultaneously.

Also, Travis works because it just hands off to the maven reactor, which builds the modules in the appropriate order -- and so Travis would fail if Maven fails.

But I noticed that the server-side library doesn't have any unit tests? This means that surefire and jacoco don't actually do anything at the moment... This is already the case on current master, though, so unrelated to this PR.

For what it's worth, I think it'd be all right to consider something like this change independently of the moment at which you would like to move generator-jhipster to use the new BOM.

Finally, if we would like to add some "steroids" like @Tcharl suggested, we would now have quite a natural place to do that.

[deepu105]

Ok to merge these 2

…

On Thu, 8 Mar 2018, 5:59 pm Julien Dubois, ***@***.***> wrote: Sorry guys, I've spent so much time on Spring Boot 2... And it's not totally finished yet!!! So yes we could merge jhipster/jhipster-dependencies and jhipster/jhipster as they are tightly linked, and it doesn't make much sense to separate them. Then I know I broke a big part of this PR when working on Spring Boot 2, and it's probably not finished yet.... At least is there anyone against this idea? So we all agree that it's the way to go. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDlFwc-dPf98vwWcRE6YtaD6FtMdH71ks5tcWNxgaJpZM4P5YPr> .

[erikkemperman]

Great! If no-one objects, I might be able to find some time to update this PR during the weekend?

[jdubois]

Yes good for me - now most of the work on Spring Boot 2 should be OK, at least it's not the big mess it was until last week!! 2018-03-09 21:23 GMT+01:00 Erik Kemperman <notifications@github.com>:

…

Great! If no-one objects, I might be able to find some time to update this PR during the weekend? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATVo_WRjILOapXDLEma1SohSZJvnON-ks5tcuTFgaJpZM4P5YPr> .

-- Julien Dubois Twitter: @julienDubois <http://twitter.com/#!/juliendubois>

[erikkemperman]

So, I've updated the PR, it is now based on the latest versions of both the server lib and the dependencies. The history of the jhipster-dependencies module was replayed here, so all attributions should remain valid, and the references to "PR hashtags" in commit messages were replaced with explicit URLs so they keep pointing to the old locations.

Please double-check if I am doing the right things here regarding snapshots -- I wasn't too sure what has been going on lately :-) For what it's worth, in this PR I was thinking to link the dependencies and server-lib artifacts and release them together. I've initially set the version at 2.0.0-SNAPSHOT. But note that such linkage is certainly not a requirement, if you prefer you could do it separately, and in that case the versions need not be the same.

There is a commit at the end which should not be merged, this only changes the repo and branch where Travis fetches the generator for running tests. It is just there to make the Travis build pass, let me know if you want to me get rid of it so you can merge more easily.

It still seems to me that we may be doing some things the wrong way around, if that makes sense; I have to commit and push changes to generator code (version refs) before I can run proposed adaptations to the dependencies and server-lib through CI. I guess I am missing something?

[jdubois]

I'm modifying the artifactId from jhipster-server back to jhipster, there's no need to have a jhipster-server.jar

[jdubois]

So this badly broke the build, because we can't do SNAPSHOT releases on JFrog :-(
We're back to doing 2 different fixed releases - not sure that the merge makes any sense anymore :-((((
I'm fixing the build first, but we'll need to think at how this can be improved

[erikkemperman]

Ehm, not sure what you're trying to do -- but the advantage of merging these is not limited to SNAPSHOT releases in my opinion. I don't see why you couldn't link RELEASE releases in the same way. You're using maven-release-plugin, right?

Also, I am unfamiliar with JFrog but I'm assuming it has some advantages over the usual suspects for deployment that weigh more heavily than the disadvantage of not supporting snapshots?

[jdubois]

no I'm just doing a "mvn deploy" to do a release, in each module (as the parent module isn't registered on Maven Central).
How do you think I should do the release?

[jdubois]

OK I'm just totally lost and I can't do a release anymore, and the build is broken :-(
Doing "mvn deploy" breaks in strange ways in both the dependencies and server libs...

[erikkemperman]

Well, I've never had to register any modules on Maven Central as the things I work on are usually there already. But I just do

mvn release:prepare
mvn release:perform

But I've tried that and it fails because we still rely on the Cairo.SNAPSHOT version of spring-platform... So that sounds like the same problem you see?

In the meantime Cairo.RC1 is out, and it looks like that will work. I'm currently preparing a PR to include that (along with aligning other dependencies).

[jdubois]

OK I got it working with mvn deploy but I'm basically doing the same thing as before...

[erikkemperman]

Are you still releasing the server-lib and dependencies separately? I thought the main idea here was to get rid of the cyclical co-dependency that we had to update the server.version properties in the dependencies POM for each new server release, and then vice versa for each dependencies release? Having them in a single repository should allow you to release them both at the same time.

I'm currently running the version bumps through Travis, including Cairo.RC1, for what it's worth.

[jdubois]

Yes indeed, but I'm stuck with JFrog Artifactory - when you do a SNAPSHOT release, they give you a unique ID. But you can't know that ID before releasing.... So I have no other choice than:

• Deploy a "jhipster-dependency" and use its id in "jhipster-server"
• Deploy "jhipster-server" and gets its new ID
• Re-deploy "jhipster-dependency" so it uses the new "jhipster-server" ID

This is pretty stupid. But this should go away when we do non-SNAPSHOT releases on Maven Central, as we will know the IDs in advance.

[erikkemperman]

Ah, I see! Hmm, that's pretty inconvenient for a lot of scenarios I would imagine... I also wonder if the release plugin recognizes those IDs as snapshots, I guess you might have to edit them manually before doing a (non-snapshot) release. Huh!