I'm using Windows and I'm trying to get ANT to work.
When I do an ant build from the command line, I get:
C:\dev\Projects\springapp\${%ANT_HOME%}\lib not found.
I look into the build.xml file and I find:
appserver.home=${user.home}/apache-tomcat-6.0.14 (which I just copied and pasted straight from a tutorial)
I changed it to:
appserver.home="C:\Program Files\Apache Software Foundation\Tomcat 6.0"
but now I get:
C:\dev\Projects\springapp\"C:Program FilesApache Software FoundationTomcat 6.0"\lib not found.
It seems like the white space in Program Files and Tomcat 6.0 are causing the build to fail. How do you deal with these in xml files without re-creating the directory with a path with no white space?
Change it to
appserver.home="C:\\Program Files\\Apache Software Foundation\\Tomcat 6.0"
Variant with "/" instead "\" works on my system. Just need to delete " symbols before and after path structure.
Find the Windows short name for those directories using dir /x and use thme when setting path values.
Some more discussion at How does Windows determine/handle the DOS short name of any given file?
It looks like you have your properties setup incorrectly.
I'm guessing your basedir property is pointing at C:\dev\Projects\springapp and your properties are using value like:
<property name="property.1" value="directory" />
instead of
<property name="property.1" location="directory" />
Using the location property then resolves links as relative to your basedir if the location is a relative path and to the absolute path if you enter one of those. If you could post parts of your Ant file specifically how you define appserver.home and how you use it in the task that's throwing the error I could be more specific.
In addition to escaping the windows directory separator also make sure that all paths that you type in should be with correct capitalisation, Windows is not case sensitive but case presrving, while Ant is case sensitive.
In the top of your build.xml, try adding
<property environment="env"/>
and then using ${env.USER_HOME} (or whatever you have in your environment). That did it for me (${env.JAVA_HOME} rather than ${java.home}).
Related
Why would the file run with no problems when using Eclipse but when I create a jar file of the same program I can't run it locally on my pc?
This is the error I get where a is an input and signal.pl is a file I pass located in Desktop:
C:\Users\HP\Desktop>java -jar ADE2.jar a signal.pl
Exception in thread "main" org.jpl7.PrologException: PrologException: error(existence_error(source_sink, a), _0)
at org.jpl7.Query.fetchNextSolution(Query.java:438)
at org.jpl7.Query.hasMoreSolutions(Query.java:342)
at org.jpl7.Query.oneSolution(Query.java:872)
at org.jpl7.Query.hasSolution(Query.java:950)
at ADE.executeGorgias(ADE.java:19)
at ADE.main(ADE.java:41)
I assume that you have two different working directories in your two scenaries.
SWI-Prolog provides the working_directory/2 predicate in the form of working_directory(-Old, +New).
As the documentation states:
Unify Old with an absolute path to the current working directory and change working directory to New. Use the pattern working_directory(CWD, CWD) to get the current directory.
Thus, I would suggest to test working_directory(CWD, CWD) in both cases to see if your working directory differs, which may lead to probelms when working with relative paths.
Edit: You can also use absolute_file_name/3 to ensure that your "Eclipse use case" and your "jar use case" resolve the file in the same way.
In maven set path to chrome driver as:
<driver.chrome>${project.basedir}/../repo</driver.chrome>
As result path is: D:\MyProj\..\repo
Answer: driver.chrome>file://${project.basedir}\..\repo</driver.chrome>
OK, I think I understand what you're asking. The resulting path you're getting is not minimized, but as far as I know, it is a valid path and it would work on any operating system.
In other words - D:\MyProj\..\repo is valid and equivalent to D:\repo. Go ahead and try to paste it into Windows Explorer and see if it opens it. Or cd to it in command prompt.
I have an XNA project that's hosted and shared with another user via a Dropbox account. When I try to build, it fails with this error:
Unable to copy file "D:\Documents\Dropbox\Super Mario Limitless\SuperMarioLimitless\SuperMarioLimitless\bin\x86\Debug\Content\m_norm.xnb" to "bin\x86\Debug\m_norm.xnb". Could not find a part of the path 'D:\Documents\Dropbox\Super Mario Limitless\SuperMarioLimitless\SuperMarioLimitless\bin\x86\Debug\Content\m_norm.xnb'.
It seems to be trying to pull a file out of the other computer's path, which clearly doesn't exist on this computer. I've traced it down (roughly) to a file called ContentPipeline.xml in $(SolutionFolder)\SuperMarioLimitlessContent\obj\x86\Debug\
<Item>
<Source>m_norm.png</Source>
<Name>m_norm</Name>
<Importer>TextureImporter</Importer>
<Processor>TextureProcessor</Processor>
<Options>None</Options>
<Output>D:\Documents\Dropbox\Super Mario Limitless\SuperMarioLimitless\SuperMarioLimitless\bin\x86\Debug\Content\m_norm.xnb</Output>
<Time>2012-12-06T21:47:30-05:00</Time>
</Item>
Now, I can change the paths to my own, and it will work for me but not for him. I tried changing them to relative paths, but it doesn't seem like whatever's loading this file will parse relative paths, nor does it work with $(SolutionFolder) or $(ProjectFolder), instead interpreting them literally.
The two content files in question are both set to "Build Action: Compile" and "Copy to Output Directory: Copy Always".
So, is there a way to fix this, or is this a sign of deeper problems?
Thanks in advance.
I am using WiX 3.5 and making an installer. I have used heat.exe to bundle all the files.
It produced a WiX file. I referred in main wxs files as componentgroup ref. When I build my installer, it throws the following exception.
light.exe : error LGHT0103 : The system cannot find the file
'..........\target\tmp-release\jboss-eap-5.0\jboss-as\server\all\deploy\httpha-invoker.sar\invoker.war\WEB-INF\classes\org\jboss\invocation\http\servlet\ReadOnlyAccessFilter.class'
with type ''.
It is able load many files from this location, except the above file, even though the file is present.
Looks like you've hit the linker bug. As far as I can see, it was already reported to the WiX team, and was scheduled for v4.0. The comment to the issue states the path is more than 255 characters, so a possible workaround for you is to re-work the files/folders layout to avoid the paths of that length.
Hope this helps.
The answer of Ravz1234 works ! I used it with a environment variable e.g. env.SourcePath.
1) Set an environment variable to show on your Source Dir e.g. C:\SourceDir
2) On heat.exe add the argument -var env.SourcePath along with the other arguments
I used the variable for the directory, sys.SOURCEFILEDIR, and it worked well.
For some reason, I can't seem to get CruiseControl.net to checkout code to anywhere but the starteam working folder for a specificed view.
I've tried both overrideViewWorkingDir and overrideFolderWorkingDir, and neither seem to work.
Has anyone been able to do this?
Are you looking for the project's workingDirectory element instead of the starteam override?
<sourcecontrol type="starteam">
<executable>C:\Program Files\starbase\StarTeam 5.4\stcmd.exe</executable>
<project>ProjectName/ViewName</project>
<username>UserName</username>
<password>Password</password>
<host>127.0.0.1</host>
<port>49201</port>
<autoGetSource>true</autoGetSource>
<overrideViewWorkingDir>C:\temp\ProjectName</overrideViewWorkingDir>
</sourcecontrol>
Works fine for me with ccnet 1.4.3 and Startem Cross-Platform Client 2008 R2. Make sure XML is valid. I had overrideViewWorkingDir tag not properly closed and ccnet was ignoring it. Found it by running ccnet.exe from the command line instead of as a service. Also you can use Process Explorer from SysInternals to view command line arguments passed to stcmd.exe
Make sure your working folder properties are set to a relative and not a full path (ex: MyFolder instead of C:\MyProject\MyFolder) or it will override the override. I've seen files checked out to some very odd places in the past when people mistakenly put in full paths when adding a folder to a view.