service jar has maven pom version in filename

[Jack Bakker, modifié il y a 9 années.]

I have bizclient-services project

pom.xml has, for example: <version>1.0-SNAPSHOT</version>

service jar in plugin ends up being "bizclient-services-portlet-service-1.0-SNAPSHOT.jar"

--
while a war on liferay:deploy drops the version, the version of the service jar is still in the file name

how do I instead end up with "bizclient-services-portlet-service.jar" ?

[David H Nebinger, modifié il y a 9 années.]

You don't.

Service jars are already version bound (the service.properties has a build number which Liferay checks to ensure version numbers sync). The maven version number on the filename is yet another extension of this inherent versioning.

[Jack Bakker, modifié il y a 9 années.]

David H Nebinger:

You don't.

no, I do want this, I am not talking about service.properties build number here, just filename of service jar

[David H Nebinger, modifié il y a 9 années.]

Jack Bakker:

I do want this

Doesn't matter if you want it or not.

This is really a maven thing than it is a Liferay thing.

The maven project is a parent project with two child projects with one child automagically dependent upon the other. The version number is part of that dependency, and it really can't be broken.

I've tried using the <finalName /> tag in the service project and that can strip off the version, but then the service implementation project fails because it cannot find the service jar.

Possibly you could work some magic during the building of the war to rename the jar, but then there's the whole problem of pushing the service jar into your maven repo so other projects can depend upon it...

So you just need it and you're also stuck with it.

Sorry it's not better news, but it just is what it is.

[Jack Bakker, modifié il y a 9 années.]

David H Nebinger:

Jack Bakker:

I do want this

Doesn't matter if you want it or not.

yes it does

David H Nebinger:

This is really a maven thing than it is a Liferay thing.

The maven project is a parent project with two child projects with one child automagically dependent upon the other. The version number is part of that dependency, and it really can't be broken.

I've tried using the <finalName /> tag in the service project and that can strip off the version, but then the service implementation project fails because it cannot find the service jar.

Possibly you could work some magic during the building of the war to rename the jar, but then there's the whole problem of pushing the service jar into your maven repo so other projects can depend upon it...

Doesn't have to be installed (local maven rep) or deployed (nexus) to be used.

For many years now I have used a 'mvservbizclient' script which moves the service jar out of the portlet into the global classpath. I've added to my script to chop the version too. And in consumer portlets I have in pom.xml

		<dependency>
			<groupid>com.bizclient.server.services</groupid>
			<artifactid>bizclient-services</artifactid>
			<version>1.1</version>
			<scope>system</scope>
			<systempath>${liferay.app.server.lib.global.dir}/bizclient-services-portlet-service.jar</systempath>
		</dependency>

So far this seems to work. Not really magic, more a work around...

[David H Nebinger, modifié il y a 9 années.]

system scope is viewed as 'bad form' for maven pom devs.

It is too dependent upon developer environment and breaks the maven norm.

If you do the "mvn install" (to put into local repo) or "mvn deploy" (to deploy to nexus or some other shared repo), the service jar will be in the repository. Your other plugins can depend upon the jar and don't have to worry about a system path to work (this is ideal for a build system such as jenkins).

If you put the jar in the app server global path, the plugins using the jar just have to include the provided scope (so it doesn't get into the war file). If it is not global, then the normal scope will include the service jar in the war.

Note that this might not be your way, Jack, and I'm not trying to force you to change paths. This is more informational for someone else who stumbles upon this thread and want to know why they shouldn't be trying to strip the version number from the service jar.

[Jack Bakker, modifié il y a 9 années.]

David H Nebinger:

system scope is viewed as 'bad form' for maven pom devs.

yeah, I read and wrote that here also:
https://www.liferay.com/community/forums/-/message_boards/message/47102214

Jack Bakker:

I read that <scope>system</scope> with filesystem <systemPath/> is bad form from a maven perspective, and also moving service jar to global classpath is bad form according to liferay de facto best practices

David H Nebinger:

It is too dependent upon developer environment and breaks the maven norm.

Generally yes, but in my example systemPath references ${liferay.app.server.lib.global.dir} which doesn't incur breakage across developers including Norm

David H Nebinger:

If you do the "mvn install" (to put into local repo) or "mvn deploy" (to deploy to nexus or some other shared repo), the service jar will be in the repository. Your other plugins can depend upon the jar and don't have to worry about a system path to work (this is ideal for a build system such as jenkins).

Clearly Jenkins is a friend of Norm

David H Nebinger:

If you put the jar in the app server global path, the plugins using the jar just have to include the provided scope (so it doesn't get into the war file). If it is not global, then the normal scope will include the service jar in the war.

Note that this might not be your way, Jack, and I'm not trying to force you to change paths.

Ideally, following Maven Norm, yes, putting jar into local or nexus repos for subsequent reference would be nice.

David H Nebinger:

This is more informational for someone else who stumbles upon this thread and want to know why they shouldn't be trying to strip the version number from the service jar.

from: https://www.liferay.com/community/forums/-/message_boards/message/44313244

EDIT: to be clear, David's comment below from other thread relates to version numbers at end of war filenames, not end of service jar filenames

David H Nebinger:

You can leave the version number on there.... It is dropped during hot deployment so it doesn't become part of your URL or anything.

magic

pom versions ; service.properties build.number ; JIRA issue ids with Stash branches ; git ids... this guy Norm though... I think I like him

Enjoy

[Jack Bakker, modifié il y a 9 années.]

I am guessing that even a folder name like "liferay-portal-6.2-ee-sp6" is involving appending of pom version.

How sticky or stuck is that given use patching-tool upgrade to newer service pack, and the -sp6 is no longer relevant.

The service jar which is subject of this thread with pom version appended also is another versioning than a service.properties build.number ; and then also different from a maven archetype version where -sp9 is actually (internally) is 6.2.10.10

yes David, for what it's worth, yes, some maven-specific questions here to further discovery by navigating the stars

[David H Nebinger, modifié il y a 9 années.]

Oh, I feel your pain, Jack. I've shared in it also.

But at the end of the day, I've taken the kool aid and drank upon it just like the other sheeple.

[Jack Bakker, modifié il y a 9 années.]

David H Nebinger:

Oh, I feel your pain, Jack. I've shared in it also.

But at the end of the day, I've taken the kool aid and drank upon it just like the other sheeple.

Yeah, I guess there is no point in spending an enormous amount of time:money on a fridge, when the rest of the kitchen is lacking, let alone the whole house or neighborhood, etc... oh, right, I guess there are also people who live there

btw, secret trick, don't tell anybody: putting silly in a post can be useful for searching out your posts in Google. "Sheeple" ... tag, your it

[David H Nebinger, modifié il y a 9 années.]

I'm almost at 7,500 posts. I can't see where I'd want to add sheeple to every post to find them...

I tend to subscribe to the ones that I'm currently working, that plus "my posts" view shows updated threads I've participated in. Those two combined ensures that I'm on top of the ones I'm concerned about.

[Jack Bakker, modifié il y a 9 années.]

yeah, you are too far along to use a silly tag method, like -spDavid or something...

congrats on the number of posts

[David H Nebinger, modifié il y a 9 années.]

Jack Bakker:

I have bizclient-services project

pom.xml has, for example: <version>1.0-SNAPSHOT</version>

service jar in plugin ends up being "bizclient-services-portlet-service-1.0-SNAPSHOT.jar"

--
while a war on liferay:deploy drops the version, the version of the service jar is still in the file name

how do I instead end up with "bizclient-services-portlet-service.jar" ?

Okay, Jack, I now think this is a bug and should be reported as such.

When you enter a "required-deployment-contexts" value in liferay-plugin-package.properties, the com.liferay.portal.tools.PluginsEnvironmentBuilder.getRequiredDeploymentContextsjars() method has code that checks to see if there is a corresponding file in /WEB-INF/lib that has the context plus "-service.jar". With Maven adding the version number, the service jar will not be found and will have unknown results.

That being said, I don't think the PluginsEnvironmentBuilder class is used in the portal runtime, so it may not be a significant bug. Other spots in the code where the required deployment contexts are given do not look for a corresponding service jar, so the more I think about it the less significant the bug seems to be, but it should probably still be reported.

[Jack Bakker, modifié il y a 9 années.]

good find, yeah, this isn't slowing me down currently but worth digging further into