Message-ID: <1651616992.14538.1414300261602.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_14537_765204004.1414300261601" ------=_Part_14537_765204004.1414300261601 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:=20
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 aggre= gate JARs, one standard name might not be enough as different assemblies fo= r the same project 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 embedder i= s part of the embedder build. Would separating the build make it easier to = deploy? Maybe.
if this is done with a classifier or just a change in extens= ion, then it would complicate the system to create a new POM.
Is anything in the POM changed other than the dependencies?=20
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?=20
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 dependenci= es. 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 tr= ying to use the same POM really makes sense here. I would say do the leg wo= rk 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.=20
We have agreed on the mailing list that when new artifacts are= created that a new POM will be created to accompany it.