[ 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
