incubator-npanday-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Query on usage of dotnet-archive
Date Wed, 27 Jul 2011 14:26:57 GMT
The dotnet-archive type doesn't do anything magic WRT the compile plugin or msbuild, as far
as I know. csc is getting confused when it is added to its command line because it expects
a dll.

I think what you might need to use is dependency:unpack (not unpack-dependencies), and list
them as artifactItems. This will still retrieve them remotely, but they are not POM level
dependencies that will get passed to the other plugins. However, I'm not sure if that helps
you get them onto the compile path as references - I'm not sure if/how others are doing that
or if they are just using these as a way to distribute some of the artefacts.

- Brett

On 27/07/2011, at 12:59 AM, Chris Whelan wrote:

> Hi all,
> I'm pulling in some .NET dependencies from an internal Artifactory
> repository which I'm trying to use in NPanday.  At first I thought this
> wouldn't be possible because the repository stores everything in .zip files.
> The group that owns the repo prefer to zip everything up due to storage
> constraints and the fact that they currently use this approach instead of
> NPanday (
> It's also a nice way of keeping the pdb and xml files alongside the DLL I
> guess.
> I'm planning to use NPanday for my app but I need to source some of my
> dependencies from their zip files.  Looking through the documentation it
> seems the dependency type 'dotnet-archive' is the way to go.
> My project is a WPF .NET 4 class library.  I've added a couple of
> dependencies of type 'dotnet-archive' to my pom file and they correctly
> resolve against the artifactory repo and pull down the necessary zip files:
> <dependency>
> <groupId>test</groupId>
> <artifactId>MyDependencyArchive</artifactId>
> <version>${archive.version}</version>
> <type>dotnet-archive</type>
> </dependency>
> <dependency>
> <groupId>test</groupId>
> <artifactId>MyDependencyArchive2</artifactId>
> <version>${archive.version}</version>
> <type>dotnet-archive</type>
> </dependency>
> but I'm getting this error:
> [INFO] --- maven-compile-plugin:1.4.0-incubating:compile (default-compile) @
> myapp-ui-components ---
> [INFO] NPANDAY-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version =
> 4.0, Framework Version = 4.0, Executable Paths =
> [C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319, C:\Program Files\Microsoft
> SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools]
> [INFO] NPANDAY-068-003: Compiling Artifact: Vendor = MICROSOFT, Language =
> MICROSOFT, Assembly Name =
> C:\Working\dev\myapp-ui\target\myapp-ui-components.dll
> [INFO] NPANDAY-068-005: Found executable path for csc:
> C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
> fatal error CS0009: Metadata file
> 'c:\Working\dev\myapp-ui\target\' could not be opened
> -- 'File is corrupt.'
> [INFO]
> ------------------------------------------------------------------------
> If I extract the zip file from my local maven repo it seems to be correct
> and contains a DLL, a PDB and an XML doc file.
> All I've done so far is include dependencies of type dotnet-archive and
> hoped it would 'just work'.  Is this the correct usage of the dotnet-archive
> type?
> In particular I'm only using the NPanday maven-compile-plugin.  This page:
> to suggest that the custom-lifecycle-maven-plugin may be required and
> that unpack-dependencies should also be used?
> I've attempted extracting the dependencies with this setup:
>                          <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>unpack-archive-resources</id>
> <phase>process-resources</phase>
> <goals>
> <goal>unpack-dependencies</goal>
> </goals>
> <configuration>
> <includeGroupIds>test</includeGroupIds>
> <includeArtifacIds>MyDependencyArchive,MyDependencyArchive2</includeArtifacIds>
> <excludeTransitive>true</excludeTransitive>
> </configuration>
> </execution>
> </executions>
> </plugin>
> But this seems to cause maven to get confused and start trying to resolve my
> other GAC dependencies (e.g. System.Xaml, PresentationFramework) from the
> repo.  If I remove this plug-in configuration these errors go away and
> System.Xaml and friends are correctly pulled from the GAC again.  I may be
> incorrectly configuring the unpack-dependencies goal in which case I
> apologise for my stupidity :).  I would have thought excludeTransitive would
> solve this but it doesn't seem to help, so I'm wondering if I'm using the
> wrong lifecycle phase as I assume this has to be run *after* NPanday pulls
> the zip from the repo but *before* the dependencies are passed into MSBuild.
> Does anybody have a good example of how this should work?  Will the
> dependencies be extracted from the zip automatically and passed to MSBuild
> by NPanday or do I have to include an unpack-dependencies execution for the
> dll's to be added as references for the compile phase?  Is process-resources
> the right stage at which to unpack?  How does the
> custom-lifecycle-maven-plugin help for this use case, do I need it?
> Many thanks,
> Chris

Brett Porter

View raw message