I'm using maven to build and run my project on Intellij IDEA.
For tracking purposes I would like to be able to get/fetch the build number associated on VCS/Localhistory directly into my java code. Rather than get the number, if I was able to create my own and set the build number on local history it should be ok.
Like you see on that picture, I would like to get 6826bed7 or 40cfe86c like this :
public static void main(...) {
// Stuff like this
String buildNumber = IntellijInternalApi.getThisBuildNumber();
// this should print 6826bed7 in my example
System.out.println(builNumber);
}
Any idea or solution ?
Forget about it, 1) most probably you do not want to have intellij api in your application classpath
2) you dont have git information in runtime, this is the property of your working copy, not binary distribution.
You have to create this information on build stage, and write to properties file, then just simply read the value. You can do this either using git rev-parse HEAD or git decribe using maven exec-plugin, or use maven-git-commit-id-plugin
Actually, your question is duplicate of Injecting current git commit id into Java webapp
Related
Teamcity Build ID (which is different from BUILD_NUMBER) is used in various URLs. I want to send an email having path of a build's artifacts/ overview etc.
In Java, we can get currently running teamcity build number as follows:
String tc_BuildNumber = System.getenv("BUILD_NUMBER");
This is because TC provides an environment variable namely BUILD_NUMBER.
But unfortunately, there is no environment variable corresponding to BUILD_ID.
TeamCity does provide Configuration parameters (like teamcity.build.id) and System property (like system.teamcity.auth.userId) but I don't know how to access these using Java. I want to read the value of teamCity.build.id jusy like we can read environment variables names mentioned in How to fetch the Value of Teamcity Configuration in java?
Are you executing the java code using a build runner?
If so, then you should be able to pass %system.teamcity.build.id% to the runner, and make it available to your code.
i.e. If you're using the command line runner
java -Dbuild_id=%system.teamcity.build.id%
which you can then access as system arguments
Or if you're using gradle, you can do something like
if (project.hasProperty("teamcity")) {
version = project.teamcity["teamcity.build.id"]
}
and pass 'version' to the java command line.
In maven, you can just access it using:
${teamcity.build.id}
in your pom.xml
(I could do with a little more info about how you're running java to answer this specifically)
I've noticed that lots of people want to know the answer to this question.
Fortunately with the help of comment from #Jayan I was able to do solve my exact problem which was how to get URL for build artifacts.
As mentioned in link https://confluence.jetbrains.com/display/TCD10/Patterns+For+Accessing+Build+Artifacts, by default, TeamCity uses Internal Build ID for the path that can be used to access build artifacts:
/repository/download/BUILD_TYPE_EXT_ID/BUILD_ID:id/ARTIFACT_PATH
Accessing build Id could be difficult in the runtime(That is the reason of this question), but we can also use Build Number to access artifacts
/repository/download/BUILD_TYPE_EXT_ID/BUILD_NUMBER/ARTIFACT_PATH
And as shown in my question build number can be accessed as
String BUILD_NUMBER= System.getenv("BUILD_NUMBER");
and
String BUILD_TYPE_EXT_ID = System.getenv("TEAMCITY_BUILDCONF_NAME");
Yes, but you can create env var with value "%system.teamcity.buildType.id%" and read it in build. After that you can do an api request like:
$APIURL = "${API_BaseUrl}/httpAuth/app/rest/builds/?locator=buildType:${API_BuildType},state:running,count:1"
$APIXML = (Invoke-RestMethod -Headers $API_CredentialsHeader -Credential $API_Credentials -Uri $APIURL -Method GET -ContentType "application/xml" -TimeoutSec 20)
# Here you build id.
$APIXML.builds.build.id
This is PS example. But idea the same. In Java that might be more easy.
A link to a TeamCity build can use build number instead of buildID. But, it requires buildTypeId as well (can be seen in build configuration page URL).
A sample of such link is:
https://buildserver/viewLog.html?buildTypeId=Project_Trunk&buildNumber=46523
Hope this helps someone.
I have a HelloWorld Java app called FitnessTracker that I want to clone as another name, FDE3, leaving the original website in tact. I performed the following steps an attempt to do this. Please tell me where I went wrong and/or what else I need to do.
Change Context Root
Confirm Change Context Root
Still the original "FitnessTracker" name persists and I'm not sure how to get rid of it.
If I was able to successfully clone the FitnessTracker webapp as FDE3, I should be able to access the new site as
http://localhost:8080/FDE3
But I get an invalid resource error. Instead, the site is still accessible as
http://localhost:8080/FitnessTracker
..because of reminants of the old name.
What do I need to change within Spring Tool Suite to get the web app to use only the new name? To minimize chance of corruptying the project, I'd rather do it via the STS GUI over manual modification of any system file.
I see that the following file contains the text "FitnessTracker" but I would rather not modify it manully for fear of breaking. What GUI option controls this?
Search "fitnesstracker" (2 hits in 1 file)
C:\Dev\Workspace\FDE3\.settings\org.eclipse.wst.common.component (2 hits)
Line 2: <wb-module deploy-name="FitnessTracker">
Line 7: <property name="java-output-path" value="/FitnessTracker/target/classes"/>
Sorry for being a noob.
Update:
I'm not sure what I did, maybe just clean, refresh, open/close a million time, dunno, but now when I run the web server from with the Spring IDE the site is coming up using the FDE3 path, however, I am wondering why I see a reference to Fitness in Parens in the project node.
Earlier, it just displayed "FitnessTracker" in parens, now I see a full path to a Test folder...
Update 2:
When I copied the FitnessTracker project as FDE3, I didn't expect that the new FDE3 project would have any ties to FitnessTracker project and I didn't think that the new FD3 project would be in SVN until I added it to SVN, but based on the icons I see below, it looks like it is, (I'm new to SVN, too)
It looks like my issues are related to SVN.
Why is there a tie to the original FT project and why? How should I have clone the FitnessTracker project?
Yes, your issue is indeed related to SVN. Copying an SVN working copy will copy .svn folders inside that and will be pointing to the same URL in the SVN repository. What you have to do is an SVN Export of your FitnessTracker project to FitnessTracke-Ex first in either Tortoise or Subclipse SVN client and then import that project into your STS Eclipse environment. Finally you can copy and rename the FitnessTracke-Ex project FDE2 or FDE3
See this
post on how to Export a working copy
See this post on how to Import an existing project into Eclipse
I'm working on an Android project with Eclipse and I use a git repository with EGit.
I have data (in my case two strings, OAuth key and secret) that I need in my project, but I don't want it to be pushed to the git repository.
My first thought was to define the strings as compiler parameter, as the project settings are not included in the git repository. I'm used to doing this in C/C++ and it is no problem in Eclipse, but in the Java/Android project this option seems to be missing.
So, how do you set up sensitive data that is used in a java project and is not pushed to a code repository along with the rest of the code?
Make them static variables inside a class file that is ignored by Git. This would cause compiler errors for people downloading the source but it should be pretty self explanatory for the user to fix it themself as long as you keep the variables inside that class file to a minimum. Like AuthData.FB_SECRET
You could also store those two string in an encrypted (and ignored by git) file.
See for instance "Encrypt Password in Configuration Files? (Java)".
Even if that file was somehow pushed... it would still be encrypted.
I have a run configuration in my eclipse. In my project we have two branches : DEV and STABLE.
I would like to create one run configuration for building my project whatever branch it is on.
For now, when I set Base directory with one of those two variables : ${project_path}, ${build_project}, I face this error :
Base directory doesn't exist or can't be read.
This works : ${workspace_loc:/my-project-dev-branch} but is tied to a particular branch. I must duplicate this configuration for building the stable branch.
So, how can I view the actual content of ${project_path}, ${build_project} ?
Or which variable should I use to get this result : ${workspace_loc:/${eclipse_variable_with_project_name}} ?
I'm not sure I follow how your branches are represented within the workspace, but
${project_path} represents a path relative to your workspace
${build_project} will only be set during an actual build (not during an execution of your program)
Based on your description you want to be using ${project_loc} instead.
Nota: The project MUST be selected in the perspective project before launching the run configuration. Otherwise, you will get a message like in the screenshot below :
As you are already creating a String Substitution variable, through Run Debug->String Substitution in Eclipse Preferences, to deal with separate paths, you could either:
Create a variable, e.g. branch_loc, with a value of ${workspace_loc:/my-project-dev-branch}
If the paths only differ slightly, e.g. by branch name, then you could create a variable branch with a value, e.g. dev, and then create branch_loc with ${workspace_loc}\${branch}
Then use ${branch_loc} for you Maven base directory.
It would be better to have all branches use the same path, which git and mercurial allow you to do. Then you could use ${project_loc} for your Maven base directory. For project_loc if you specify the project name of your project, e.g. ${project_loc:MY_PROJECT_NAME}, then it doesn't require you to select the project in order to work.
If you right click on the project and then select Properties, you can see what ${project_path} will resolve to by looking at path and what ${project_loc} will resolve to by looking at location.
First of all, if you are using git as version control system: Do not checkout the project twice, but just switch between branches in a single project. Git was designed for that and can do that in seconds. That way your problem would vanish completely.
If that is not an option, maybe putting the run configuration under version control itself would be an alternative. Set the Shared file option as shown with the first highlight:
Then you can run the run configuration by selecting it in the respective project (as that is really a file there) and launch it via context menu. However, I've never tried this with the same launch configuration checked out twice.
You can set the base directory in below mentioned way:
${project_loc:${project_name}}
You can find the above variables from the variables option.
Also you can set your mvn command in goals as example below:
clean install -PautoInstallPackage -Padobe-public -DskipTests
The company I'm working for is starting up and they changed their name in the process. So we still use the package name com.oldname because we are afraid of breaking the file change history, or the ancestry links between versions, or whatever we could break (I don't think I use the right terms, but you get the concept).
We use: Eclipse, TortoiseSVN, Subversion
I found somewhere that I should do it in many steps to prevent incoherence between content of .svn folders and package names in java files:
First use TortoiseSVN to rename the directory, updating the .svn directories.
Then, manually rename the directory back to the original name.
To finally use Eclipse to rename the packages (refactor) back to the new name, updating the java files.
That seems good to me, but I need to know if the ancestry and history and everything else will still be coherent and working well.
I don't have the keys to that server, that's why I don't hastily backup things and try one or two things. I would like to come up with a good reason not to do it, or a way of doing it which works.
Thank you for your help,
M. Joanis
Package rename test
Procedure:
Create a new package com.oldname.test.renametest.subpackage.
Add a new class under renametest called RenameTest0.java and containing:
class RenameTest0 {
public RenameTest0() {
showMessage();
new RenameTest1();
}
public static void showMessage() {
System.out.println("RenameTest0!");
}
public static void main(String[] args) {
new RenameTest0();
}
}
Add a new class under renametest.subpackage containing:
class RenameTest1 {
public RenameTest1() {
showMessage();
RenameTest0.showMessage();
}
public static void showMessage() {
System.out.println("RenameTest1!");
}
}
Test that RenameTest0 runs fine.
Commit.
Change the messages of both of the classes.
Commit.
Again, change the message of one class and commit (just creating some history).
Apply procedure proposed above (the three steps in the original message) for renaming package renametest to testrename.
Commit.
Test run.
Modify the messages again and test.
Commit.
Try to roll back to the version when both messages have been changed simultaneously the first time.
If everything worked fine to this point, it looks good, no?
Result of test:
Note on step 9: Had to do it in reverse order (Eclipse rename THEN TortoiseSVN rename.), else it was getting complicated, as TSVN create a new folder/package and marks the old one for deletion... So you can't rename for Eclipse unless you put the old package somewhere else in the meantime to prevent losing .svn folders, etc. etc. Didn't look like a good idea to go further with this method. (Note to myself: don't forget to tick the checkbox for recursive package renaming!)
Note on step 14: Worked! We can see previous versions; all we have to do is tell not to break on copy/move and it's ok. Once reverted to a version before the rename, the package names are not back to the good name though, probably that refactoring it again would do it.
End note: I was surprised to have to do the critical steps in reverse order. To do that right in the middle of this first package rename try, I had to roll back some TSVN and manual modifications, casting a little doubt on the repeatable nature of the exact results of this procedure. I will have to do a second test to confirm it's validity. To sum up: it looks good, but needs further testing.
Perhaps it's not practical for your exact needs but TortoiseSVN has a handy feature regarding renames. You could do this:
Use your IDE's refactoring feature to rename stuff.
Launch the "Check for modifications" dialogue from TortoiseSVN.
For each renamed item, you'll see two entries: a missing "source.java" item and an unversioned "target.java" item. Highlight both and choose "Repair move" from the context menu.
Repair moves/renames
Have you considered using the Subclipse plugin? It may solve your problems, according to How do I use Eclipse Refactoring Tools and stay in sync with SVN through Subclipse?
Are you sure keeping history is NOT working if you are using the refactoring method included in eclipse?
With NetNeans I regularly change package names and the underlying 'svn plugin' will silently move the content (which saves history) into the new directory (after that the normal refactoring will happen).
so: Have you tried it from within eclipse if the history is kept with the subversion plugin? (e.g. in a fresh check-out copy to avoid failure)
At least you could use NetBeans to do this one-time task ...
Yes, it will work. You could install the command line version of svn and write a batch file that will do the svn stuff. Automating the eclipse stuff would be a bit more work, and probably not worth it unless you're already familiar with the eclipse API.
Test it with one package before you do everything just to make sure you're doing all the steps right.
You can do this, and it's not that hard - your best bet to get a clean SVN history is to do it in 2 steps (can become one commit) - though for good results I recommend using the CLI client.
Use svn mv to move the folders/packages
Go into Eclipse, or use grep from the CLI to fix the packages in the files to match the new name
Then you can commit as a change-set, and the history at the file level should match.
If you're using Maven or a packaging tool, recommend you run a release before doing something like this - also it's worth cutting a tag immediately before this in case you need to go back to the old structure
I discovered that the subclipse plugin gives the error message " is already under version control" when committing a class that has been moved to a new package (i.e. not under source control yet) and the parent of this package is also new.
When this happens, I can commit the changes using TortoiseSVN. After that I only need to refresh the project in Eclipse.
After moving a class to a new package whose parent is already under source control, subclipse can commit this change without problems.
Instead of renaming the packages you could do this:
create the new package structure in your project. Once done your project should look something like this:
com -
|- myOLDcompname -
| |- feature1 -
| |- classA.java
| |- classB.java
|- myNEWcompname -
|- feature1
add the new folders under version control so svn can track them
move your java classes from old packages to new ones. Eclipse should update all the classes imports and package declarations accordingly. Most importantly because old and new packages are under vcs this step should keep the history of the classes.
when done delete the old folders
commit!