Gradle build fails when using com.liferay.ext.plugin

RE: Gradle build fails when using com.liferay.ext.plugin

2020-05-14T17:00:27Z

Hi Asier,I am having the same problem. Did you solve your issue? If so, can you post your solution?Thank you!!

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-06T22:44:52Z

It is in the first entry of this thread, that's the actual build.gradle file.

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-06T22:25:22Z

How are you adding the dependencies to the build file? can you post an example of what you are trying that doesn't work?

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-06T22:17:55Z

Thanks for your inputs! We all agree that using the ext is something to avoid. But it still is a tool that is available in 7.2, and the point of this post is that the ext building doesn't work.
This is how I can reproduce it with Liferay Developer Studio 3.6.2:1) Create a Liferay Module Project
2) Use a war-core-ext template
3) Add UserLocalServiceImpl from the Liferay code4) Add dependencies to the build file.5) Build it.
The dependencies in the build file are ignored.

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-06T17:17:19Z

I like Dave's idea of UserLocalServiceWrapper. Much more upgrade friendly approach. If you ever plan to upgrade liferay, do yourself a favor and use UserLocalServiceWrapper instead of ext-plugin.

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-06T10:28:37Z

"The deal is that we need to allow duplicated email addresses."

That's fine, but there's no reason to abuse or change Liferay for this...

I've done similar things by storing the real email address(es) separately from Liferay's table and then use fake but unique values in Liferay's store. You can then use a user local service wrapper to resolve the storage and lookup issues and index post processors to update the indexing.

Would I really implement this requirement over using an EXT plugin? Absolutely. EXTs really should be avoided that strongly.

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-05T21:40:06Z

To be clear... I am not modifying anything (yet). Just copied the UserLocalServiceImpl to the newly created ext plugin (using the LDS), added the dependencies to the build.gradle, tried to build, would not work.

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-05T19:17:49Z

Olaf,
I totally agree that ext is something to be avoided. The deal is that we need to allow duplicated email addresses. Using a Wrapper for this makes it necessary to actually replicate almost everything from the original service in the wrapper, because there is no validation implementation that we can override safely due to a design decision. So more than a wrapper, we would have a wrapper that is actually a copy of the wrapped class.

In any case, the issue is that the ext doesn't even compile. It looks like the issue is that the dependencies that I am adding to build.gradle are ignored. I am not using the liferay-workspace, but just adding a Liferay Module Project from a war-core-ext template using the Liferay Developer Studio, and gradle build doesn't work. Any ideas why?

Best,
Asier

RE: Gradle build fails when using com.liferay.ext.plugin

2019-11-05T07:23:52Z

Asier Del Pozo:

When running "gradlew deploy", the build will fail due to not finding the classes in javax.mail. Same dependencies added to a regular OSGI module, it works.
What's wrong?

Pardon my ignorance: I believe that the approach to use an ext is wrong. (this is a safe assumption in more than 95% of ext plugins I've seen, thus it's my suggestion number 1)
Apparently you want to introduce some mail processing into UserLocalService.
Mail processing shouldn't be done synchronously anyway, in order to not slow down day-to-day operations. And UserLocalService additions shouldn't be done in an ext, but rather in a ServiceWrapper.
Unless I see a hint that points into the other direction, my suggestion is to implement a ServiceWrapper that drops a message on the MessageBus. Then implement the receiving end that asynchronously handles the required mail.

Gradle build fails when using com.liferay.ext.plugin

2019-11-04T15:15:54Z

I created an ext plugin using Liferay Developer Studio 3.6.2 (not using blade or liferay-workspace). It created everything apparently fine, including the build.gradle file.
I add to the project UserLocalServiceImpl from Liferay's 7.2 portal code, in the extImpl section. Nothing new.
If I add the dependencies for UserLocalServiceImpl , this is what build.gradle looks like:

buildscript {
&nbsp;&nbsp; &nbsp;dependencies {
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;classpath group: "com.liferay", name: "com.liferay.gradle.plugins", version: "4.0.23"
&nbsp;&nbsp; &nbsp;}
&nbsp;&nbsp; &nbsp;repositories {
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;maven {
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;url "https://repository-cdn.liferay.com/nexus/content/groups/public"
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;}
&nbsp;&nbsp; &nbsp;}
}
apply plugin: "com.liferay.ext.plugin"
apply plugin: "eclipse"
eclipse {
&nbsp;&nbsp; &nbsp;classpath {
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;plusConfigurations += [configurations.portal]
&nbsp;&nbsp; &nbsp;}
}
repositories {
&nbsp;&nbsp; &nbsp;maven {
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;url "https://repository-cdn.liferay.com/nexus/content/groups/public"
&nbsp;&nbsp; &nbsp;}
}
dependencies {
&nbsp;&nbsp; &nbsp;compileOnly group: 'javax.servlet', name: 'javax.servlet-api', version: '3.0.1'
&nbsp;&nbsp; &nbsp;compileOnly group: 'javax.mail', name: 'mail', version: '1.4'
}

When running "gradlew deploy", the build will fail due to not finding the classes in javax.mail. Same dependencies added to a regular OSGI module, it works.
What's wrong?