Its fantastic to finally see real movement in the maven csharp
suppport. I have been using a tweaked in-house version of the maven csharp plugins found in the maven SVN for 6months or so. (See JIRA issues submitted by nawkboy at: http://jira.codehaus.org/browse/MPA) In looking over the nmaven codebase a few questions came up. As I have not yet tried to actually use the nmaven plugins, there may still be a slight misunderstanding of what is going on. With great respect for the effort expended in developing the nmaven support, the questions/issues are: Design Questions: 1) Although there are several tagged versions of nmaven in SVN, the "getting started" instructions have the typical user build the plugins on their own desktop. I would expect released versions to be deployed to ibiblio (or another public mvn2 repo). Using a released version of a standard maven plugin requires nothing more than registering the plugin within a pom. Why should the nmaven plugins be any different? (Potential exception for the .NET framework.) 2) Why did you remove support for transitive dependencies? The nmaven site docs imply that nmaven intentionally removes support for transitive dependencies. Transitive dependencies are one of the best features of mvn2. From code inspection it appears you have solved the issues of version numbers as part of the dll names within the maven repo. (http://jira.codehaus.org/browse/MNG-2369, http://jira.codehaus.org/browse/MNG-2527) With this problem gone, non-public assemblies (unsigned) should be quite compatible with transitive dependencies. When resolving public dependencies it would of course be necessary to fail the build when inconsistent versions of the same library are discovered. 3) Does the nmaven resource plugin provide the same level of filter support available in the standard maven resource plugin? If not are there plans to refactor the standard resource plugin so as to push the relevant code into reusable utility classes which the nmaven resource plugin can then leverage? 4) I currently provide the build artifacts of my C# code (built using the tweaked maven csharp plugins found in the maven SVN) to another team which is not using maven. To do this I have configured the assembly plugin to create a zip file containing my top level dll as well as all of its dependencies (explicit and transitive) along with a configuration file or two. Will the assembly plugin still work with the new nmaven plugins? If not is there an alternative available? If an alternative is needed and not available, do you have any thoughts on how to best attack this problem? 5) How are you handling satellite assemblies? From maven's standpoint I'm sure one could treat them as attached artifacts, but the relevant plugins must obviously be smart enough to work with them. Design Recommendations: 1) The java builds derive much of their implicit behavior from the master parent pom burried in one of the maven jars. In working with the tweaked in-house versioned maven csharp plugins found in the maven SVN I soon ended up building a com.mycompany.csharp:maven-csharp-parent:X.X.X pom. My versioned maven-csharp-parent pom could then be used by a typical csharp build to easily get all the necessary plugins. This has been so useful, I think the nmaven project should provide the same sort of master parent with any versioned release of the nmaven plugins deployed to ibiblio (or alt.). Usage Questions: 1) I have several custom plugins which leverage code generators to produce C# code and/or resource files. Is there anything special I need to do to include generated source in a build artifact? My plugins producing C# currently just use the MavenProject to add the additional source directory. My plugins producing resources simply drop the output into special directories within the target directory. (See http://jira.codehaus.org/browse/MNG-2487 for details on how I currently handle resources.) 2) Although I have become proficient at developing maven plugins, I still don't have a great grasp of how artifact resolution is coordinated. The artifact resolver itself is conceptually quite straightforward. My problem is getting clarity on the interaction of the artifact resolver, MavenProject (which knows the transitive dependencies, etc.), and other core interactions which occur beneath a typical maven plugin. A few sequence diagrams which detailed a typical build would be very helpful in this regard, as would a few paragraphs providing an architectural overview of the topic. I noticed the nmaven plugins/components provide a custom repository layout, but didn't really understand it or how it would be used. (I am painfully aware of the requirement to enhance the repository layout to properly support .NET artifacts, just not sure where all the proper hooks are.) Can anyone provide some clarity here? (Say a wiki page?) Thank you for your time and effort in reviewing and answering these questions. Sincerely, James Carpenter jcarpenter621 Remove Spaces yahoo.com james.le.carpenter Remove Spaces jpmorgan.com |
Free forum by Nabble | Edit this page |