incubator-npanday-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Kolotyluk <>
Subject Re: Tired of wagon
Date Thu, 29 Sep 2011 18:21:55 GMT
On 2011-09-28 6:34 PM, Brett Porter wrote:
> On 29/09/2011, at 4:04 AM, Eric Kolotyluk wrote:
>> OK, I did not have tlbimp.exe on my PATH, so I added it and made a little more progress,
but the build is still failing (see below).
>> I am not clear why there are complaints about missing assembly references. As far
as I can tell they seem to be there.
>> Part of the problems seems to be that P:\Intersystem\main\platform.NET\intersystem-service\target\
does not have the directory 28104638. Is this something that NPanday is supposed to create?
Is this because of the previous errors?
> That's a temporarily generated directory that is removed again when the build completes
(Even on failure). You'll need to look at the response file while the build is still going.
I think if you run with -X it might show you what it is putting into the response file, but
I'd need to check.
> Certainly something that could be improved on the npanday end to aid debugging.
> - Brett
> --
> Brett Porter
OK, I was finally able to get this project to build :-)

If you use -X flag then the temporary directory is left behind so you 
can inspect it. Nice feature.

Basically the compile was failing because of missing references. The 
error message was misleading because (I think) the temporary directory 
was being deleted too early due to the csc errors.  I had to add a Maven 
references for



The more subtle problem was a problem with one of the .dll files 
generated in another Maven project. The problem here is that for some 
reason the NPanday compile plugin insists on updating AssemblyInfo.cs, 
but if that file is under source control then it is read only and it 
fails to compile all the source files, however that actual build 
succeeds so while there is a .dll artifact created, it is incomplete. So 

 1. There seems to be a bug in the compile plugin where it is succeeding
    when it should fail.
 2. Trying to update AssemblyInfo.cs file is problematic with respect to
    source control. The plugin should not update this file, rather it
    should update one in the target directory. If there really is some
    reason to update files that are likely under source control, then
    the compile plugin needs to interact with the defined SCM.

Just one more .NET project to Mavenize...

Cheers, Eric

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message