best practices: deployment of aggregate JARs produced by the assembly plug-in

if this is done with a classifier or just a change in extension, then it would complicate the system to create a new POM.

Is anything in the POM changed other than the dependencies?

If it is just that, I'd like to ehance the current feature in the artifact handler that blocks transitive dependencies to become a filter out dependencies included in the archive but keep the rest as transitive. This could be information built into the JAR?

We are going to have to do some legwork at the front-end or at the back-end. I think making a POM that actually represents what's in the JAR is a more simple approach and less confusing to users. If you looked at the POM for the embedder all-in-one JAR you wouldn't expect any dependencies. I think this would also more closely match the way someone not building with Maven would approach the situation: they would simply make JAR which aggregate anything desired and then create a POM to match. I don't think trying to use the same POM really makes sense here. I would say do the leg work up front and let people use the artifact as a simple JAR dependency.

We also have the information at hand in the assembly descriptor to accurate make the POM up front. What if the assembly wasn't a complete closure of all dependencies? Then the artifact handler gets even more complicated, or we're hunting around in JAR for special hinting.

The wiki has been updated and we've decided to create new POMs for new artifacts so that third party use will work without Maven magic.