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.

New Directions

It has been a long time since I have posted any blog updates, so I wanted to give an update on what is happening in my world.

As I write, it seems like a very long time since I attended IBM Connect 2016 this past January/February.  It was a great conference and I came home from it very optimistic and fired up about the future.  I was nearly 100% sure that I would soon be moving on from my current position as a contract XPages developer at Navy Federal and finding a new position somewhere else as a Notes Domino/XPages developer.  I had several encouraging meetings at the conference and I left sure that one of them would work out for me.

In March, I came very close to being hired for one particular position that would have had me working with some of the best XPages developers in the business.  After a very positive interview, that job fell through due to factors beyond mine and their control.   It's also worth noting that in the last year, I started to notice a decline in the number of XPages job postings.  It seems like a year ago, there were always 5-7 postings out there, sometimes more, sometimes less.  It seems now the only postings are in the DC or New York areas, two places in which I do not wish to move.

While I love the platform and have a long and positive history with Notes, I knew and have known for years that it was only a matter of time before I would need to move on to other technologies. Years ago in the mid 2000’s I immersed myself in Java with the intent of moving in that direction.  I thought that my ideal job would be where I can get in the door as a Notes developer and then transition to Java without taking the big pay cut that would occur if I went the Junior Developer route.  This was my plan, but I kept getting interesting and well-paying Notes developer jobs.  When XPages came out, I immersed myself in learning it, and found that my prior Java studies have paid off greatly in that area.  While I like backend java, I really loved front end work and I think I am a decent UI designer.

In early April, I found myself working as contract developer and working on doing mostly Notes development.  For some reason, Navy Federal has decided not to create any more XPages projects so most of the work would be maintenance projects on existing Notes client applications.  I was not getting serious interest for other jobs developing XPages despite the honor of being an IBM Champion.  Meanwhile my manager, for whom I have a lot of respect, continued to encourage me to apply for a full time Java developer position in which I would still report to him.  After much reflection, discussion, and prayer I did decide that I would move forward and accept a position if it was offered.  

At the end of April I accepted a full time position as an ISD Developer III and will be working on Java and whatever else they ask me to do.  I hope to get to eventually get to work with the front end again, but for now it will be mostly back end.  I still might work occasionally with Notes if they assign me those projects.  It is very unlikely that I will work with XPages again any time soon.

It is not without some sadness that I move on from the Yellow Bubble (Notes Community).  Even though I am moving on, I hope to maintain contact with the friends I have made.  I remain extremely honored to have been named an IBM Champion for 2016. In some ways it feels like going out on top.  I look back to my goal of ten years ago of transitioning to a Java developer internally from Notes, and realize that I have obtained that goal over 10-12 years after making it.

After I accepted the job but prior to my start date, Navy Federal was kind enough to let me take six weeks of leave to catch up on family visits and move the last of my possessions in storage from Utah to Florida.  Despite many miles of driving, we had great visits in Texas, Utah, Missouri, Minnesota, Indiana, Pennsylvania, and Virginia.  I also got to add 62 miles towards my goal of completing the Appalachian Trail in my lifetime.

So as of today, Monday June 27, I am now a Navy Federal full time employee.  I plan to stay for a while and we will settle here in the Florida panhandle. I have peace about my decision and am excited for the future.  I am also relieved to not have to worry about my future employment for a long time. 

As far as this blog, I hope to continue to blog whenever I find topics that I think will be of interest, and/or topics that I need to make sure I remember for later.