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 Bla.de.resx 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.