[jira] Commented: (MNG-1452) best practices: deployment of aggregate JARs produced by the assembly plug-in
[ http://jira.codehaus.org/browse/MNG-1452?page=comments#action_50247 ] Brett Porter commented on MNG-1452: --- 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? best practices: deployment of aggregate JARs produced by the assembly plug-in - Key: MNG-1452 URL: http://jira.codehaus.org/browse/MNG-1452 Project: Maven 2 Type: Task Components: best practices Reporter: Jason van Zyl 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 aggregate JAR 2) Do we want a standard name or classifier for these aggregate JARs, one standard name might not be enough as different assemblies for 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 is part of the embedder build. Would separating the build make it easier to deploy? Maybe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1452) best practices: deployment of aggregate JARs produced by the assembly plug-in
[ http://jira.codehaus.org/browse/MNG-1452?page=comments#action_50275 ] Jason van Zyl commented on MNG-1452: 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. best practices: deployment of aggregate JARs produced by the assembly plug-in - Key: MNG-1452 URL: http://jira.codehaus.org/browse/MNG-1452 Project: Maven 2 Type: Task Components: best practices Reporter: Jason van Zyl 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 aggregate JAR 2) Do we want a standard name or classifier for these aggregate JARs, one standard name might not be enough as different assemblies for 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 is part of the embedder build. Would separating the build make it easier to deploy? Maybe. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
