I am receiving the below error when I'm trying to build the solution file from MSBUILD.
I'm building the solution file from ClearCase integration stream .
When I do the same from a different system it works fine on the integration stream.
I have tried creating and writing the file into the N/W drive & it works fine.
But when I build it through CruiseControl it is throwing the following error.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3041,9):
error MSB3491:
Could not write lines to file "obj\DAL.csproj.FileListAbsolute.txt".
Access to the path 'M:\yj73_SRDV3G_Proj_01_00_int\SRM_COMP\SRDV3G_Project\CRDB_V3\Application_Source\DAL\obj\DAL.csproj.FileListAbsolute.txt' is denied.
Two usual causes:
The CLEARCASE_PRIMARY_GROUP environment variable is incorrectly set and don't reference the primary or secondary group of the Vob \SRM_COMP (see cleartool descr -l vob:\SRM_COMP for a list of those groups)
The path is somehow not selected by the current config spec.
It is best to do a cleartool ls in M:\yj73_SRDV3G_Proj_01_00_int\SRM_COMP\SRDV3G_Project\CRDB_V3\Application_Source\DAL to see how ClearCase displays obj.
The OP user1383839 confirms not using the right account for the Build Loop, which means it didn't benefit from the right environment variable, hence the "access denied" message.
Or you can also "runas" the project as a different user (see "Running cruise control.net under different credentials")
This issue got Fixed !:)
I was using the local account Previous
you need to go to the properties of the cruise control and change the account it is being used.
Related
I'm working on 2 different machines (home vs. work) and transfer the code via GitHub, which works nice, but I just ran into a machine dependency when I added this code to the gradle.properties file to fix a vexing OAuth issue for google sheets:
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_131
org.gradle.java.home=C:\Program Files\Java\jdk1.8.0_77
Now I have to toggle between the 2 lines to get Gradle to compile. Need to check if I still need it (since I got the keystore files etc. sorted out), but I also wonder whether there is an easy solution to make this work (e.g. something like ifdef).
Obviously, I could just change the directory name in one of the machines I guess, but still curious how to solve this within Studio.
Lets start with a quote from the Gradle docs:
org.gradle.java.home
Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, jdk is safer. A reasonable default is used if the setting is unspecified.
So, by default, you should not need this project property (thats what they are called in Gradle).
However, there can be reasons, that you need to specify the Java directory. For this specific project property, you can follow Ray Tayeks advice and use the JAVA_HOME environment variable (on both systems). But there is also another approach, which can be used for any project property (and also for so-called system properties):
gradle.properties files can be located at different locations of the file system. Your files are located in the project directory and, therefor, they are included in your VCS. You can use them / it for project-related properties. An additional location is in the Gradle user home directory, which is by default the .gradle folder in your personal folder. This folder is not under version control, so simply define the property there.
try removing the line from the properties file. if that fails, try setting JAVA_HOME on each machine.
there are a lot of related questions.
you might try asking on the gradle forums.
any one know how can I get current path of eclipse workspace programmatically. Since this path changes in every computer I want to get this thing programmatically and dynamically. It should return a string and it should be like ersin/projects/proj/my_work_space_name.
by the way this code didnt work for me:
ResourcesPlugin.getWorkspace().getRoot().getLocation().toString()
it gives ersin/projects/proj/runtime-EclipseApplication whereas it should be ersin/projects/proj/my_work_space_name.
It looks like you're getting that value because you're running a test environment for debugging a plugin. When you do that, you're effectively running a different workspace and that's why you're getting the root location of that workspace. Should you get to the point where you run that plugin in your original development workspace, you'll get the value you expect.
In short, you are getting the current path of the eclipse workspace.
So if you're trying to debug a plugin that searches the workspace, you'll need to add projects to your test workspace so that the search can take place there.
I have an Informatica workflow that is supposed to generate a .dat file.
The issues is that the wroflow creates a 0 byte file, but then can not write to the file it JUST created. It's baffling.
The target directory is a linux server, and there is a developer on our team that is able to run the workflow just fine, without this file-writing issue.
However, I have checked with our linux admins and several of them have confiremd that there is no major difference in access/permissions between her linux ID and my own. She is in two more user groups than I am, but I have been told that they would not have anything to do with this issue.
The ID used by the connection object is also in the same user group as my id on the linux server, enduser. Therefore it should be able to write to my home directory.
The workaround we have devised is to remove the files using my id, touch the files and then chmod them. This allows the id used by the Informatica connection object to write to the files, but it is not a permanent (or correct) fix.
My best guess is that this is most likely some sort of (very obscure) Linux environment issue.
I am also not able to make any changes to the Informatica workflow or mapping, since it is built correctly and this issue appears to be completely local to certain linux user ID's.
Does the etluser have write permissions? have you tried running a post session command script for chmod and giving full permissions and then writing into the file?
Hi have an application running separateley (1 instance for customer) in different folders, 1 per each customer.
Each customer is a separate user on my machine.
At the moment I have the source code in each of these folders where I rebuild the code per each instance. Would it be better if I do something like the following?
create a shared folder where I build the code
deploy the binary in each user folder.
allow permission for each user to access the source code in READ ONLY mode.
when it is time to debug, by using gdb in each user folder will allow to read the source code and debug will happen.
Do you think that this could be a better approach or there are better practice?
My only concern is that each user has the chance to read the source code, but since the user will not access directly his folder (it is in my control) this should not trouble me.
I am using CENTOS 6.4, SVN and G++/GDB.
in different folders
There are no "folders" on UNIX, they are called directories.
I rebuild the code per each instance
Why would you do that?
Is the code identical (it sounds like it is)? If so, build the application once. There is no reason at all to have multiple copies of the resulting binary, or the sources.
If you make the directory with sources and binaries world-readable, then every user will be able to debug it independently.
When I start the JBoss server to run my JSP page, it gives the error as:
Failed to create directory structure: C:\Program Files\jboss-4.2.2.GA\server\default\log
and then a pop-up appears saying
Starting JBoss v4.2 at localhost has encountered a problem.
Server JBoss v4.2 at localhost failed to start.
Please tell me what to do?
When starting for the first time for a certain configuration (here being default, if they are not already present, JBoss creates the directories:
$JBOSS_HOME\server\default\data
$JBOSS_HOME\server\default\log
$JBOSS_HOME\server\default\tmp
$JBOSS_HOME\server\default\work
These are used to store and write logs, temporary files and other various files generated.
There is obviously an error when it tries to create the log folder and this is most likely because it does not have permissions to write and create folders. ( Though you would get this every time since JBoss likes to write a lot of logs all the time ).
In Windows Vista/7, the Program Files folder is not (usually) write-able, so an application started by the user cannot create or modify anything there. You could run JBoss as Administrator but DON'T, it's a bad idea. All files which need to be created/modified by an application should usually be stored in the user's folder, Application Data or somewhere else on the hard drive.
Possible solutions:
Either install your JBoss server somewhere else where you have write access. ( It needs this also when running normally like for storing logs )
Configure JBoss to store logs and other files in different directories, outside of your normal Program Files one. For example to specify a different directory for logs you can set the JVM startup property jboss.server.log.dir ( Specify it at startup by using java -Djboss.server.log.dir=C:/I_can_write_here/. You can find the properties for other directories (and a lot more) at http://community.jboss.org/wiki/JBossProperties
The obvious thing to check is which, if any, of the directories in the quoted path are missing:
C:\Program Files\jboss-4.2.2.GA\server\default\log
Obviously, you have bigger problems than just this if C:\Program Files\ is missing, but you may have other directories missing.
You may need to run an initialize step to validate your configuration and create the directories.