Water 2253 fails to resolve reference

Elements Water
1

This project works fine in VS2015 with elements 9.3.103.2211

Notice the leading slash in the path to this reference:
image

The file is at the specified location.

2

also, an underscore in a folder name is suppressed visually. The actual folder is c:\oxygene_test
image

Clicking Show in Explorer works fine.

3

Resolved the reference error by editing the project file manually from:

<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2">
  <Private>True</Private>
  <HintPath>\C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2.jar</HintPath>
</Reference>
<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-core-2.8.2">
  <Private>True</Private>
</Reference>

to:

<Reference Include="log4j-api-2.8.2">
  <Private>True</Private>
  <HintPath>C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2.jar</HintPath>
</Reference>
<Reference Include="log4j-core-2.8.2">
  <Private>True</Private>
  <HintPath>C:\java_libs\apache-log4j-2.8.2-bin\log4j-core-2.8.2.jar</HintPath>
</Reference>
4

Well, looks like this is as designed, if you actually have that bad path in the project?

5

Water is changing the project file.

I start with;

<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2.jar">
  <Private>True</Private>
</Reference>
<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-core-2.8.2.jar">
  <Private>True</Private>
</Reference>

then open water and it’s been changed to this, which does not resolve:

<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2">
  <Private>True</Private>
</Reference>
<Reference Include="C:\java_libs\apache-log4j-2.8.2-bin\log4j-core-2.8.2">
  <Private>True</Private>
</Reference>

build info shows:

  -> Target Cooper started.
     -> Task RemObjects.EBuild.Elements.ElementsResolveCooperReferencesForTarget started, Cooper.

E: Reference ‘C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2’ could not be resolved for target ‘Cooper’ (Cooper Plain jvm).
E: Reference ‘C:\java_libs\apache-log4j-2.8.2-bin\log4j-core-2.8.2’ could not be resolved for target ‘Cooper’ (Cooper Plain jvm).

6

References should not have extensions, so Water does clean that up for consistency yes (ie it removes the “.jar” or ".dll). Water didn’t add the bad slash before C:\ though, did it?

7

hmm. does the file exist at there exact path? The way references are supposed to work, Include=“” should have just the NAME, and there should be a <HintPath> subtag pointing to the file on disk, e.g.

<Reference Include="log4j-api-2.8.2">
  <Private>True</Private>
  <HintPath>C:\java_libs\apache-log4j-2.8.2-bin\log4j-api-2.8.2.jar</HintPath>
</Reference>

How did these references get generated to start with? manually? out by Water or VS via Add Reference?

I’ll see if I can improve EBuild to handle full paths w/o extension in the Include, as fallback. But the proper/clean fix is to make the references look like above.

8

Fixed for 2254 coming Friday.

9

Yes the file is at that exact path. This reference is what was created by using VS2015. I don’t think that I directly edited it, but perhaps I did at some point. However, it worked fine in VS

10

I have no idea where the initial slash originated. However, interestingly, this project also had another spurious “edit” show up from nowhere. In one of the .pas files, this showed up just prior to a closing semicolon:

{$IFNDEF oxygene}[80]{$ENDIF}

I thought that perhaps I’d accidentally hit some magic key combo to cause this insertion…

11

Yeah, EBuild has slightly different rules. I;ve fixed it to handle this scenario now.

hmm. this does not look like something we’d insert automatically. VERY strange.

12

My project file has most reference Include=“blah.jar” with the extension. However a couple do not have the extension. I believe all were added via the VS2015 IDE, not by editing the file.
eg:

True True C:\Program Files (x86)\RemObjects Software\Elements\Cooper\Reference Archives\com.remobjects.elements.rtl.jar True False True ..\..\..\..\Program Files\Java\jre1.8.0_25\lib\jce.jar True C:\MIRVsoft\out\artifacts\MIRVsoft.jar True True True ..\..\..\MIRVsoft\regex.jar True True True C:\Program Files (x86)\RemObjects Software\Elements\EUnit\Cooper\Plain\RemObjects.Elements.EUnit.jar True True
13

yeah, both of those are fine; Watere just cleans them jump for consistency. It’s the combination of full path + no extension that threw EBuild off…

14

Come to think of it, the one of my machines used to edit this project was using VS2017 for a while.

15

ok. b ut all is goof for yopu now, right? if so, I’ll ignore the extra \ issue and chuck it up to cosmic rays or whatever, unless it happens again :wink: