Not able add external jars in DXP module

[Kushagra Khanna, geändert vor 6 Jahren.]

Hi Team,

I struggling with some issue that I am not able to add any external jars dependency in DXP module, I have gone through the several documents but fails to achieve the success, please share relevant steps to make external dependency on module.

Thanks,
Kushagra

[Alfonso Crisci, geändert vor 6 Jahren.]

Hi Kushagra,

Did you come across the below documentation already?

https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/adding-third-party-libraries-to-a-module
(Feel free to browse around on the site and search for related topics if you wish)

Is it of any relevance for you?

Hope it helps !

[Peter Helgren, geändert vor 6 Jahren.]

I just posted a similar issue in the Portal Frameworks group. Your reference is pretty good, but here is what I posted in reference to a blog post along similar lines by David Nebinger:

1) You mention build.gradle but no mention of *which* build.gradle file. In a service builder module project, there are three of them. Which build.gradle do you put the directives in?

2) Assuming the .jar doesn't exist in the maven repository, where will the build.gradle get the jar it expands or embeds? I am moving quite a bit of code from 6.0.6 to 7.0 and I have a bunch of jars that don't exist in any repository. How/where do we tell the build the process to find the jars?

3) Is it possible to show the "before" and "after". Code snippets are great to keep the post short, but when listed out of context, the snippets can be confusing. The entire grade.build, before the external jars are added and afterward, would be helpful.

Adding the above would make the entry more useful (to me at least).

Thanks

[David H Nebinger, geändert vor 6 Jahren.]

Peter Helgren:

1) You mention build.gradle but no mention of *which* build.gradle file. In a service builder module project, there are three of them. Which build.gradle do you put the directives in?

Always in the build.gradle of the module that has the dependency.

2) Assuming the .jar doesn't exist in the maven repository, where will the build.gradle get the jar it expands or embeds? I am moving quite a bit of code from 6.0.6 to 7.0 and I have a bunch of jars that don't exist in any repository. How/where do we tell the build the process to find the jars?

You can always install your jars in your local repo using the following syntax:


# Install an artifact into local repo
mvn install:install-file –Dfile=path.to.file –DgroupId=group-id –DartifactId=artifact-id –Dversion=1.0.0.0 –Dpackaging=jar –Dsources=srcs.jar –Djavadoc=docs.jar

This is actually a better path because it allows teams to reference dependencies w/o forcing everyone to use a known path.

3) Is it possible to show the "before" and "after". Code snippets are great to keep the post short, but when listed out of context, the snippets can be confusing. The entire grade.build, before the external jars are added and afterward, would be helpful.

Not really before and after perspective, more like just after, but here's my project that has some external dependencies: https://github.com/dnebing/filesystem-access








Come meet me at the 2017 LSNA!

[Peter Helgren, geändert vor 6 Jahren.]

Thanks, as always....

One follow up question, probably because I am not being clear. When it comes to the build.gradle file, I am still a little confused. If I were to build a new service builder module called "MyModule" I would see the following in project Explorer:

MyModule
(with a build.gradle)
MyModule-api
(with a build.gradle and a bnd.bnd)
MyModule-service
(with a build.gradle and a bnd.bnd)

Most of the work I do is in the source in MyModule-service. I haven't yet had to touch any of the source in MyModule-api. Each of the build.gradle files is slightly different. So, when you say: "Always in the build.gradle of the module that has the dependency." I guess I'd wonder what you consider the "module" folder to be in an SB module? The "root", the "api," or "service" folder ? That is what is throwing me. In SB, since I think all of the source modifications occur in the "-service" folder, can I assume that the build.gradle in the "-service" folder is the one to use since that is where the implementation of the interfaces is? Or, since the interface and service definitions are in "-api" is that build.gradle the one to use?

Again, I see "MyModule" as THE module but since "-api" and "-service" are two separate jars, which would be considered the "module"? Would it be safe to say that all build.gradle and bnd.bnd file modifications should be in the "-service" folder in an SB module?

[David H Nebinger, geändert vor 6 Jahren.]

Peter Helgren:

Most of the work I do is in the source in MyModule-service. I haven't yet had to touch any of the source in MyModule-api. Each of the build.gradle files is slightly different. So, when you say: "Always in the build.gradle of the module that has the dependency." I guess I'd wonder what you consider the "module" folder to be in an SB module? The "root", the "api," or "service" folder ? That is what is throwing me. In SB, since I think all of the source modifications occur in the "-service" folder, can I assume that the build.gradle in the "-service" folder is the one to use since that is where the implementation of the interfaces is? Or, since the interface and service definitions are in "-api" is that build.gradle the one to use?

Again, I see "MyModule" as THE module but since "-api" and "-service" are two separate jars, which would be considered the "module"? Would it be safe to say that all build.gradle and bnd.bnd file modifications should be in the "-service" folder in an SB module?

A module, in OSGi, is a jar so, although "MyModule" is the parent folder, it is not represented as a jar. The -api and -service modules are both jars.

If you're familiar w/ Intellij or Maven, they tend to refer to folders as modules and I'm afraid that might be adding to your confusion.

But in OSGi, when we talk about modules, we're talking about bundles or jars.








Come meet me at the 2017 LSNA!

[Peter Helgren, geändert vor 6 Jahren.]

I am not familiar with Maven or IntelliJ which might be a "future" issue for me.

OK! So it sounds like I can safely ignore the build.gradle in the "root" module folder. The "-api" jar doesn't have any implementation details. Which leaves me which the "-service" folder where I am adding dependencies for JavaMail so my guess is that the build.gradle in the "-service" folder is where I will be identifying dependencies and modifying bnd.bnd

I am also going to re-read through the service builder documentation again at the LR dev site. Still many questions to be answered....

Thanks

[David H Nebinger, geändert vor 6 Jahren.]

Peter Helgren:

I am not familiar with Maven or IntelliJ which might be a "future" issue for me.

Well, maven is the alternative build tool, if you're using gradle you won't have to worry about it. Intellij is an alternative IDE (I prefer) over Eclipse (or Liferay IDE/Dev Studio), so you won't have to worry about it either.

OK! So it sounds like I can safely ignore the build.gradle in the "root" module folder. The "-api" jar doesn't have any implementation details. Which leaves me which the "-service" folder where I am adding dependencies for JavaMail so my guess is that the build.gradle in the "-service" folder is where I will be identifying dependencies and modifying bnd.bnd

The build.gradle at the root folder is not necessary for a Liferay Workspace usage, that file can actually be deleted. In a non-workspace, it may be used but I actually haven't worked much with non-workspace grade so I don't know if it has value or not.

Take care not to expose your javamail dependency through the API. For example, if you put a method in XxxLocalServiceImpl that takes a javax.mail.internet.InternetAddress object as a parameter, you're going to bleed the javamail dependency all over the place. First the -api would incur a dependency on javamail, then every other module that wants to use the service layer through the -api will also incur the transitive dependency. It can get quite painful if you can't limit the dependencies to just the -service module.

I am also going to re-read through the service builder documentation again at the LR dev site. Still many questions to be answered....

Bring it!








Come meet me at the 2017 LSNA!

[Peter Helgren, geändert vor 6 Jahren.]

Whoa! Thanks for that tidbit! In this particular case, the references to JavaMail are internal to the method, not a parm, but, wow! what a hassle. I'll need to look at the current LR 6.0.6 stuff I am porting and make sure that the parms I am passing won't generate additional dependencies downstream....

BTW...the Gradle stuff is actually fairly cool. It is taking me a while to look at the build and deploy steps differently, not to mention redefining some architecture but adding dependencies (when you figure out how) makes for a fairly easy build. Reminds me of Ruby and bundler

[Kushagra Khanna, geändert vor 6 Jahren.]

Hi David,

Thanks for reply,
I want to add on that I have added respective poi and poi-ooxml jars inside lib/ext for tomcat bundle, but still facing the same issue as dependency are still not resolved.
I am using poi-3.16-beta2 and poi-ooxml-3.16-beta2 jars.

Please provide suggestions on the same.

Thanks,
Kushagra