[ http://jira.codehaus.org/browse/MNG-2369?page=comments#action_67412 ] 

James Carpenter commented on MNG-2369:
--------------------------------------

To: dev@maven.apache.org
Subject: MNG-2369: Generic 3rd Pary DotNet Libraries not appropriately handled

I am actively using the maven csharp plugins in the maven plugin sandbox.  Of 
the bugs I have reported (MNG-2367, MNG-2369, MNG-2370, MNG-2371) by far the 
most painful for me is "MNG-2369: Generic 3rd Pary DotNet Libraries not 
appropriately handled" found in JIRA at: 
http://jira.codehaus.org/browse/MNG-2369.

I hope to have time to tackle this problem in a week or two, and would 
appreciate any feedback you can give regarding my proposed solution.  Any 
pointed feedback on the following will be particularly useful:

1) Which class/plugins will be affected (I have an idea, but probably missing a 
few)
2) Which pre-compile phase is best for my artifact pre-processing?
3) Whether a custom lifecycle should be used. (It seems I should really do the 
artifact pre-processing between the process-resources and compile phase of the 
default lifecycle)
4) The best choice for placing the pre-processed artifacts.  (Should this be 
another directory alongside ${user.home}/m2/repo whose location is governed by 
the settings.xml file?)

If convenient please attach your feedback as a comment on the JIRA issue.

Thank you for your time and effort spent reading and replying to this email.

Sincerely,
James Carpenter
email: [EMAIL PROTECTED]

> 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: 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

Reply via email to