This project is read-only.

Four NPanday Execution Modes (Different Conventions)

Mar 5, 2010 at 8:42 AM


i think it is hard to get everybody and all project structures handled with only one set of conventions.

Here is what I suggest:

1. alternative: Though this is the currently implemented Style it is an alternative approach to what the normal structure is in .NET projects.

  • Source files from 'src/main/csharp'
  • Resource from 'src/main/resources'
  • Test source files from 'src/test/csharp'
  • Test resources from 'src/test/resources'
  • AssemblyInfo.cs is generated from POM if not exists
  • resx files are compiled and linked
    • culture-specific resx get compiled into satelite assemblies
  • ??

2. default: Following the ALT.NET / Microsoft conventions. They are not as strong as in java, but there are some.

Tests are usually held in a Test or Tests folder within the same project, or in a sibling project called as the tested project + .Test(s).

  • All source files get compiled (exclude Test(s)??)
  • resx are included by default
    • if the resx have locales they are linked into a satelite assembly
    • neutral-culture resx also get compiled as sources with resgen /c
  • Other resources/folders have to be included in the pom manually
  • Tests are resolved automatically
    • if a folder Test or Tests exists these are taken as test-files
      • resources within the Test(s) folder are only linked when testing
    • the test-project pom is resolved via naming conventions and built + executed in the test-lifecycle step of the project beeing tested
      • alternatively the test-pom can be specified
  • The AssemblyInfo.cs is patched with the version from the pom.
  • ???

3. integrated or msbuild: The proj-files are the leading resource.The pom file is generated ad-hoc or at least a minor resource. Maven 3 supports groovy, we support msbuild :-)

Some more comments, before elaborating on the conventions: MSBuild is actively developed and we can hardly clone everything they do. I would therefore copy the project including the proj-files and then patch it with more information. The references can be rewritten to maven refs. And other conventions could be applied by a custom xsl or so.

  • POM files are optional, but if they contain very little information
  • The pom file is generated/patched from the csproj
    • The group ID can be specified with a custom assembly-attribute in AssemblyInfo
    • The group ID from referenced assemblies is inferred as follows:
      • Try to find the project or dll and see if it has a NPanday.GroupIdAttribute compiled with it
      • Try to resolve it from remote or local repositories by publikKeyToken (usually unique to one groupId) and the artifactName
      • Infer it from the artifactName (First namespace-hop? NHibernate, log4net, xunit, NUnit, ... matches most projects!)
  • The compiler uses msbuild, not csc
  • ... you get the idea

4. hybrid: The POM is leading for metadata, but the information about resources and sources is retrieved from the csproj

You get the idea. Just copy all Compile-filesets from MSBuild to sources and all EmbededResource filesets to embedded resource. ...

If you think this is interesting we could work on specifying those in a wave, the wiki or google docs instead of discussing every thing in a long confusing thread.

Mar 9, 2010 at 1:54 PM