Eclipse Tip: Using an Built-In Variable to Customize a Linked File Location in the Build Path

Today, we came across this issue and I thought I would share this information since we couldn’t find much out on the net about this subject. Warning: This is a very narrow use case.

Author Note: This post is my first java-centric blog since I have moved on from my Domino/XPages role. I hope to blog more about java related topics in the coming months, thanks to those who encouraged me to continue blogging. I have several ideas in the pipeline.

Background:  My Tech Lead and I are creating three java web services.  We often pair program but also want to be able to work alone. We use Rational Application Developer, which is a flavor of the Eclipse IDE. To manage our code, we use SVN for source control, and I making the assumption that everyone knows the basics of how that works. We are both currently working local, and the code is not on a shared server yet.

As part of our project, there are some file resources in which we need to read. These resources are in a folder that we need to add to our build path and to do so we use a linked source folder.  Also worth noting, we are not allowed to use Maven in our environment.

The Problem:  When each of us, link to the source folder on our hard drive it is stored with an absolute path. When we commit this to our shared repository and then Update to Head, we get the other person’s absolute path.  Each of our user folders is based on our five digit ID so the path is always different.  We needed a way to avoid absolute paths when we link source.

The solution: We used a variable to specify the Linked File Location which translates to our individual paths. This works well, but it is quite confusing initially, until you understand how it works.

How to Implement Solution:

Follow these five steps to use a variable for the Linked File Location:

 1) Configure the Build Path of the project and click on the ‘Source’ tab as show here.  

2a)  If creating a new location, click on ‘Link Source’

2b) Alternatively if you already have a link source then select it, and press edit to see this similar window

3) From either window above, select the ‘Variables’ button and you will see a window like this. These four variables/constants are created by default. You could also add your own here if you have a need to do so.  Make a note of the variable name or write it down because you cannot copy the name to the clipboard.

4) In the linked file location add the variable “WORKSPACE_LOC” instead of the concrete path. Hit 'Finish' to save.

The variable will show in the Build Properties now prior to hitting OK to save. However once it is saved, it will show the complete path without the variable you entered.  This is very confusing.

5) Despite the confusion, if you followed the steps right, the variable is saved. I would recommend verifying that the variable change took by opening the .project XML file and checking to see if the variable is in the path.  You need to use the Navigator window to find the .project file.  If the change took, it will look like below.

Thoughts on my XPages Experience

It is painfully obvious that XPages is on its way out as a technology solution.  Although I will always have a fondness for XPages, its time of relevancy was much shorter than I ever expected.

As someone who dived head first into XPages, I have no regrets learning the technology. What learning XPages taught me was invaluable for moving forward in the world of software development.  For me personally I am currently immersed in the java world.  Right now, I am only working on back end services, but I hope that this changes in the future.  Getting the job I have now would not have been possible without the experience gained using java within XPages. I plan on staying where I am for a long, long time.

So it occurred to me that sure, learning OneUI was a waste, there were many more lasting benefits that I gained from learning XPages.  Here are a few that come to mind.

• Hands on Java.  I embraced the use of java managed beans, and used them over SSJS whenever it made sense.

• Javascript. Even proprietary SSJS was beneficial in becoming very comfortable with the language of the web. The more you use something the better you are at it.

• Bootstrap – still very popular and another skill used everywhere. 

• JQuery – I used this heavily, and another skill that any developer is expected to know.

• Relational database exposure – Because my company had a policy of using backend DB2 with XPages, I benefited greatly.

• Dojo – I am not all that fond of dojo, but it is a skill that is good to know outside XPages. For instance, my company uses dojo as part of one of their key applications (not XPages).

• Front end javascripts frameworks. This is the future here, and XPages opened the door for me in this area.

• REST services – it was the XPages Extension Library that introduced me to this concept.  This goes hand in hand with the previous bullet point.

• Using frameworks in General.  XPages taught me to see the benefit of using established framework to structure an application.

There are probably even more, but this is the list of skills that helped me the most. Because of these skills, I have entirely no regrets about diving headfirst into XPages. I loved working with it, and in some ways wished that time lasted longer.  XPages is still an incredible technology developed by some brilliant people, but market trends and business decisions have brought us to its current state.

If you are still developing XPages, do not feel that you are spinning your wheels, but also proactively plan for the future.