I used a very basic build file taken from the sample configure-was-derby.xml:
<property name="worklight.server.install.dir" value="C:/Worklight70"/>
<property name="config.migration.tool.enable" value="true"/>
<target name="minimal-update">
<updateapplicationserver id="" contextroot="/AreaClienti">
<project warfile="C:/temp/AreaClienti.war"/>
<applicationserver>
<websphereapplicationserver installdir="C:/WebSphere85/AppServer"/" profile="AppSrv01" user="wasuser" password="xxxxx">
<server name="server1"/>
</websphereapplicationserver>
</applicationserver>
</updateapplicationserver>
</target>
Recently I was able to reproduce the issue on my laptop installation and I believe I found the cause: please review the following analysis and confirm the results.
I originally installed the war file manually from WAS admin console, and when I run the Ant minimal-update with the above build file it failed with the mentioned error
The MobileFirst Project WAR file is not currently deployed in the WAS
profile at ...
Then I removed the manually installed war file and reinstalled it using Ant install target.
At this point the minimal-update run successfully.
I found out that the Ant installation created into WAS config structure
profile_root/config/cells/cell_name/nodes/node_name/servers/server1
a new Worklight directory containing the worklight-jee-library.jar file and a derby subdir with the derby driver jar.
Apparently the minimal-update Ant task makes a preliminary check on the existence of the Worklight directory and it fails if it's missing.
Can you please confirm that this is true ?
Of course the Worklight directory is not created by the standard WAS installation process.
So, after a console installation of the runtime war the Ant minimal-update always fails!
If I manually add the Worklight dir in WAS config, then the Ant minimal-update starts running just fine.
IMHO, altering in such way the standard WAS config structure is not very clean.
Said that, is it a valid workaround in case we initially install the runtime war with standard WAS admin procedures ?
Furthemore, also the returned error message could have been a bit more clear: please let me know if there is any debug option to make the Ant tasks more verbose.
At last, let me ask one further question.
I noticed that the Ant execution writes log files in the directory
user_root/.mobilefirst_platform_server
Is there any way to redirect those logs into a different dir to avoid the risk of filling up the user root ?
Apparently the minimal-update Ant task makes a preliminary check on the existence of the Worklight directory and it fails if it's missing. Can you please confirm that this is true ?
That's correct.
Is there any way to redirect those logs into a different dir to avoid the risk of filling up the user root ?
Unfortunately not.
Related
I have a project with different modules bundled into each others.
We build with ant and I have no problem running the Ant build inside Intellij if I provide the path to the generic build files through a property (repository.dir : C:/myRepositoryFolder).
Similarly, I have no problem running my ant build in command line given I have set my environment variable ANT-OPTS with -Drepository.dir=C:/myRepositoryFolder
However, Intellij does not know where to find this folder and therefore the inspection 'Ant inspections / Ant references resolve problems' blow off on most of my build.xml.
Does anybody know where I can show Intellij where to find this folder without modifying my existent build.properties?
Thanks in advance!
I'm running an ant build through Jenkins and on the stage where it is deploying to windows-share its returning the following error:
Failed to copy FILE to FILE2 due to failed to create the parent directory for FILE2 (I've taken the paths out to keep the question shorter).
I'm guessing that there might be some problem with permissions with the jenkins default user but this problem has only just started occurring, and any help would be great.
Thanks
This is a pretty old question but I thought I'd come back and complete it with a short update as to what was actually going on. Someone had changed the password for the user that was logged on to the vm that jenkins was running on, and when it was trying to create the directory to stick the files into it was running into permissions errors. Only problem was the error message wasn't very descriptive.
So in the end this was an infrastructure problem rather than anything to do with the ant script.
I take it you're doing something like this:
<copy file="${from.dir}/${from.file}"
tofile="${to.dir}/${to.file}"/>
And, you're getting an error that ${to.dir} doesn't exist.
In earlier versions of Ant, you definitely had to create the directory before doing a copy:
<mkdir dir="${to.dir}"/>
<copy file="${from.dir}/${from.file}"
tofile="${to.dir}/${to.file}"/>
I think I also noticed that later versions of Ant will create the directory for you when that directory didn't exist. I've always been in the habit of putting <mkdir/> in front of any task that creates a new file in a new directory, including things like <zip/> and <tar/>.
Here are some questions:
Do your users also use Ant to run their builds? I know that this isn't always the case. Many users use Eclipse and don't bother with Ant.
Is the version of Ant your users have vs. what your users have the same?
Do you do a clean? Jenkins can emulate a clean either by doing an update, reverting and removing unversioned element, or by simply creating a brand new working directory. If your users don't remove the destination directory where ${to.file} is being placed, it might work locally, but not on Jenkins.
Can you manually run Ant from the Jenkins working directory. If so, what results do you get? (Remember to disable this Jenkins job before doing this. You don't want Jenkins to do a build while you're experimenting in the working directory.)
I have tried to run a example from the website http://confluence.highsource.org/display/J2B/Annotate+Plugin#AnnotatePlugin-Activation. The very first schema provided in the webpage and I saved it as schema.xsd under c:\jaxb folder. Then, I ran the command 'xjc -extension schema.xsd' from command prompt and I get the similar error. Apparently xjc doesn't seem to understand this url http://annox.dev.java.net. How do I solve this?
You have to add the annotate plugin with all the dependencies to the classpath. See this Ant build file for what dependencies are
You have to activate the plugin using -Xannotate switch
Here's a sample Ant project. I'll assemble a command-line example for the next version.
I am trying to use the Ant <scp> task in my buildfile. It gives me an error every time I run the target:
cannot be found: com/jcraft/jsch/UserInfo
I have read some posts that talk about having this issue with Ant 1.7. Some of the posts are talking about removing the ant-jsch.jar files from the ant_home lib. Unfortunately I can't do that as the ant_home is common across lot of other projects and I can't remove or update any jar files from the lib directory.
Is there a way that I can solve this issue purely using Ant configuration?
ant-jsch.jar contains ssh related tasks developed by Apache Ant team, while jsch.jar contains the jsch library which is the dependency of those ssh tasks.
So do a little check: check if jsch.jar is in your $ANT_HOME/lib and also check if the jar contains UserInfo.class.
If one of above happens, download the latest version of jsch.jar and put it in $ANT_HOME/lib.
I am currently using Ant 1.8.4 with a jsch.jar downloaded last year without any problem.
Update:
Check this page first:
http://ant.apache.org/manual/install.html#optionalTasks
Please note that <scp> and other ssh tasks (the ant-jsch.jar) are included in the Ant binary distribution by default. You don't need to write <taskdef> to use <scp> because it is included in Ant's lib directory by default. I recommend you to put jsch.jar in that directory with the following points:
These ssh tasks don't support classpath def, that is to say, you can't define a <classpath> pointing to jsch.jar and then reference to it in an ssh task.
Also you can put jsch.jar in any directory included in your system's CLASSPATH environment variable, but it is not a good practice.
We usually put a task and its dependency in the same directory.
all
I'm trying to deploy Nutch1.4 to Hadoop cluster(following this page). I got some problems when compiling Nutch with ant.
problem 1
When I run ant command, I got the following error:
/home/xenserver/apache-nutch-1.4-bin/build.xml:71: invalid Date syntax in "01/25/1971 2:00 pm"
I remove attribute "datetime" from line 71 in file build.xml and run ant again. Then I got another problem.
problem 2
The error is:
/home/xenserver/apache-nutch-1.4/build.xml:412: syntax errors in ivy file: java.text.ParseException: http://java.sun.com/xml/jaxp/properties/schemaLanguage in file:/home/xenserver/apache-nutch-1.4/ivy/ivy.xml
at org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:273)
........
What's wrong with the steps above? Is there any tutorial for compiling Nutch1.4?
Need your help.Thanks in advance.
For compiling nutch 1.4, all you have to do is run ant clean deploy from the nutch directory. The output is created in the directory named 'runtime' with 2 folders: one for local mode and other one for cluster mode.
please check the date settings and ant installation on your machine. I think that is casing the issue. Also have you tampered/ edited /home/xenserver/apache-nutch-1.4/ivy/ivy.xml ? Please check that file too.
EDIT:
There is some problem with the build file when executed on your Linux box.
Check these out: this and this.
These are the things that you should verify on your setup:
java version and ant version : dont use old ones. get the latest ones or ones that are compatible with your nutch release. FYI: for nutch-1.4 I am using apache-ant-1.8.3 and java jdk1.6.0_18. This combination works perfectly fine with me.
Check that you have installed a JDK and not a JRE
Check if your JAVA_HOME environment variable point to the JDK. System PATH variable must have $JAVA_HOME/bin and $ANT_HOME/bin appended to it. ANT_HOME variable must point to the ant installation directory.
Can you successfully run normal ant targets on any other build files ? try out with small ant build file.
Still facing the same issue, run ant command with -v option. This will provide more information about the error faced.
eg.
ant -v clean deploy