Adding custom java project (jar) to my portlet in plugins SDK

[Piña Kanpokaldean, modificado 12 Anos atrás.]

Hi,

I'm developing a base model to be shared by a considerable number of portlets. So, I created an standard java project, put some classes in there, and set Eclipse's (well, liferay IDE actually) deployment assembly to depend on this java project. When I try to deploy it locally, things go fine and the jar gets added to webinf/lib the deployed portlet, but when I want to move it beyond that by getting the SDK to build me a WAR file I can use on other environments the war doesn't include this jar. I assume this is either because plugins SDK conifguration is independent from eclipse's and doesn't know it needs to add one more jar, or because I need to ask eclipse to keep the jar file on the webinf/lib constantly and not only add it during deployment. How can I do that?

Due to management decision, each portlet must remain in it's own war, so I can't put them all in one project. Adding my jar to tomcat's lib folder could be a solution later on, but the model is much too young right now and keeps changing very fast, so uploading it every time would be quite a pain.

[Nick Straguzzi, modificado 11 Anos atrás.]

Hey, did you (or anyone else) find a solution to this? I'm having the same issue. The Ant build scripts aren't picking up what I've set in Eclipse under Deployment Assembly -- not surprising, of course, but I'm not sure how to tell Ant to package my user libraries into the WEB-INF/lib directory when building my WAR.

Thanks,
Nick

[David H Nebinger, modificado 11 Anos atrás.]

Copy your jar to an EXT plugin in the docroot/WEB-INF/ext-lib/portal directory and deploy the EXT plugin.

In your plugin projects, declare the jar as a dependent jar in liferay-plugin-package.properties. At deployment time it will be copied to your plugin and all will be satisfied.

[Piña Kanpokaldean, modificado 11 Anos atrás.]

That's a nice one, I'll give it a try. Thanks.

[Nick Straguzzi, modificado 11 Anos atrás.]

David, thanks for the response but I'm hoping to find a different solution. Two reasons:

(1) I do not want to use an EXT plugin in this portal project, for the usual reasons plus a few others. I would like to stay with the newer, cleaner, hot-deployable plugins only.

(2) This really ought to be a fairly simple build management issue. I think I need only tell Ant that when building a particular WAR, to include certain libraries on the build path and to include those JARs in WEB-INF/lib. If I have to maintain separate build/deployment descriptors in Eclipse and in Ant...well, okay, I guess I can live with that. I'd just like to know if there's a best practices solution wrt Liferay.

Thanks,
Nick

[David H Nebinger, modificado 11 Anos atrás.]

Best practice is to use the liferay-plugin-package.properties file to pull in dependent jars. That way you don't end up w/ a bunch of different versions of the same jar across your platform.

To conform to that best practice, a custom jar should be treated in the same way. The only way to treat a custom jar in this manner is to deploy it via an EXT plugin.

Yes, EXT plugins do require app server restart, but the same would be true to put them in the global class loader path (/lib/ext).

The ant build scripts themselves do not do anything w/ jars outside of referencing the ones from WEB-INF/lib and jars from the liferay-plugin-package.properties file. Should you choose your own mechanism, you're going to be responsible for working it into the build scripts and supporting it when new versions of the SDK are released. None of these things are problems if you adhere to the process I outlined above.

And frankly I don't see why everyone is down on the EXT plugin. It has one requirement only, and that is a app server restart is required after deployment. That really is not so much of a big thing. Other arguments against using the EXT (in the right way) don't really hold water.

Eclipse is just a tool to help develop plugins, but ant is still the tool used to build them within the SDK (until at some point it gets replaced with maven). If you want to go down this road, you're going to have to hack up the ant build process.