[ http://jira.codehaus.org/browse/MNG-2369?page=all ]
John Casey updated MNG-2369:
----------------------------
Component: Multiple Language Support
> Generic 3rd Party DotNet Libraries not appropriately handled
> ------------------------------------------------------------
>
> Key: MNG-2369
> URL: http://jira.codehaus.org/browse/MNG-2369
> Project: Maven 2
> Type: Improvement
> Components: Multiple Language Support, Sandbox
> Environment: Windows XP
> Reporter: James Carpenter
>
>
> The csharp plugins work great when using .Net dependencies built with the
> csharp plugins, but don't work in the general case.
> Problem Statement:
> (Note: As a Java developer, I might mess this up a bit.)
> A .NET assembly contains a manifest which lists the assemblies it depends
> upon. In addition to checking digital signatures for public assemblies, the
> classloader (whatever MS calls it) expects the filenames of the dependencies
> to match that described in the manifest. The problem is the maven repository
> structure imposes a particular naming convention upon the artifacts placed
> within it. So you can't just take a third party dll change its name to fit
> into the maven repo artifact naming convention and create an associated POM.
> Artifacts built by maven using the csharp plugins match the maven repo
> artifact naming conventions and the assembly manifests contain dependencies
> whose names are consistent with the maven repo artifact naming conventions.
> Tatical Solution:
> The nasty tatical solution I am currently using, is to simple refer to any
> 3rd party dlls as system dependencies. (<scope>system</scope>)
> Potential Strategic Solution:
> I believe the solution is to create another maven artifact type to support
> 3rd party dlls. The artifact actually stored in the maven repo should be an
> archieve of some sort (jar, zip, etc.). During the process-resources (some
> phase prior to compilation, might need custom lifecycle) phase these 3rd
> party dependencies would be downloaded by the ArtifactResolver and
> unarchieved in some directory structure which maintains the versioning
> through directory naming, but not by file name. The dll filename would be
> the same as the original name of the 3rd party dll (most likely
> implementation choice is simply to let the archieve maintain the original
> name).
> When maven builds the classpath, any artifact of this new type would be
> represented in the classpath as the path to the unarchieved dll. (The
> current csharp compiler plugin sees these as the path to the local repo.)
> I believe, it will actually be necessary to produce two new artifact types.
> One will be used for "managed" dependencies and another for native
> "unmanaged" dependencies. This distinction is important because the csc (C#
> compiler) only wants to know about "managed" dependencies. (See as /resource
> arguments to csc compiler. Refer to plexus csharp compiler code for details.)
> I'm not sure my proposed solution is 100% accurate, as I still don't know the
> maven internals that well, but I think its close.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
