We Keep Coding

Using external jar as dependency file while running spring boot jar

I have a Maven-Springboot project setup. After doing a mvn install I can run the jar file in command prompt using java -jar <my-jar-file.jar>
There was a dependency to a jar say as-common-1.0.0.jar that is there in my-jar-file.jar. Now I want to override the version of this dependent jar at run time by giving an external jar. something like:
java -jar my-jar-file.jar using as-common-1.0.1.jar
I went through many SO posts like thisinclude external jar when running java -jar but they didn't help.
is it achievable?
EDIT: The issue we have is many of our applications depend upon one of our internal framework jar which gets updated(version) often.
So every time changing the pom file and re-deploying all the apps doesn't look feasible to us. We want somehow the dependency of this particular jar is given at run time. Any idea regarding best possible way to manage this scenario?

No, this is not sensible. At best, you would load classes twice and this may/may not work.
If you build a complete jar containing everything, you cannot swap content at runtime. You need to rebuild it.

Running a compiled Jar file in Jenkins

I am trying to run an executable jar file through jenkins. What I am trying to achieve here is I have an executable jar file created and is residing locally in my machine. I want to put it in Git and then run it in jenkins. Is there some how I can do this? I am totally new to Jenkins and if someone can help it will save me a lot of time.

You can do nearly everything you want with Jenkins since you can have it run arbitrary scripts / executables.
If you want to put this .jar in git, then the Jenkins jobs will retrieve it when it fetches the repo. Then you just need to add a script shell step to the build, and to put your command line java my.jar my.class ....
On the other hand, it's sometimes frowned up to put binary files in git. It's true in particular if the .jar will need to be often updated. Hence you might want to provide the .jar to the Jenkins job using alternative methods. For example using a maven repository.

Add working directory to build

I am having trouble adding dependancies that are located in my working directory, to my .jar. When I try to run the .jar from command line I get errors saying that files I am attempting to access do not exist. Why does netbeans not include the working directory in the build dependancies, seems like a pretty easy and obvious thing to do....
I am simply trying to read a file, located at res/settings/settings.txt. I have made my working directory the res folder so that in netbeans I access that file successfully through 'settings/settings.txt'. I attempted to make the settings folder a library so it would be added to the build, however it refused to copy it because it was a directory.
How can I add this file to the build so i can run it from command line?

Why should it? The working directory is simply a "test" location for your application. The build process is not a "packaging" process.
Netbeans provides you with a build.xml file which can you can modify to perform custom actions, but consider this, each time you build your application, these custom build actions/targets could be executed. That could add considerable time to your build process. If you're just making small changes, this might not be desirable.
Two solutions then come to mind.
You could create custom build targets within the build.xml file which you would need to trigger by right-clicking the build.xml file (in the files view) and selecting Run Target and choosing the required target from the cascading menu...from experience this is not as convenient as it sounds. You could also run the build.xml file from the command line, specifying the targets you want...
Make another ant script which packaged your application separately. This is similar to the first comment except that you completely divorce the build and package processes.
I work on a very large application, which was taking upwards of 15 mins to build (completely). We wrote a utility which went through all the Netbeans project properties and built it's own dependency map, which then generated an Ant build script. We then included this in our own packaging script, so we could build the application and package it within a single pass when we wanted to create a release. This reduced the build down to something like 3 minutes (don't ask why, it just did), it also meant that we could remove the immediate dependency on Netbeans from our build process.
So. The basic answer is. Netbeans is a builder, not a packager. In order to supply this support, you're going to have to write something yourself. The easiest thing to do would be to simply write some Ant script to perform this aciton. Where you do this is up to you.

Jenkins and Maven : how to package some files in my JAR and unpack them before running a test?

Using Jenkins to run my test suite. As part of the setup for an integration test, I need to copy a bunch of files into a given folder. I'd like to include these files in src/test/resources, and then somehow unpack them and copy them onto the folder before running the test. What's the best way to accomplish what I'm trying to do?
Edited to add :
Basically, I'm testing a method that needs to read some files from a folder on our hadoop cluster. On my Jenkins box, I have a single-node hadoop "cluster" running in pseudo-distributed mode. Thus, I need to copy those files onto the cluster before running the test. So I need to :
A) Somehow get the files onto the Jenkins box (I was thinking it would be easiest to package them in the JAR) and
B) Copy those files onto the hadoop "cluster".

First thing you should do is to set the option in jenkins job so that your workspace is not cleaned up on every run. This will esure that folder structure is intact before you start the build.
Use the plugin https://wiki.jenkins-ci.org/display/JENKINS/pre-scm-buildstep
You can add a step before you start the build copying and unpacking [basically it will provide you unix shell to execute any commands, so its you can do anything like ftp,rsync, unjar here].
But i am not sure how will you direct your test case to use these new files, but then i have never worked on hadoop so can't comment on that.

Java, Eclipse, Ant, JUnit, Hudson, SVN, native libraries; can they all coexist?

What is the most proper way to accomplish all of the following:
Create a project in Eclipse
With an Apache Ant buildfile
That Hudson (or another more recommended CI system?) uses
And support for JUnit tests that are run by both Ant/Hudson and Eclipse
And check the proper folder structure into SVN so that future developers can replicate the build, and Hudson can automatically grab from SVN and run the Ant file to build/test/deploy the project
And the project has native libraries, if that makes any difference (I've already written an Ant task that can download and unzip the proper library files depending on the OS)
I already have my project with some source files and an Ant file, but I've been having trouble integrating it with Eclipse in an organized manner, so I would really love to start from a fresh Eclipse project, set it up correctly, and then copy my Ant file and my source files piece-by-piece into the project in the most Eclipse-compatible way.
I will be continuing to play around with everything in an attempt to get it working as I like it. But if you have experience with this sort of thing, perhaps at your workplace, please give as much information as you can.
My main goal here is to learn this once and use it in my future projects. For now, I am developing a client-server application consisting of a JOGL applet frontend (using JNLP files) and an unattended server app. Up until now I've been doing it all by hand: writing and building in Eclipse, dragging the applet jar into my FTP client, SSHing the server jar and restarting it by hand, and all with no testing process. I'm hoping that by the end, the build process will be something like this: test locally on my machine with a copy of the native libraries; commit code changes to SVN; Hudson svn updates, uses the Ant buildfile to compile and run all JUnit tests; if all the tests pass, it proceeds to copy the server jar to my dedicated server and restart the running server instance, and then copy the client jar to my web server.

When I start a new project, I generally take the following steps:
Create a new Java project in Eclipse, using the Java project wizard and opting to keep source and class files in separate directories ('src' and 'class')
Set up the project in Eclipse with the package structure you want
Create a new repository (or folder in your repository) for the project, with the normal /trunk/ /branches/ /tags/ set up
Using your SVN client, import the contents of the project folder Eclipse made for the project (at the level where the 'src' and 'class' directories are) into the trunk of the repository
Confirm everything is in Subversion correctly (check the trunk out to a new location)
Using Eclipse, delete the project (and the files on disk)
Create a new project using the 'Checkout projects from SVN' wizard, using the trunk of the repository
Create your Ant script, ensure the project builds correctly, and add the Ant script to the repository
Now, from Hudson:
Create a new job and set the Subversion URL to the root of the repository
Add a build set that will use Ant (I've always had to install my own version of Ant and ensure it's configured correctly to have this work) and will call the Ant script you
Use 'Build Now' to see if the job will build correctly
You can invoke your JUnit tests from Ant in the build script (first compile them with the javac task, then run them with the junit task). Hudson will track the test results if you ask it to.
You can use a shell script build step to copy your server jar to where it's needed, and restart the server instance. Like Mnementh said, it sounds like you've got the native libraries sorted...

If you are not tied to using ant, and are prepared to use Maven, then it is simply a matter of setting up Maven with the Eclipse plugin which generates the Eclipse projects for you.
Hudson already knows how to build Maven projects, so that is taken care of.
So long as you can pull your projects into eclipse, then it will be able to run the unit tests, and hudson can use the previously mentioned maven support to run the unit tests as well.
If you use Maven, then you will want to follow it's guidelines on how to create a project, here is a good starting point.
Hope this helps.

At our company we actually use Eclipse, Java, Ant, SVN, Junit and Hudson. That is all you mentioned except the native libraries. If you said your ant-buildscript already works with the native libraries that problem seems solved too. To integrate it well into eclipse you could do it in two ways: Use Ant also from Eclipse (has downsides) or the developer has to install the native library for his machine properly, so that Eclipse can compile without a problem and for continuous integration it will be downloaded by Ant.