On 09/11/2012, at 12:38 AM, Lars Corneliussen <[email protected]> wrote:
> iirc i "forked" create-package to create-content-package and > create-iisApp-package > > create-content-package should be the "old" behavior… Right, so the options are: - update existing POMs (not a big deal, we haven't released it yet) - alias create-package to c-content-package - change c-content-package back to c-package - rather than fork the mojos, have a single one with a configuration parameter to determine the type Given the configuration arguments are the same, I'm inclined to do the last one - unless I'm missing something? The consistency in the name with azure-m-p is probably helpful. - Brett > > Am 08.11.2012 um 14:35 schrieb Brett Porter <[email protected]>: > >> Hi Lars, >> >> You might have missed this because of the original subject - any thoughts? >> >> On 26/09/2012, at 3:01 PM, Brett Porter <[email protected]> wrote: >> >>> Hi Lars, >>> >>> I'm looking into the test failures, and this commit broke the existing POMs >>> that referred to 'create-package': >>> >>> On 4 May 2012 17:18, <[email protected]> wrote: >>> Author: lcorneliussen >>> Date: Fri May 4 07:18:12 2012 >>> New Revision: 1333788 >>> >>> URL: http://svn.apache.org/viewvc?rev=1333788&view=rev >>> Log: >>> [NPANDAY-488] Packaging for Web Applications (also Azure Web Roles) >>> [NPANDAY-563] Generic MSDeploy synchronization mojo >>> >>> o support for iisApp packaging and deployment >>> >>> It seems to me that this could be better achieved by keeping >>> create-package, and adding a parameter to determine what the source >>> provider is, rather than subclassing the mojo (as the subclasses don't add >>> any different configuration arguments). Given that application-maven-plugin >>> and azure-maven-plugin both use create-package, the consistency might be >>> good to keep too. >>> >>> WDYT? >>> >>> - Brett >>> >>> -- >>> Brett Porter >>> http://brettporter.wordpress.com/ >> >
