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

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.

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

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

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.