Rename artifacts

[erikkemperman]

@jdubois
I would like to propose renaming the server-lib artifact, because it clashes with the artifactId of generated apps (with default settings) and Eclipse refuses to import because of it... It would only require a minimal change in generator and registry. The major v5 of the generator, along with a major v2 of the server-lib, would be the time to do it (if it is done at all).

Also, jhipster-parent is not a very descriptive name for the POM at this repo's root, it's not actually used as a parent anywhere. How about jhipster-build instead?

PS -- I think I had this in the original PR which merged jhipster-dependencies into this repository, looks like you changed it back deliberately. So maybe you don't think this is a good idea... Feel free to just close this in that case!

[jdubois]

• totally OK for jhipster-parent to jhipster-build (or whatever, this isn't used by anyone)
• for jhipster-server: I agree it's more descriptive, but 1) I don't understand your issue and 2) I find it very surprising that we have a jhipster-server.jar in our Java application... it's obvious it's "server", we're in Java. That's why I wanted to call it just "jhipster". Then maybe we could find another name, like jhipster-framework?

[erikkemperman]

Well, it’s that jhipster is also the default app name when the generator is run with all defaults, and Eclipse refuses to import it (even though groupId is different!)

So anything but jhipster would work for me, jhipster-framework or -common or -library would be fine if you don’t like -server.

Let me know which, and I’ll amend! And if it’s merged I’ll make PRs for generator and registry as well.

[jdubois]

-common or -library also don't give much relevant information :-(
And I also find -server misleading, people might think we do a server, like Netty or Tomcat...

So let's go with jhipster-framework, as it's on top of the Spring Framework, it makes more sense to me.

Let's wait for tomorrow for this, to give some time to people to react if they don't agree with the naming.

[erikkemperman]

All right!

[deepu105]

ok for, jhipster-framework Thanks & Regards, Deepu

…

On Tue, Apr 10, 2018 at 5:29 PM Erik Kemperman ***@***.***> wrote: All right! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABDlF6gDZRPdPZK7pFTQYQuIOZtlcqKVks5tnM_KgaJpZM4TObqi> .

[pascalgrimaud]

jhipster-framework sounds good

[erikkemperman]

Changed it to jhipster-framework :-)

Also, I figured it might be good to move some stuff -- like pluginManagement and build properties -- into the parent. That kind of thing doesn't really belong in a BOM project, I think. But then we're actually using jhipster-parent as a parent, so no need to rename it. But this is in a separate commit so I can easily get rid of it if you don't like the idea!

I have a corresponding patch ready for the generator, here:
https://github.com/erikkemperman/generator-jhipster/commits/rename-artifacts-2

Probably the registry will need work as well, but I was thinking that might actually benefit from inheriting from jhipster-parent as well, it would eliminate some redundancy. Does that make sense?

Of course Travis will fail here, but this shows that things mostly work (same code but custom JHIPSTER_REPO vars to use my branches):
https://travis-ci.org/erikkemperman/jhipster/builds/365027958

The single failure is the uaa app, which the Travis scripts seem to still get from mvnrepository instead of github, even though the JHIPSTER_REPO environment variable is pointing to my corresponding branch.

[erikkemperman]

Pushed another commit, so the problem with testing the UAA sample is now fixed (by replacing versions in the generator as well).

Everything passes now:
https://travis-ci.org/erikkemperman/jhipster/builds/365654942

Will also make a accompanying PR to the generator. If approved, please merge both at the same time.

[erikkemperman]

Ref jhipster/generator-jhipster#7477

[jdubois]

Looks good to me, let's try this!

[jdubois]

Oh, I realize we have an issue with the "SNAPSHOT" versions -> this is going to make the JHipster release v5.0.0.beta.0 fail....
So for me we need another release for jhipster-parent, etc... How about a stable one?