I am trying to add a single external JAR file to my Eclipse path to make it able to perform a needed function. I have attempted to load in the project through Maven in hopes that it would gather all needed dependencies, but it still gives me an error.
Is there an easy way to make one single call to the internet to download all necessary dependencies for an External JAR (and all their dependencies, etc, etc)?
Mind you, this code is a very specific, one-time implementation that does not need to be exported or run on any other machine. Even if the program I'm writing will not ever work as a JAR on it's own, that's okay. I just need a quick and easy way to get all my dependencies in one shot.
Related
So I have a .java file which, for example, uses the OpenCSV dependencies. I use these dependencies via the .jar files within Eclipse and link the build path, rather than typing them in via the pom.xml file. I assume this produces the same output, being able to use the libraries, but I just want to cover the bases. I am attempting to email this .java file along with dependencies to a possible employer, but I am having trouble emailing it at all. I found out you apparently cannot send a .jar file via email, so I tried to pack all the dependencies and my .java file into a Executable JAR file (and just a normal JAR file) and they still wouldn't send. Then, I tried to change the file extension to something like .jpg, and even .jpg.zip, still to no avail. Does anyone know how I could send these over? I was hoping to send them with the dependencies, but I feel like at this point I will need a README file with the dependencies needed to be downloaded, which kinda sucks. Thanks in advance for any assistance!
I found out you apparently cannot send a .jar file via email, so I tried to pack all the dependencies and my .java file into a Executable JAR file (and just a normal JAR file) and they still wouldn't send.
I can't pack explosives in my suitcase when I fly, so I decided to pack an even bigger bomb, and for some bizarre reason they wouldn't let me fly with that, either.
(If you cannot mail jars, you cannot mail jars. You cannot obviously solve this problem by messing with how you pack the jar!)
I use these dependencies via the .jar files within Eclipse and link the build path, rather than typing them in via the pom.xml file.
Type them into your pom file.
Then, I tried to change the file extension to something like .jpg, and even .jpg.zip, still to no avail.
I tried to tape a sticker that reads: "Hello! I am a teddy bear and most definitely not a bunch of explosives!" but airport security didn't fall for it.
(gmail and friends are not complete idiots. Stop trying to mail a jar file to a service that does not allow you to do so).
The industry standard way to 'mail' a project is first to have a project that can in fact be distributed. What you're trying to pull is to combine the sources, but not in a state that the recipient can actually compile them, along with some half-baked distributable. This isn't going to work: Pick a side. Either [A] just ship sources (just the java files, and the pom), or [B] just ship the executable, which you don't email - put it on a site someplace. Given that it's heading for a potential employer, they obviously want door number one: sources.
Put your project on github or some other public source repository. If you aren't using source control, that's a big problem and will likely lead to your employer having an issue with hiring you - it's industry standard, time to learn. It's not particularly difficult.
Next, ensure the project as is builds cleanly on a clean system. That means it is high time to stop handrolling your deps in an eclipse project: You evidently know what maven is, so use maven as it is meant to be used; put the deps in there. You want a readme file, but all it really needs to contain is something like:
(Short explanation of what your application does)
To build and compile this project, ensure java and maven are installed on the system.
(at least java11), and run:
mvn compile
And then you mail then the link, so, https://github.com/cardinalsfan13/myproj or whatnot, and nothing else.
If your arms itch when I mention 'put it on a public repo', then you can still mail the sources (so, pom.xml, java files, and not much more), zip em up. email itself can handle jar files just fine, so either your mail service, or theirs, is detecting them and denying your email. Zip them up with a password, or use a file mailing service then. These are significantly worse options than mailing a link to github or some other source repo hoster, though.
I'm working on a JavaFX project and there is a framework behind the scenes which handles CDI to inject a context. The problem is that the GUI is part of a bigger application and I want to be able to test it without the need to start the whole application every time. For this, I needed to update a file which is included in a dependency. I copied it to my workspace and added system properties that I can set in my launcher to fake some needed data. Until the dependency is updated to include this behavior, I need to keep the patched class in my project. The problem is, it should not be released.
So basically I want to exclude a java file from deployment but not from compilation so I can use it locally in my project.
I already tried these things:
maven-compiler-plugin: via exclusion I managed to get rid of the file but then it won't compile at all which means that I can't use its functionality in my project
copy the file to src/test/java instead - the file is not visible from the JavaFX form in the main project
maven-assembly-plugin: can't exactly get this to work the way I want it
Did I miss something or is there a way to achieve this with the assembly plugin without interrupting normal deployment?
Some weeks ago at work I took over a Java-based back-end web application written using Eclipse. The nature of the application is that it cannot be adequately tested locally, and instead changes need to be tested on our testing network (which involves pushing the changes to an AWS Micro server that we connect to via SSH).
Until now, I pushed changes in the same way as my predecessor: compile the program using Eclipse's Export to Runnable JAR File option, then scp the jar to the remote server and run it. However, this process has a huge problem. While compilation takes only seconds, the jar is well over 30MB, and pushing the entire thing from the office to the remote server over our fairly ordinary internet connection takes well over 10 minutes. If I'm having a particularly bad day and, say, introduce several minor bugs to the code and then discover them one by one, I can easily end up losing an hour or more in total twiddling my thumbs while pushing the whole jar over and over for a series of one-line changes.
Clearly, a saner solution than scping the entire jar for every change would be to simply remotely pull only the changed .java files from source control, and then compile the new version entirely remotely. However, I'm quite new to Java (and indeed programming generally) and all my Java work has been on existing Eclipse projects that I've taken over partway through development. As such, I know very little about compiling Java, and I have found the tutorials about this online are mostly either opaque or completely fail to address the question of how to compile code that uses external libraries.
I will relate here what information about the project's dependencies I can find from Eclipse, and my questions are these: what do I need to copy to the remote server, and where do I need to put it, to be able to compile remotely? What tools, if any, do I need to install on the remote server to be able to compile there? And once I've got everything set up, what do I actually type at the command line to get it to compile?
Anyway, here's what I know about the dependencies and directory structure (I've anonymised our application name by calling it “bunnies”):
The application source code is located in bunnies/src
We compile to bunnies/bin/main.jar
bunnies/dependencies contains three jars of external libraries that we use.
Right-clicking on the project in Eclipse, going to the Java Build Path section, and selecting the Libraries tab, I see
the three libraries above
(appearing in the form, e.g. “json-simple-1.1.1.jar - /home/mark/workspace/bunnies/dependencies”)
a fourth jar file in another location
(“M2_REPO/com/google/guava/guava/r09/guava-r09.jar - /home/mark/.m2/repository/com/google/guava/guava/r09/guava-r09.jar”)
JRE System Library [java-6-openjdk-i386]
But there's more! We also use two libraries, mahout-core and mahout-integration, that are included as separate projects in the same workspace rather than as jar files in the dependencies folder. They appear by name on the Projects tab of the Java Build Path section of the bunnies project, and are located at /home/mark/workspace/mahout-core and /home/mark/workspace/mahout-integration respectively.
Since I am not a Java whiz, perhaps there are also some other hidden dependencies I'm missing, that don't appear in any of the places I've looked so far?
If anyone can walk me through the steps of compiling this huge mess from the command line, without needing to use the Export option in Eclipse, so that I can ultimately compile it all remotely, I would be highly appreciative.
Look into Apache Ant. It's a build-suite for Java, sort of like an XML based Makefile system.
I have a Java system running on a remote server. I have a directory structure separated into /src and /build. I then just scp the .java files from my local machine to the /src folder and build using ant.
Alright, so I have a web service that was created using an eclipse dynamic web project. It is currently shared on a CVS repository, but the versioning system used is irrelevant. At the moment, I have literally NEVER been able to pull this project out as is and get it working. It leads to countless errors that cannot be fixed. Every time I need to work on this webservice in a new machine I have to create an entirely new dynamic project, copy over the source files, add all the necessary libraries and make the deployment assembly work correctly again. After finally making it run I share the project as the same one, stop after a second, and then synchronize again (in a way tricking eclipse into thinking this was the shared project all along).
I feel like others must have run into this problem and found a way around it. So if you have a web service or any dynamic web project, what files do you share, and how do you successfully pull it from the repository and get it to run on another machine besides what I currently do now?
Your help is much appreciated,
-Asaf
Edit: After reading some of the responses I feel that this question is actually more specific to those who use WTP to create/test their web services. Just wanted to add the clarification.
Edit2: Let me also clarify that the other 20 or so projects not using WTP are shared just fine. I am able to pull and run them with no problem. Only web service projects are an issue.
In general, you want to check in everything that's not "derived" (generated or compiled - that's usually the contents of the bin directory or other place where your code is compiled/built into). For Eclipse Java projects, you want to include the .project, .classpath, .settings, and any other similar files that Web Tools might create for Dynamic Web projects. The Eclipse CVS client will ignore files marked as Derived so you shouldn't have to worry to much about it.
Without more detail about what kind of problems you've run into, it's not possible to guess what was causing them. My only guess is that perhaps you had different versions of Eclipse and/or the WTP (Web Tools Platform) plugins installed on the different machine. That's just a wild guess, but could explain some incompatibility when you check out the project from CVS.
Bottom line, checking in those .* files is the long recommended approach from Eclipse gurus. Maven can kind of change things, but you didn't mention it so I'm assuming you aren't using it.
I am primarily sharing my experience, may be you can find some help.
Conceptually speaking, the files which the IDE can generate itself while creating new project should not be pushed. I.e the IDE specific files should not be pushed. And everything which the IDE cannot generate on its own must be pushed.
Forexample in case of eclipse, following files should not be pushed:
.settings
build
.classpath
.project
For setting the project on new machine, first pull the files from server, and then create a project from IDE using pulled files.
EDIT: If your project has external jars/libraries, then you will have to add to the classpath manually. You could also push .classpath but that might give errors while creating a new project.
I think it's easiest to use a build system and let the IDE generate the project from your build system.
Eclipse, Netbeans, and Intellij are all pretty good at building projects from maven or ant build files. With this solution you have a simple build that is easy to setup in CI (Hudson, Bamboo, whatever) and you don't have any IDE specific files checked in. If my workspace is totally different than yours, with different versions, plugins, whatever, I'm not stuck with your project file and you're not stuck with mine. My IDE creates the project appropriate for my environment and your IDE does the same for yours.
Since you mentioned having to manually add libraries, I assume you are not using any build manager (like, maven or ant) besides ecplise.
For ecplise to handle the project properly you need the source files (*.java) in their respective directories, any resources bundled with the web service (e.g. services.xml), the ".project", ".classpath", ".settings", etc. files for eclipse. This should be enough for eclipse to generate anything else necessary to build the project.
Any files/directories that are generated by eclipse during the build process (e.g. target & bin directory, *.class, *.war) should not be checked in -- they will be generated when needed during the build.
I am thinking that, since you are adding the necessary 3rd-party jars manually, these libraries might reside in a different path between computers (e.g. if the path contains the username, it will not be transferable to another computer for a different user). To fix that you can set up the classpath using an eclipse classpath variable. In Preferences->Java->Build Path->Classpath Variables set up a varable linked to the "root" folder where the 3rd party jars a stored. Then add the libraries to the project using this new variable, not their full path. To make it work on someone else's computer, you would only need to set this classpath variable to have the build path point to the correct libraries.
It might be beneficial if you migrated your project from eclipse only to a build manager (e.g. maven) that takes care of many of these issues for you. Eclipse can build a project from the configuration of the build manager, making it easier to manage the project.
I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.
1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.
I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps