On 30/11/2011, at 12:52 AM, Lars Corneliussen wrote: > The project importer automatically imports "Web applications" with packaging > type "asp". Please notice, that "Web application" is different from "Web > project".
I think I had an open issue to make pre-compilation optional - perhaps by requiring it be configured in the plugin, allowing us to drop the 'asp' type. > 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. Hmm, is that true? I thought -u *did* precompile, but also included the originals which could be modified? > So I'd suggest to deprecate both the type and the plugin in NPanday > 1.5.0-incubating. +1 I'd probably deprecate aspx and remove NAR (I doubt it is in use for the reasons you gave). Whether the precompile goal moves over depends on the answer to the above. From below, I see you have things that will supersede the copy-dependencies and package goals from that plugin. > > 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 I think this is right - it seems close to how Maven did it in Java. Generally, the "packaging" tool is the lifecycle plugin, but that doesn't quite exist in this scenario. However, I'd still keep functionally related lifecycles (like, all the aspnet lifecycles in an aspnet plugin, even if it uses goals from several other plugins) > * nar/zip shouldn't be the main artifact, if the project is compilable at the > same time. Makes sense - and assembly can equally do that. What would the main artifact be in each case? > * goals that create additional artifacts should be skipped/disabled by default Also seems to make sense - however this will be clearer to me when you enumerate them. Looking over this plan, it seems like a more significant readjustment of the plugins (long overdue!). Does this make it NPanday 2.0? Or did I misread your intent? > > 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 I like aspnet-maven-plugin better... and I hope that doesn't need to duplicate things from compile. Is that right? > > 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. Very helpful, thanks! - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
