Import-Export jar

30 views
Skip to first unread message

hpa...@gmail.com

unread,
Nov 6, 2017, 10:29:49 AM11/6/17
to dotCMS User Group
Hello,

I have a dynamic plugin "Project-A". It has API service calls that will be used by other plugins. Is there a way I can export the jar of "Project-A" using build.gradle and all other plugins could import the same using their build.gradle.

Any help is appreciated!!

Thank you!!

Jason Tesser

unread,
Nov 6, 2017, 10:38:15 AM11/6/17
to dot...@googlegroups.com
this is an OSGi thing more then a gradle thing per say but yes this is what the Export is for in the manifest which is configurable in the gradle build. 

see 

in fact the service plugin I linked right above is an example of what you are trying to do 

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/4b5255eb-629a-40c9-ae75-9cecdf5618f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nathan Keiter

unread,
Nov 6, 2017, 10:54:08 AM11/6/17
to dot...@googlegroups.com

FWIW, I would avoid the extra complexity.  Typically, there’s not much overhead in including the needed classes in each of the dependent plugins.  I prefer all my plugins to be “stand-alone” capable.  For example, if several plugins require my “ContentletUtility” class, I just include a copy of ContentletUtility.java in each plugin package.  If a global change is needed to that class, a simple copy-paste in eclipse will do it rather easily. Then recompile, redeploy. While typically I would tend to avoid this kind of redundancy, the benefit of easy “stand-alone” plugins outweighs my concern.

 

OSGI can be tricky enough without relying on external dependencies.

 

Nathan I. Keiter | Lead Network Applications Programmer | Benefits Advisory Council Member | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993

https://www.gettysburg.edu

hpa...@gmail.com

unread,
Nov 6, 2017, 1:20:37 PM11/6/17
to dotCMS User Group
Basically the idea was to move all content saving/updating/deleting functionality to one plugin and let all the other plugins call this service. This idea was suggested by DOTCMS when they came to HCA.

To post to this group, send email to do...@googlegroups.com.

Nathan Keiter

unread,
Nov 6, 2017, 1:30:06 PM11/6/17
to dot...@googlegroups.com

Proceed as you want. I’m just giving you my opinion based on my experience writing OSGI plugins.

 

Nathan I. Keiter | Lead Network Applications Programmer | Benefits Advisory Council Member | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993

https://www.gettysburg.edu

 

hpa...@gmail.com

unread,
Nov 6, 2017, 1:34:05 PM11/6/17
to dotCMS User Group
Am sorry if i offended in any way... i was just giving more explanation on where i am coming from. I have zero experience in this import-exporting jars withing dotcms osgi plugins. I am completely depending on whatever suggestions you are providing here..

Nathan Keiter

unread,
Nov 6, 2017, 1:41:36 PM11/6/17
to dot...@googlegroups.com

No offense taken. Just trying to help. I have over 10 years experience  with dotCMS and I wouldn’t do it that way personally.

 

Is what they are suggesting possible? Yes, but personally I don’t think it’s worth the headaches.

hpa...@gmail.com

unread,
Nov 6, 2017, 1:46:53 PM11/6/17
to dotCMS User Group
Hmmm...  so you are saying it would be more feasible to
1. Either import the plugin jar to every plugin project.
2. Or to just use the save/update/delete methods directly in every plugin.

Nathan Keiter

unread,
Nov 6, 2017, 1:51:09 PM11/6/17
to dot...@googlegroups.com

#2. Add the source code of the package or classes directly to each plugin. (To avoid namespace conflicts adopt the package name of the specific plugin.)

 

For example by class:

 

edu.gettysburg.nkeiter.transportation.utilities.ContentletUtility.java

 

edu.gettysburg.nkeiter.admissions.utilities.ContentletUtility.java

 

Or by package

 

edu.gettysburg.nkeiter.transportation.utilities.content.services

 

edu.gettysburg.nkeiter.admissions.utilities.content.services

hpa...@gmail.com

unread,
Nov 6, 2017, 1:54:41 PM11/6/17
to dotCMS User Group
Cool!! i will update so... thank you for the help!!

Nathan Keiter

unread,
Nov 6, 2017, 2:01:48 PM11/6/17
to dot...@googlegroups.com

Cool. For a more concrete example, every plugin I write now uses a custom logger class if applicable:

 

https://github.com/nkeiter/generic-dotCMS-plugin-code-examples/blob/master/dotcms4.1.1/osgi/org.example.nkeiter.template.viewtool/src/main/java/org/example/nkeiter/template/viewtool/log/Logger.java

 

https://github.com/nkeiter/generic-dotCMS-plugin-code-examples/blob/master/dotcms4.1.1/osgi/org.example.nkeiter.generic/src/main/java/org/example/nkeiter/generic/log/Logger.java

 

https://github.com/nkeiter/generic-dotCMS-plugin-code-examples/blob/master/dotcms4.1.1/osgi/org.example.nkeiter.contentlet.rest.light/src/main/java/org/example/nkeiter/contentlet/rest/light/log/Logger.java

 

Now depending on where it’s deployed the server names would be a little different, so it’s not the purest example, but should give the general idea. In a pure example, the source would be identical across all plugins. Unfortunately I don’t have any example code loaded on GitHub demonstrating that, but here in our private repos I have many such examples.

Nathan Keiter

unread,
Nov 6, 2017, 3:15:31 PM11/6/17
to dot...@googlegroups.com

Here’s another example. A copy of this class is in every plugin which runs queries against an Oracle database. It’s a helper method which parses the string value returned to a Java date object.

 

https://gist.github.com/nkeiter/4652d4aadddb6ce00434fc2b01174f82

 

Nathan I. Keiter | Lead Network Applications Programmer | Benefits Advisory Council Member | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993

https://www.gettysburg.edu

 

hpa...@gmail.com

unread,
Nov 6, 2017, 3:20:55 PM11/6/17
to dotCMS User Group
So you are adding the class to every plugin that needs to use this functionality. what would be the drawback of adding the plugin jar file itself to those plugins which need it?

Nathan Keiter

unread,
Nov 6, 2017, 3:26:34 PM11/6/17
to dot...@googlegroups.com

Here’s one of my personal favorites. This adds useful shortcuts to commonly used functions for any plugin which uses the contentletAPI.

 

So then I can just use shortcuts like ContentletUtility.checkout( contentlet );

 

Or ContentletUtility.findContentletByIdentifer( identifier );

 

https://gist.github.com/nkeiter/604d27e17c492a826079a71ba7746a05

Nathan Keiter

unread,
Nov 6, 2017, 3:38:08 PM11/6/17
to dot...@googlegroups.com

If you are just putting the commonly used libraries in a jar and placing that in the /libs/ folder of the plugin, that would probably work.

 

/libs/CommonUtilities.jar

 

This would require build.gradle changes to include the libs, and preclude source code access at the plugin level.

 

Note: You cannot put a dotCMS plugin jar in this location. (Then you’d have a plugin inside a plugin.)

 

I just find it simpler to have a standard build.gradle and include the source itself. Then it’s a simple build process.

Reply all
Reply to author
Forward
0 new messages