I transferred my web project from another laptop to another. Installed every jar files needed. But when i run the project, this error comes out.
C:\Users\user\Desktop\Inventory\Inventory\nbproject\build-impl.xml:1013:
Warning: Could not find file G:\Downloads
from Chrome\commons-fileupload-1.4-src.zip to copy.
BUILD FAILED (total time: 0 seconds)
Ive tried :
Could not find file mysql-connector-java-5.1.13-bin.jar
I have mysql connector installed on my libraries. So i tried Saumil answer. But i could not find the line in my build-impl.xml which is this:
copyfiles files="${file.reference.org-netbeans-modules-db-mysql.jar}"
todir="${build.web.dir}/WEB-INF/lib"
So since i couldn't find the line that Saumil suggested in my build-impl.xml, i have no idea how to fix this. I am not sure which line should i remove to fix this.
Fixed. All i did was clicking the blue link on the error line, and remove all "copyfiles files" line and rerun the project. Thanks :D
I'm on Windows. My Nitrous desktop app wont sync files. It says
"Error Warning the previous run of unison terninated in a dangerous state."
How can I fix this?
Thanks
The file transferring may not have completed properly. Try restarting the Nitrous Desktop app and try again.
If you run the app from the command line then you should see a full log message details on which files it is having issues with. If the app continuously displays this error then you may want to try removing the files which are causing the warning.
Here is a full explanation via Yahoo Groups:
There is a small window of danger while Unison is finishing
transferring a file, when the old file has been moved to a temporary
location but the new file has not been moved where it belongs. This
message is telling you that Unison got interrupted just at this moment
the last time it ran. You should check the file it's warning you
about, then delete the DANGER.README file and try again.
I'm running into a problem with a user not being able to push his commits into a Mercurial repository and am perplexed as to why it's not working for him. I've tried several things to figure out what's up, Googling doesn't turn up anything helpful... so here I am.
First, the configuration. We have a Windows XP SP2 x64 machine on our network acting as our official repository server. This contains several repositories on it. We clone / push / pull using a folder on that drive that is shared. Permissions are given to everyone for read access. Users that can push (including the user that has problems), are given full control. The user's machine is Win XP based. My machine (used to help troubleshoot things) is also Win XP based.
Second, the symptoms. The user is using TortoiseHg 2.1.1 to do his work. He can clone just fine, commits to his local repo are a-o-k, etc. When he tries to push, however, TortoiseHg returns a "abort, ret 255" code. Not very helpful. So, we've gone to the command line and have issued "hg push -v --debug". Here it returns "abort: Access is Denied". This same user can write to the server's shared folder no problem -- he can create files, directories and delete the same as well. So, reading / writing access the drive / folder is not an issue.
Third, our experimentation results. Here are some weird results from testing. The user created a new, local test repo. I logged into the server machine and created a test repo for him to push to. The user checked in a file and then pushed it up to the test repo on the server machine. This worked fine. No aborts. Life was good. He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message. Meanwhile, I can still update the project without any problems.
As another experiment, we had the user log out and another user log in. They did so and were able to push to the server repo without a problem. Original user logs back in, makes some changes, etc. and once again hits the brick wall of "Access is Denied".
As far as we can tell, the problem is not related to Windows credentials. Otherwise, we'd expect that creating arbitrary files on the server's shared folder would not work. Further, until I made an update to the test repo the user created, he could push to that particular repo just fine.
Any ideas? What additional credential checks is Mercurial making that might cause this?
UPDATE:
After a tip from Wim, I started to look at the permissions on the various objects of the repo using 'cacls'. This is a Windows tool that "displays or modifies access control lists of files". I had the user create a new repo and then took a snapshot of the permissions. I then checked in a file to the same repo and took another snapshot of the changes.
It turns out that there are several repo file permissions that get updated as a result of this: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, undo, and the single file of the repository. All of these files had permissions similar to the following:
C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
DOMAINxxxx\USERIDxxxx:F
BUILTIN\Users:R
(actual DOMAINxxxx and USERIDxxxx values have been altered). Prior to my check-in, DOMAINxxxx & USERIDxxxx reflected the user's domain and userid. After my check-in, these got updated to mine (we're on the same domain, but the userid is obviously different.) I was able to check things in and out even though my userid wasn't listed because I'm a member of the BUILTIN\Administrators group. The user with the problem is not. So, I'm guessing that after I checked things in, the system no longer saw him as a credentialed user with write-access (BUILTIN\User:R indicates Read-only access) and therefore caused the access denial.
I've got a terribly Q&D fix in place right now (user is now part of the Admin group...) The real fix is going to be to get the repo off of Windows Sharing and on to a proper server configuration.
He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message.
It sounds like your push creates or modifies files in the .hg folder in such a way that they are (or become) inaccessible for the other user.
I'm no expert on NTFS file permissions, but I think you can fix such situations by forcing all the content of the folder to inherit its permissions. Try selecting "Replace all child object permissions with inheritable permissions from this object" in the Advanced Security settings of the folder.
However, sharing the repository files directly with Windows file sharing is not recommended. You need a server process between the users and the repository files for the sake of performance, data integrity and security. Without such a gatekeeper, granting commit access also means granting the ability to destroy/corrupt the repository files (or as you found out in this case, changing their permissions).
See Publishing Mercurial Repositories on the Mercurial wiki for more information about other options.
When trying to commit on my locally cloned repository of a code repo on my network share, I was getting the same error message:
00manifest.i Access is denied
Probably overly simplistic, but removing some of the read only permissions to the offending files made my hg commit work fine.
I just had the same issue abort: Access is denied. The cause was my firewall (Privatefirewall) silently blocking some actions of hg.
I was getting exactly the same error message when trying to hg push at the windows command prompt. I'd recently received a new user profile after the old one had corrupted. I then ran into this "Access Denied" error. In TortoiseHg I received a similar message of "Aborted: Error 255".
I tried the advice given here by Wim Coenen as it seemed to fit; given my new user credentials. Eventually, I tracked the error to a badly installed Windows Git. It was only failing when I used repositories with git sub-repos.
In case others are having a similar problem with Git sub-repos:
Check that Git is installed correctly. I removed and re-installed it completely. (See: https://code.google.com/p/msysgit/downloads/list for latest version).
Ensure that the path to Git is in the path environment variable. (Right-click My Computer -> Advanced tab -> Environment Variables). Don't forget that some applications do not like windows paths with spaces in so you might need to replace "Program Files" with "PROGRA~1" (possibly "PROGRA~2" on 64-bit systems).
If you are using a proxy, ensure that HTTP_PROXY and HTTPS_PROXY in the environment variables are also set correctly.
Trying to configure Jenkins CI. Currently just running it from the .war (eventual intention as a service). Jenkins is aware of the CVS executable (i.e. will read the version [Concurrent Versions System (CVSNT) 2.0.62.1817 (client/server)]).
The .cvspass is not specified, because they apparently do not play nice with CVSNT (which prefers to keep passwords in the registry.) I've specified the password in the job config by using the :pserver:user:passg#server:/dir pattern for CVSROOT, which I found suggested in some places. Regardless of whether I run using that, or :pserver:userg#server:/dir as the CVSROOT I get the blinking red ball, jenkins stuck with a nearly full progress bar for 2 and a half minutes. It then fails. The console output yells with something like
FATAL: hudson.scm.ChangeLogSet.iterator()Ljava/util/Iterator;
java.lang.AbstractMethodError: hudson.scm.ChangeLogSet.iterator()Ljava/util/Iterator;
at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:282)
at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:279)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:596)
at hudson.model.Run.run(Run.java:1400)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)
Both CVSROOTs I'm using provide no trouble with TortoiseSVN. I've found some mention of difficult of logging into SVN from jenkins as a service and related user/system issues, but considering I'm running it from the .war I don't think that's the issue.
EDIT:
Interestingly the console log if I use an invalid user or password recognizes such.
cvs [checkout aborted]: authorization failed: server rejected access to /dir for user FOO
FATAL: CVS failed. exit code=1
Finished: FAILURE
which indicates that Hudson is talking to the CVS server and authenticating, but something else goes wrong.
/EDIT
Cheers
Answer to the question found, thanks to rpetti on #jenkins on freenode. Problem was I had switched between Hudson and Jenkins and there were some incompatible configuration files that were mucking things up. Deleting and recreating the home directory solved the problem.
CVSNT 2.0.62.1817 is very very old and has several known security issues. Please upgrade to the latest 2.8.01.
In the job configuration for a Jenkins 1.418 job (older versions are Hudson) on Windows, I am having trouble with "Archive the artifacts". In the box titled "Files to archive" I have
foo/**/Release/Install/App.exe
The error it gives me at configuration time is:
'foo//Release/Install/App.exe' doesn't match anything: 'foo' exists but not 'foo//Release/Install/App.exe'
Now, if I'm correct, ** is "search all subdirectories" as per ant. What is odd, is that no matter what I enter it tells me the top level folder exists (foo), but no other folder exists underneath it. Yet when I use the windows explorer to navigate, all my folders exist.
How can I troubleshoot this or fix it?
Update: I figured out a technique to troubleshoot - use the workspace browse features in hudson/jenkins to find what is visible and what is not visible. Turns out some directories had file permissions that blocked them being visible inside jenkins/hudson.
I had hudson configured to run a batch file, and my folder references were failing because of some errors in the batch files I was using. This was not a hudson problem, but a batch file problem. I saw the error and thought it was the problem because it was a reported error, but the real problem was a silent failure in a batch file.