Message-ID: <1692105952.297872.1368872550210.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_297871_731090977.1368872550209" ------=_Part_297871_731090977.1368872550209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We need a way to deploy aggregate JARs produced by the assembly plug-in.= Some things to consider:
1) A new POM will need to be created to reflect the contents of the aggr=
2) Do we want a standard name or classifier for these aggregate JARs, one s= tandard name might not be enough as different assemblies for the same proje= ct might contain slightly different things.
3) Do we want assemblies like this to be in their own builds? Right now the= J2EE JAR in the Geronimo build is like this whereas the assembly for the e= mbedder is part of the embedder build. Would separating the build make it e= asier to deploy? Maybe.
if this is done with a classifier or just a change in extension, then it w= ould 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 artifa= ct handler that blocks transitive dependencies to become a filter out depen= dencies 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-en= d. I think making a POM that actually represents what's in the JAR is a mor= e 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 an= ything 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 accur= ate make the POM up front. What if the assembly wasn't a complete closure o= f all dependencies? Then the artifact handler gets even more complicated, o= r we're hunting around in JAR for special hinting.
We have agreed on the mailing list that when new artifacts are created that= a new POM will be created to accompany it.