I'm running an Ant target which contains this:
<ftp action="send"
server="${ftp.server}"
remotedir="${ftp.remotedir}"
userid="${ftp.userid}"
password="${ftp.password}"
systemTypeKey="WINDOWS"
binary="no"
verbose="yes">
<fileset dir="${dist.dir}">
<includesfile name="${temp.dir}/changedListText.txt"/>
</fileset>
</ftp>
"changedListText.txt" is a newline-delimited list of files to upload. All text files I upload end up having a size of zero. Also, all binary files I upload have a size that doesn't match my local machine's. I thought splitting the text and binary files would help, but apparently it didn't.
I can find precious little documentation on the Ant FTP task, and as far as Verbose is reporting, there don't appear to be any errors during the upload.
EDIT: I see now that it's only uploading whole chunks of 1024 bytes. My text files are small, so they're ending up rounding down to zero.
Your probably using Apache Commons Net 3.0. Change to 1.4.1 and it will work. Don't forget to remove the 3.0 jar.
The jar file can be downloaded from: http://commons.apache.org/net/download_net.cgi
Related
We are using TFS 2017 update 1 (on premise install). When I try to paste a large number of HTML tables and lots of text into the Description field, I get the following error:
TF401262: Value of long text field System.Description exceeds the maximum length allowed length of 1048576.
Can I change this limit ?
I had the same kind of necessity, so I tried a little bit harder...
This is my tfs database (Tfs_Dev):
I executed this procedure to add a registry value in TFS configuration:
EXEC [dbo].[prc_SetRegistryValue]
#partitionId=1,
#key='#\Service\WorkItemTracking\Settings\MaxLongTextSize\',
#value='2000000000'
I could find this solution after looking in TFS source code, thanks to a great tool named dnspy
You can find the specific TFS dll in a path similar to C:\Program Files\Microsoft Team Foundation Server 15.0\Application Tier\Web Services\bin\Microsoft.TeamFoundation.WorkItemTracking.Server.dll
Tested and cannot reproduce this issue on my side. But obviously it has the limitation for the maximum allowed length.
Generally String fields take a max of 255 characters. PlainText/HTML will take a max of 32K. If it crosses this limits, you can opt to store it to a file and add it as an attachment.
However you can try to change the limit by editing the web.config of the TFS site follow the instruction mentioned in this article : Easy Ways to Upload and Validate Large Files in ASP.NET
If you use IIS7 and you want to upload files larger than the
restricted 30000000 bytes or 28.6 MB, you can add the following code
to your web.config file in order to set that value to 100 MB:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="104857600" />
</requestFiltering>
</security>
</system.webServer>
If that still not work then please share the steps to reproduce the issue, especially for the "large number of HTML tables and lots of text" you mentioned (You can store the strings in a file e.g word if it's too large then share the file in Onedrive or another site we can access).
The project I'm working on has a stacktrace.log file that is over 160GB in space. This is killing my hardrive space. What can I do to avoid this.
You should use rolling file appender so that the log file does not grow that huge size.
Use configuration like:
rollingFile name:'stacktrace', file:'stacktrace.log',
maxFileSize:'100MB', maxBackupIndex:5
Here every log file will be maximum 100 MB. You can control how many previous file will be existed by 'maxBackupIndex'.
You can empty the existing huge file by(in linux)
cat /dev/null > /path/to/file/stacktrace.log
I don't want to include or make application.xml in ear tag
How can i off this parameter
<ear earfile="${builddir}/myapp.ear"
appxml="ear_deploy_descriptor/application.xml"
basedir="${builddir}"
includes="*.jar,*.war"/>
Please see earTask documentation at http://ant.apache.org/manual/Tasks/ear.html.
If you specify update="true" then the appxml attribute is not required.
A Java EE 5 application is not required to provide an application.xml file in the EAR file.
There seems to an issue with ANT when dealing with this. This was reported here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51761
Try using the jar task instead of the ear and it should work.
<jar destfile="${builddir}/myapp.ear"
basedir="${builddir}"
includes="*.jar,*.war"/>
I'm trying to use the native2ascii ant task but it seems that is not doing anything. Here's my ant task:
<target name="-pre-init">
<native2ascii src="src/com/bluecubs/xinco/messages" dest="src/com/bluecubs/xinco/messages/test"
includes="**/_*.properties"/>
<copy todir="src/com/bluecubs/xinco/messages">
<fileset dir="src/com/bluecubs/xinco/messages/test"/>
</copy>
<delete dir="src/com/bluecubs/xinco/messages/test" />
</target>
I did the copy part to see if it was an overwriting issue but the files come out exactly the same.
This is the output I get when running the task:
Converting 12 files from Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Copying 12 files to Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages
Deleting directory Z:\Netbeans\Xinco\2.01.xx\Xinco\src\com\bluecubs\xinco\messages\test
Edit:
Additional information:
OS: Windows 7 (but answer should work on any OD)
File encoding: Western (ISO-8859-1) obtained with this article.
Files location
Any idea?
native2ascii converts native characters like áéí to escaped unicode sequences. It means that á will be \u00e1, é -> \u00e9 and í -> \u00ed. After running native2ascii your files will be standard ASCII files which are more portable.
native2ascii does not touch the characters which are already in the escaped unicode form. Your properties files are already in escaped unicode form so it does not change anything. For example _XincoMessages_cz.properties contains this line:
general.accessrights=opr\u00E1vnen\u00ED k pr\u00EDstupu
It's escaped unicode. The nonescaped unicode form is this:
general.accessrights=oprávnení k prístupu
Wordpad vs. Netbans: When you open the properties files with Wordpad it opens it as a simple text file and shows \u00e1 as \u00e1. It does not convert it back to á. Netbeans does this conversion and you see the 'á' character. Furthermore, it writes it back to the disk as \u00e1 (!) when you save the file. To see the raw files use for example a Total or Double Commander which doesn't do any converting. (Note that Netbeans does this conversion just for properties files.)
If you put for example an á character to your _XincoMessages_cz.properties file it will be changed to \u00e1 if your run your ant task. Of course now don't use Netbeans for the editing, a simple notepad will do.
Loading properties files in java converts the escaped unicode characters to real unicode characters. An example:
final Reader inStream = new FileReader("..../_XincoMessages_cz.properties");
final Properties properties = new Properties();
properties.load(inStream);
System.out.println(properties.getProperty("general.accessrights"));
It prints:
oprávnení k prístupu
The ASCII/escaped unicode form in properites files is usually handled well by java applications. Finally, I think your properties files are good in their current format.
It ended being a view issue. Looking the files in a raw editor (i.e. Wordpad) showed that the files were already converted by the task. Viewing them from NetBeans shows them the same.
We're generating PartCover reports via the command line tool along with our CruiseControl.Net unit tests. This generates an xml file that displays the results nicely on the cruisecontrol dashboard. The xslt transforms that are included only show you the percentage of coverage in an individual class. We want to know exactly what lines are not being covered. The problem ist when we open the report in the PartCover browser and double click a method it doesn't show us our cs files. I know the PartCover browser is capable of showing you the files because of the following.
Here's a screenshot of PartCover browser with the lines of code showing: http://kjkpub.s3.amazonaws.com/blog/img/partcover-browse.png.
The information looks like it should be available to the browser because the report contains this:
<Method name="get_DeviceType" sig="Cathexis.IDBlue.DeviceType ()" bodysize="19" flags="0" iflags="0">
<pt visit="2" pos="0" len="1" fid="82" sl="35" sc="13" el="35" ec="14" />
<pt visit="2" pos="1" len="4" fid="82" sl="36" sc="17" el="36" ec="39" />
<pt visit="2" pos="5" len="2" fid="82" sl="37" sc="13" el="37" ec="14" />
</Method>
and this:
<File id="66" url="D:\sandbox\idblue\idblue\trunk\software\code\driver\dotnet\Common\AsyncEventQueue.cs" />
All I want to be able to do is view what lines of code are not being covered in my test cases without having to figure out what the xml above is trying to tell me.
Thanks to anyone in advance who replies.
I figured out why the cs files were not displaying. The paths were incorrect in the xml file because our test project was being built on a different machine than the one partcover was on. (partcover must generate the .cs file paths from pdb files maybe?) Once I search and replaced the file switching the base directory of our subversion location to the one on the other machine all was well.