[ http://jira.codehaus.org/browse/MNG-2369?page=comments#action_67456 ]
James Carpenter commented on MNG-2369: -------------------------------------- The solution should also handle plugins which need to leverage such 3rd party applications. For example I have two plugins which use the plexus commandline utility to run a .NET utility. One plugin actually runs an in-house developed C# based tool. Since the in-house C# tool is built with maven, the plugin which uses it is able to automatically obtain the tool from the maven repo. This is done by following the lead of the jetty plugin as discussed at this blog: http://www.mortbay.com/MB/log/janb/?permalink=MavenRuntimeClasspath.html The other plugin does little more than use the plexus commandline util to run the C# xsd tool (similar to Jaxb). Unfortunately, the xsd tool doesn't fit the maven repo conventions (not without the feature this JIRA issue discusses). Consequently, the plugin must be configured with the exact location of the tool. This is obviously brittle. Furthermore, it means any workstation must install the dependency in a standard location. (Similar evil to a system scoped dependency.) > 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
