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
Locked
