maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Porter (JIRA)" <>
Subject [jira] Moved: (MSANDBOX-26) Generic 3rd Party DotNet Libraries not appropriately handled
Date Mon, 18 Jun 2007 00:41:57 GMT


Brett Porter moved MNG-2369 to MSANDBOX-26:

    Fix Version/s:     (was: 2.2.x)
      Component/s:     (was: Multiple Language Support)
                       (was: Sandbox)
              Key: MSANDBOX-26  (was: MNG-2369)
          Project: Maven 2.x Sandbox  (was: Maven 2)

> Generic 3rd Party DotNet Libraries not appropriately handled
> ------------------------------------------------------------
>                 Key: MSANDBOX-26
>                 URL:
>             Project: Maven 2.x Sandbox
>          Issue Type: Improvement
>         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
> 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:
For more information on JIRA, see:


View raw message