What does the xml .project and .cproject file contains ?
.rds_delta is a file which contains data like
#delete
.delta.lst
#add
#modify
author-signature.xml
signature1.xml
what is it's purpose?
There is another file .sdk_delta.info what does this contains
I would like to know the consequences of change in these file (each of these files).
You typically wouldn't change any of these files manually.
The .project file contains general settings for your project. Eclipse settings, whether the project is linked to another project, etc.
The .cproject contains C/C++-specific settings for your project. Build paths, build flags, which compiler to use, etc.
Related
I have the following files which I would like to upload to Artifactory as a 9.8.0 versioned artifact.
NOTE: The first two files DO NOT have an extension (they are executable files i.e. if you open them/cat on it, you'll see junk characters).
Folder/files of a given version 9.8.0 in CVS is like:
com.company.project/gigaproject/v9.8.0/linux/gigainstall
com.company.project/gigaproject/v9.8.0/solaris/gigainstall
com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe
com.company.project/gigaproject/v9.8.0/gigafile.dtd
com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd
com.company.project/gigaproject/v9.8.0/giga.jar
com.company.project/gigaproject/v9.8.0/giga.war
Uploading the above files which have an extension is very easy... You log in to Artifactory as an administrator/user which has access to deploy artifacts, click on "Deploy" tab, browse for the Artifactory file and once you select the file, click on "Upload" button.
Next you'll see a screen (like shown above). You'll tweak what you want in the fields on this page and once you click on "Deploy Artifact", you are done. All you have to make sure is you select the correct file.extension file while uploading and make sure the file extension is shown in the "Target Path" box correctly (with the version -x.x.x, etc.).
My questions:
Question 1: How do I upload an artifact which doesn't have an extension? It seems like Artifactory by default takes an artifact as a .jar extension. How can I upload the "gigainstall" artifact as shown in the folder/file structure above for both Linux and Solaris? I see I can use the artifact name as gigainstall-linux and gigainstall-solaris and differentiate it, but I am not sure how to tell Artifactory that this artifact doesn't have any extension.
I don't think the development team will start generating this artifact with a proper extension (as this artifact may be hard coded everywhere in other projects where they are currently getting it from CVS/SVN source control somewhere - which is itself a bad practice to store an artifact in a source control version tool).
Question 2: How would I tell a build system (for example, Gradle) to consume a non-extensioned artifact during, let's say, 'compile' task. In build.gradle under section dependencies { .. }, I will add something like as shown below, but I am not sure for non-extensioned files (the first two in the folder/file structure I mentioned above).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0#'
//compile 'com.company.project:gigainstall-linux:9.8.0#??????'
//compile 'com.company.project:gigainstall-linux:9.8.0#""'
//compile 'com.company.project:gigainstall-linux:9.8.0#"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0#"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0#war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0#dtd'
compile 'com.company.project:gigaanotherfile:9.8.0#dtd'
}
Answer 1 (will cover 2 as well in a different sense): Using Artifactory "Artifact Bundle" feature section under "Deploy" tab can do the TRICK for AT LEAST uploading the artifacts in a way we want, by creating a zip file first (containing the structure and artifacts in it) --OR you can upload the artifacts using/calling Artifactory REST API way.
High level idea:
Create a zip file called gigaproject.zip OR anyname.zip/.tar/compressed file which Artifactory can read. Inside the zip, create the structure - how these artifacts will be loaded to Artifactory
i.e.
gigaproject.zip will contain the following folders/structure/files.
Case 1:
com/company/project/gigaproject/9.8.0/linux/gigainstall
com/company/project/gigaproject/9.8.0/solaris/gigainstall
com/company/project/gigaproject/9.8.0/win32/gigainstall.exe
com/company/project/gigaproject/9.8.0/gigafile.dtd
com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd
com/company/project/gigaproject/9.8.0/giga.jar
com/company/project/gigaproject/9.8.0/giga.war
NOTE: In case 1 example, I didn't use any -x.x.x in the filename (i.e. I'm using plain and simple giga.jar instead of giga-9.8.0.jar).
The above Upload/Deploy will result the files (as shown in the following snapshot):
So, we have achieved what we wanted. Actually (visibly speaking yes), but not in a way Artifactory usually stores these artifacts (as they should -x.x.x version embedded in the file name and where artifact id should match the artifact filename). Now, if you want to consume the following in a Gradle build file, you CANNOT as first, you haven't uploaded the filename with -x.x.x version name in it, secondly, the artifact id in our case 1 tree was "gigaproject" (after com/company/project folder), so Gradle way of defining what artifact id and what artifact file name you want won't work.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
Conclusion: It's possible to upload any files (with/without extension in Artifactory) in any structure but it depends how your build system will consume it or will be able to consume it or not.
- I deleted the structure I just created with case 1 .zip file from Artifactory repository to try next case#2 and deleted the .zip file I created.
Case 2:
Let's create an individual versioned file name for each artifact and also create structure in the format - how Artifactory actually stores them (an artifact as seen in a repository in a tree view) and create a .zip file containing that structure. Let's use the same "Artifact Bundle" feature to upload this .zip file to upload individual artifacts that we need in Artifactory - where artifact-id (second value which we mention while trying to consume it) would match the artifactfile name in Artifactory.
Folder/file structure for the .zip file:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe
com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd
com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd
com/company/project/giga/9.8.0/giga-9.8.0.jar
com/company/project/giga/9.8.0/giga-9.8.0.war
NOTE: This time, we'll be using the same "Artifact Bundle" feature and for similar files (gigainstall under both Linux/Solaris folders), I took the approach of creating gigainstall folder (containing gigainstall-9.8.0.linux and gigainstall-9.8.0.solaris file names) i.e. when we'll consume these artifacts in Gradle under dependencies { ... } section for compile, we'll use x.x.x# way to fetch these artifacts from Artifactory.
OK, once "Artifact Bundle" Deploy/Upload was successfully complete, I got the following message.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Now, let's see how it looks like in Artifactory while searching for one of the artifact/in Tree view. You can see we have the files now in place, with filename-x.x.x.extension way so that I can consume them easily in Gradle.
In Gradle build file (build.gradle), I'll mention:
dependencies {
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:gigainstall:9.8.0#solaris"
compile "com.company.project:gigainstall:9.8.0#linux"
compile "com.company.project:giga:9.8.0
compile "com.company.project:giga:9.8.0#war
compile "com.company.project:gigafile:9.8.0#dtd
compile "com.company.project:gigaanotherfile:9.8.0#dtd
}
OH OH!! - That didn't work, see below for Gradle error. Why? - Artifactory Bundle upload/deploy feature uploads a zip file content what you have in the .zip but it DOES NOT create a .pom file per artifact it deploys. Thus, making the Gradle build to fail. May be in Ant this might succeed. This occurred for each individual .jar/.war/.dtd/etc file. I'm just showing one error example.
While doing gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
Case 3: Let's take a simple approach (workaround but will save a lot of pain).
Create gigaproject.zip file with the following structure, this approach takes - No x.x.x version value embedded in the individual artifact/filename in the folder/file structure. We will use "Single Artifact" approach (which will create the .pom for gigaproject.zip file automatically during the upload/deploy process provided by Artifactory). You'll still be able to get gigainstall file without needing any extension to its name using this approach. During the upload/deploy step, as you already have seen, you upload gigaproject.zip and artifactory will upload it to a given Target Repository as "gigaproject-x.x.x.zip" where x.x.x is 9.8.0 in our case. See the image snapshot below.
gigaproject/linux/gigainstall
gigaproject/solaris/gigainstall
gigaproject/win32/gigainstall.exe
gigaproject/gigafile.dtd
gigaproject/gigaanotherfile.dtd
gigaproject/gigaproject.zip
gigaproject/giga.jar
gigaproject/giga.war
Now, upload it in Artifactory using "Single Artifact" feature. Click "Deploy Artifact" once you tweak the values for GroupId, ArtifactId, Version, etc.
Once this is uploaded. You'll see in the zip artifact in the target repository (I took a bad example, usually this would be libs-snapshot-local or libs-release-local instead of ext-...), you'll be able to consume the ZIP artifact directly in Graddle:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0#zip"
}
Once the .zip is available to Gradle build system, now you can tell Gradle to unpack this .zip file somewhere in your build/workspace area where you can feed the actual(unpacked) files (gigainstall, .dtd, .jar, .war, etc.) to the build process/steps.
PS: Case# 1 and 2 would have worked for Ant I guess.
Answer 2:
If you have uploaded a non-extensioned file in either way. Make sure you have manually created/uploaded its POM file as well (i.e. if I uploaded gigainstall-9.8.0 as an artifact under com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, then at the same level, I have to/should create it's POM file (see a simple template .pom file for a custom jar artifact or while uploading an extensioned file via "Single Artifact" deploy, you'll see what POM Editor window shows you) and upload both so that Gradle won't error out saying no POM conflict/error. Ant might not need pom (I didn't check that).
Once it's there in Artifactory, the following line should work -- OR comment please if you find another way.
dependencies {
// See nothing mentioned after - x.x.x#
compile "com.company.package:gigainstall:9.8.0#"
}
I'm making a JApplet and need to make a JAR file to connect to a .htm file with the applet tag. The simple solution I could think of was to use the tool in drjava that says "Create Jar File From Project..." but alas, it's not highlighted for some reason, so I can't do that. What I'm really looking for is either (a) an explanation as to why drjava can't turn my classes into a jar file, (b) an alternative to allow me to create this jar file, or ideally (c) both. Thanks for your help ahead of time.
I don't use Drjava, but here is how you can create a JAR file from the command line without any IDE specific complications.
Simply go to the folder/directory where your project is located. Let's say your class files are located in the bin folder. You can then use
jar cvf myapplet.jar -C bin .
The JAR is then ready to be deployed.
I have a Solution that contain 3 projects.
1 Windows application and 2 class library.
Folder structure tree on my disc is as following:
\projects\CurrentProject\test\
\projects\CurrentProject\build\
The solution files are located under:
/projects/CurrentProject/
All 3 projects are located at \projects\CurrentProject\test\
I need all the build outputs of all projects (1.exe and 2 dlls) to be under \projects\CurrentProject\build\ ...
So on each project, i go to "project properties", select on both debug/release the output path to be: "....\build", but still after doing so, i have files on /obj of the class library projects.
Why is this ?
Thanks
To move your obj folder elsewhere your can customize your build configuration using the BaseIntermediateOutputPath property in the project file (the .csproj file).
To do it:
Open the .csproj file in a text editor (the .csproj file is an XML file)
Edit the value of the element BaseIntermediateOutputPath or add it in the desired PropertyGroup. (The line to modify or to add looks like <BaseIntermediateOutputPath>..\build\obj</BaseIntermediateOutputPath>)
Save the file
Reopen your project in Visual Studio.
I created a WPF test project, single Window with a single button in it. I then unloaded the project and modified the csproj to contain the following <UICulture>en-US</UICulture>. After rebuilding the build folder now contains a subfolder named en-US and it contains a file called WpfLocalizationTest.resources.dll. All clear so far.
Then I downloaded the source code for Locbaml and built it. (Couldn't find a binary download anywhere, go figure.)
Then I copied the Locbaml.exe to the en-US folder and tried the following.
locbaml /parse WpfLocalizationTest.resources.dll /out:test.csv
This results in an error 'Could not load file or assembly WpfLocalizationTest.resources.dll or one of its dependencies. An attempt was made to load a program with an incorrect format.'
In the obj\x86\Debug folder there's a file called WpfLocalizationTest.g.en-US.resources. I tried running locbaml on that, but the result was the same.
How is locbaml supposed to be used? MSDN is full of cockamamie samples, none of which work. Is locbaml really how Microsoft intends WPF apps to be localized? Or have they come up with proper tools for the job?
As I continue to search I found another link here on Stackoverflow. The compile errors we were originally receiving were related to an outdated LocBaml project not being set for .Net4.0. This is why I was unable to generate teh CSV from the DLL and had to go straight at the resource file. Follow this link for more details. Locbaml localization of .net wpf4 application
This link provides a link to .net 4 binaries which once compilied allow you to go straight at the dll to generate the CSV using LocBaml.
Just an update I pulled my notes this morning. Hopefully this will help get you a bit further along.
Once the project has been compiled copy the LocBaml.exe to the project directory where the build has been generated : In my instance I copied the file to E:\localiztion_sample\localiztion_sample\obj\x86\Release
This is the tricky part in that the build did not contain all the DLL files from the bin directory (telerik controls and other assemblies). As a result I went to bin\release\ and copied all the DLL and resource files from there into the obj\x86\Release directory. For files where I was prompted to overwrite I looked to see if there was a difference in filesize or date created and if not I skipped the copy for these objects.
NOTE: In order for me to generate the CSV I had to copy dll and resource files from the bin directory and place them in the obj directory. Omitting this step will result in the CSV file being created but not populated with data.
Once you have copied the necessary files to the directory you will then parse the .resource file located within the Release directory.
In my project the resource file was located at:
E:\localiztion_sample\localiztion_sample\obj\x86\Release
And the file name was titled: localiztion_sample.g.en-US.resources
Note: this is different from the instruction on the Microsoft website. Microsoft states that you should run the LocBaml tool on the dll file located within the en-US directory. However after multiple attempts and research I found that this in fact caused a number of problems with compatibility between 32 and 64-bit builds as well as it just flat out not working.
In reading through wpf4 unleashed as well as online forums it is suggested to instead point to the *.gen.en-Us.resources file. * = the project name and gen.en-Us reflects the development language chosen
Within the VS command untility you will then need to enter the following
LocBaml /parse filename.resources /out: sample-en.csv
Notes: It is assumed that you have copied the LocBaml file to the root directory where this file exists and that you are running the command prompt as system administrator. For ease of use I changed the working directory within the command prompt to the VS project directory
For my sample project the command looked as:
*LocBaml /parse localization_sample.g.en-US.resources /out: sample-en.csv*
This command then generates the CSV file which acts as a definition of the current project
This was as far as I got I was able to modify teh file and regenerate the dll but I was not able to get the culture to change within the application so I am still working on this piece. I'll reposte once I get it working.
1) Unload project you want to localise
2) Edit Project .cproj file
3) Add property group at the end of the last property group
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
en-GB
4) Reload project and compile this would create a satellite assembly "yourlibrary.resources.dll" inside en-GB folder at bin\debug location, this assembly would be the default assembly.
5) Open Properties\AssemblyInfo.cs file and uncomment this line [assembly: NeutralResourcesLanguage("en-GB", UltimateResourceFallbackLocation.Satellite)] this is a fallback satellite assembly. And we need this entry otherwise for wpf application it throws exception around app.xaml.cs couldn't load
6) From command prompt run this command which uses msbuild to generate UID C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /t:updateuid . \yourlibrary.csproj, open xaml file and check your controls there would be UID on all elements.
7) Download locabaml.exe source code tool from https://github.com/JeremyDurnell/locbaml
8) Copy locabaml.exe file to the \yourprojectname\bin\debug folder
9) we would now create an satellite assembly for french. First we need to parse the default satellite assembly and write out the contents to a csv file as shown here
10:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /parse C:\yourprojectname\bin\Debug\yourlibrary.resources.dll /out:C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv
11) Open yourlibrary.resources_FR.csv make necessary translations
12) Now we need to create a satellite assembly in french using command line
13) C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild /generate C:\yourprojectname\bin\Debug\yourlibrary.Resources.dll /trans: C:\yourprojectname\bin\Debug\yourlibrary.resources_FR.csv /out:C:\yourporjectname\bin\Debug\temp /cul:fr-FR
14) The command above would create a folder fr-FR at \bin\debug location
15) Switch your computer region settings to french(France)
16) In the code set localisation to Thread.CurrentThread.CurrentCulture = CultureInfo.CurrentCulture;
Thread.CurrentThread.CurrentUICulture = CultureInfo.CurrentUICulture;
17) Compile and run application you would see translated text on the controls
I have a set of functions saved in a clojure file.
How do I Provide selected set of functions and then import these functions in my other file?
You have a few options.
If it’s just a file (not in a package) then in your files, you can just use load. If your file was named “fun.clj”, you would just use the name of the file without the extension:
(load "fun")
(provided fun.clj was on your classpath). Or
(load "files/fun")
if it wasn’t on your classpath but in the files directory.
Or you could use load-file and pass it the location of your file:
(load-file "./files/fun.clj")
If you wanted to namespace them (put them in a package), then you’d put the ns macro at the beginning of your file, again put it on your classpath. Then you could load it via use or require.
Here are the docs for the functions I’ve described:
load
load-file
ns
use
require
Besides "load"ing source files, you can also use the leiningen "checkout dependencies" feature. If you have two leiningen projects, say, project A requires B (provider). In the root directory of project A, create a directory called "checkouts". Inside "/checkouts" make a symbolic link to the root directory of project B.
- project A
- project.clj
- checkouts
- symlink to project B
- src
- test
in project A's project.clj, declare project B as a dependency in the :dependencies section as if it were a project in clojars.org. E.g.
(defproject project-a
:dependencies [[org.clojure/clojure "1.5.1"]
[project-b "0.1.0"]])
The thing though is, you have to go into project B and type:
lein install
That will compile project B's files into a jar file, which will appear in your ~/.m2 directory, which is kind of like your local clojars.org cache.
Once you set all this up, in your *.clj src file(s) of project A, you can "require" project B files in the normal way, as if it were from clojars.org:
(ns project-a.core
(:require [project-b.core :as pb])
This way, you can refer to functions in your project-b.core the usual way like this:
pb/myfunction1
In my opinion, this is a pretty good way to share libraries and data between Leiningen projects while trying keep each Leiningen project as independent, self-contained, and minimal as possible.
This one solved my problem and I have looked through countless other issues here so I would like to clarify.
The easiest way in emacs (on linux) is to do something like this:
java -cp "lib/*":. clojure.main -e "(do (require 'swank.swank) (swank.swank/start-repl))"
(note the "lib/*":. given to -cp
Then you can use M-x slime-connect to connect with this instance.
Don't know if it's required, but I have read that it's a good idea to use the same version of clojure, clojure-contrib and swank-clojure on both sides.
You can also setup the path inside emacs by consing the "." to swank-clojure-classpath.