Hi guys, I'm trying to find the best place to put new logic for our upcoming Azure support. Since I'm starting with MSDeploy now, I had a closer look at the two obviously related web-app "styles" / types / lifecycles we "support".
Further down that leads me to general questions on how to structure functionality, types and lifecycles in NPanday. If you have no time to follow me through all the argumentation, just scroll down to "the current plan". But the plan should really be built upon the preceding arguments. So if you have new arguments to throw in that make us/me reconsider the plan, that would help me much more than just a general "that looks reasonable". Happy reading! maven-aspx-plugin introduces the packaging "asp" with extension "zip". It precompiles App_Code and Code-Behind-files for Web Applications and attaches both referenced binaries, the precompiled dlls and project artifacts in "./" using default EXCLUDES (excluding svn, etc). Available Integration tests: NPandayIT0012VBWebAppTest NPandayIT0013WebAppInstallTest NPANDAY_329_VS2010WcfProjectSupportTest NPANDAY_121_ResGenWithErrorInFileNameTest\npanday-9903 The project importer automatically imports "Web applications" with packaging type "asp". Please notice, that "Web application" is different from "Web project". Available project importer tests: MultipleFolderLevelTest\SubLevelWebApplication\SubLevelWebApplication WebSiteWithCSProj\WebApplication1 flat-multi-module-web-application-vb sample_web_project\SampleWeb A "Web application" is initially intended to be compiled on the web server, while "Web projects" are always compiled. With the aspx precompiler you can choose to compile "everything" including aspx-files, or just the App_Code, the Resources and Codebehind files. NPanday uses the latter, which is defined with the "-u" switch. After looking closer into it, I assume that the aspx-precompiler part in this plugin is totally unnecessary: since we (hardcoded) use the -u switch, it doesn't compile the aspx pages, but only all *.cs/*.vb files. -p disables access to IIS Metabase, -fixednames makes the dll-filename reproducible. The same can be achieved using our compile plugin by just including ./**/*.cs/*.vb as source. Hence I suggest to deprecate the plugin and supersede it with a more flexible packaging solution. More below. maven-webapp-plugin introduces the packaging "nar" (same file extension), which creates a plain zip file containing all files from src/main/webapp (with plexus default excludes) + all referenced dlls. Doesn't seem to have any support for GAC references. Already a year ago when I worked on it, it seemed that this plugin was out of service: NPANDAY-256: compile-plugin does not do a install for ArtifactType.NAR NPANDAY-256: Deprecate NAR type 1) We have no integration tests. 2) There are no unit tests. So I'd suggest to deprecate both the type and the plugin in NPanday 1.5.0-incubating. If not, we should unify the way dependencies are 'injected'. new functionality should be integrated in existing plugins when appropriate instead of just creating a new one just "exactly for what I need now" every time. But after looking closer into it it doesn't make sense to use maven-aspx-plugin or maven-webapp-plugin. These are the fragments of functionality I have to implement in context of NPANDAY-488: 1) Sensible default for selecting the files to be deployed along with the web application 2) Resolving of binary references (library, dotnet-library) from POM-dependencies 3) Some way of overriding/modify configurations deployed along with the web application. I'd prefer XDT (it supports XSL, too). We could also offer simple replacement configuration, where the user can configure a different *.config file to be used as web.config / app.config 4) Pack up the prepared web application with MSDeploy, and attach it as artifact. But this is not everything. We should take more things into consideration. a) 2) is not web-specific; it is something like a customized copy-dependencies that knows about our types, about configs, .pdb and .xml, and so on. b) 3) is not web-specific; it should also be available to other packaging types. c) 4) is not web-specific; although MSDeploy was targeted at Web Application, it fits as a package format for drop-in / xcopy-on steroids deployment for normal .NET applications too. Specifically if they run on servers and need to be installed automatically and headless. Then in addition, there are plenty of other packaging formats we should support over time, and which would most certainly make use of 2-4) I) Click once Package/Manifest II) Nuget Package III) Azure Cloud Service Package IV) MSI / WIX V) VSIX (Visual Studio 2010 Extension) VI) Normal "zero-config" zip distributions for Executables the question is, how to structure the functionality and code we add. Basically we have two extreme alternatives: 1) package/type centered plugins which provide both the functionality and the lifecycle for a packaging type. Pro: Everything "in place". Simple use. Contra: can easily lead to duplicate code! 2) tool-centric plugins which can be used explicitly, standalone, and or can be included by specific lifecycle-plugins. Pro: Tidy. Easier to communicate, since no true/false here and there changes "everything"; Contra: many plugins, and many goals, because each tool will have to provide different goals for different contexts they could be used in. Still there is much more :( At what detail should lifecycles be? Should they include packaging/deployment? Or should that be left to additional plugin configurations? That again leads to a new question: should the main artifact of a "compilable" NPanday project allways be *.dll or *.exe, and would we then add the packages as additional artifacts? the current plan, after having written all this, is: General principles * tool-centric plugins with simple goals that reflect the tools; plugins should not bind goals to phases! * dedicated lifecycle-plugins bind goals to phases * nar/zip shouldn't be the main artifact, if the project is compilable at the same time. * goals that create additional artifacts should be skipped/disabled by default Implementation of MSDeploy * create a msdeploy-maven-plugin which creates a package from a predefined, but configurable, prepackage-directory. * create a xdt-maven-plugin that offers transformation of config files and applies them to the same directory packaging plugins would pick up. * create a component that can resolve and copy dependencies known to npanday into some directory * create a new dotnet-webapp-lifecycle-plugin which does what compile-plugin does today + ** triggers the right plugins to prepare a web package by default (what sense would it make to build a web site if there are no plans to package it's contents somehow?) ** copies 'runtime'-dependencies into a bin directory of that web package ** includes disabled goals for maven-aspx-plugin which precompiles Sorry for this really long email... but that is, what I've been thinking over the last days. And I'd really like your feedback since I'm sure I haven't taken everything I should into consideration. yours, Lars
