I am a big fan of jetbrains products, and am an intellij (community edition) user for all my java development. However there is one feature from eclipse that I REALLY miss. In eclipse, if I had a bunch of jarfile dependencies, I could repackage them in my runnable jar file so all dependencies were contained in one jar file.
I can not find anything that will get this done in intellij, so I am forced to export my projects to eclipse format from intellij, fix the project configuration in eclipse (since intellij doesnt do such a great job on the export) and then build my jarfiles from eclipse.
Have you taken a look at the build artifact component of IntelliJ? It allows you to define a JAR build artifact (executable or non-executable) that can include the dependencies either extracted within the target Jar or as a link within the Jar's Manifest file. See this blog entry for the details: http://blogs.jetbrains.com/idea/2010/08/quickly-create-jar-artifact/
Related
I am trying to achieve the following between Eclipse and Gradle:
Allow Gradle to handle 100% of my local build logic; only use Eclipse as an IDE for syntax highlighting, refactoring, etc. Every time I wish to build my app I want to drop into a command line and run a Gradle build invocation from there.
I want the dependencies closure of my build.gradle file to be the sole location for configuring 3rd party dependencies; every time I make a change to this closure (adding/removing a dependency/JAR), I want Eclipse to automagically "see" this change and adjust my project's classpath accordingly
I installed the Gradle-Eclipse Integration plugin and then I followed this tutorial for configuring it correctly.
First I ran:
gradle clean build
And then I added:
apply plugin: 'eclipse'
To my build.gradle, and then ran:
gradle eclipse
I saw a lot of output, the tail end of which is:
gradle eclipse
:myapp:eclipseClasspath
Download http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/3.3.2/commons-lang3-3.3.2-sources.jar
Download http://repo1.maven.org/maven2/org/sonatype/sisu/inject/cglib/2.2.1-v20090111/cglib-2.2.1-v20090111-sources.jar
Download http://repo1.maven.org/maven2/asm/asm/3.1/asm-3.1-sources.jar
Download http://repo1.maven.org/maven2/com/google/inject/guice/3.0/guice-3.0-sources.jar
Download http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.3.7/groovy-all-2.3.7-sources.jar
Download http://repo1.maven.org/maven2/aopalliance/aopalliance/1.0/aopalliance-1.0-sources.jar
Download http://repo1.maven.org/maven2/javax/inject/javax.inject/1/javax.inject-1-sources.jar
:myapp:eclipseJdt
:myapp:eclipseProject
:myapp:eclipse
I then opened my .classpath file and see that its been correctly updated with all the transitive dependencies defined in my dependencies closure back inside build.gradle.
However, there is not visual indication inside Eclipse that anything is wired correctly. With Ivy or Maven, you usally get something like a Ivy Repository Manager or Maven Dependency Library that automatically changes anytime you modify ivy.xml or pom.xml.
Most importantly, this just doesn't seem to be working! As you see above, Apache Commons Lang 3 is a dependency, but when I try to add org.apache.commons.lang3.exception.ExceptionUtils to a Groovy source file, Eclipse can't find it. I have already tried restarting Eclipse to see if that shook any bugs out.
Am I just not using this plugin correctly, or does it just not work? Using Groovy/Grails Tool Suite 3.6.0.RELEASE here, which is based on Eclipse Luna 4.4.
I am trying to use the library scala-io in my Eclipse environment, does anyone know how do I generate a jar file, or which folder to include in my eclipse so that I can have access to the scala-io library from my project ?
EDIT:
Q: How to incorporate an external library into scala IDE?
A: Two possibilities:
Leverage SBT to build your project; that is generating jar files and maintaining dependency
Including the generted jar files directory in the IDE, project -> Properties -> Java build paths.
hth.
EDIT #2:
I found this great plugin to generate all of your dependencies in one jar file sbt-assembly
http://jesseeichar.github.io/scala-io-doc/0.4.2/index.html#!/getting-started
shows how to start with sbt or maven or with prebuild jars provided by links.
You should try to get familiar with a build system like sbt. Its cumbersome to always manually add dependencies to eclipse, especially if you have dependency chains: scala-io needs scala-io-core and arm and file etc...
I'm added a dependence to my build.sbt (casbah). I did a sbt update, I did check my ~/.ivy2/cache directory and all jars are there. Do I have to add this ~/.ivy/cache directory to my Build Path and add the casbah as external Jar to my project? If no, probably no because I did try it, what should I do to be able to use this jar in my scala project?
EDIT
I found this instructions that helped me, but still a hack
Establish a simple project (general/project) named "IvyCache"
located at your ".ivy2/cache" folder just for library reference
purposes.
Establish a Scala project located at your "project" folder.
Add the following libraries to the Scala project by means of "Add
JARs" to the "Java Build Path":
3.a) All jars from "/IvyCashe/org.scala-tools.sbt" filterred by
"*2.9.1-0.11.2" or any other Scala/SBT version numbers.
3.b) A single sbinary_*.jar from "/IvyCache/org.scala-tools.sbinary".
3.c) A single test-interface*.jar from "/IvyCache/org.scala-
tools.testing".
Now your build files should compile within Eclipse.
The easiest way to manage this is to use the eclipse plugin for sbt. Then you can just say sbt eclipse on the command line any time you change the dependencies in build.sbt, and the Eclipse files will be automatically updated for you.
Doing it this way means that you will never have to manually configure your Eclipse build path. After all, sbt already knows how to construct the build path, so there's no reason you would have to do it manually.
After cloning playframework from github and importing java sources into eclipse there are a lot of build errors shown.
Running the goals from ant file in eclipse works fine as well as building from cli directly.
How can i resolve these errors in eclipse?
I took the following steps to import play into eclipse:
new -> other -> Java>New Java Project from Existing Ant Buildfile
select play/framework/build.xml
checking the 'Link to the build file in the file system' checkbox
Finish
The errors result from differences between eclipse internal build path
and classpath available for ant at runtime.
First Eclipse only imports rt.jar from system path. This may lead to
missing dependecies in javax.net packages (e.g.
javax.net.ssl.SSLException), which is located in jsse.jar. To fix, right
click on project->Properties->Java Build Path->Libraries->Add Library->
JRE System Library.
Second, play has dependencies to classes from ant runtime. To fix, right
click on project->Properties->Java Build Path->Libraries->Add
Library->User Library
There you have to add a new User Library (perhaps call it ANT) and add
all ant-jars from your ant installation (/usr/share/ant/lib/ worked for
me). Then add this user library to play projects build path.
From the Oliver's answer, I had also to add the jce.jar lib in my classpath.
It comes from the $JDK/jre/lib directory.
I have a list of Eclipse projects that I would like to compile based on the existing project configuration.
As far as I can tell, if an ant script could read the .classpath files, it would pretty much be able to infer the project dependencies and perform a "javac" compilation in the right order. This would save time in describing the same dependencies again in the ant script or a Makefile.
The dependencies I am interested in are JAR Dependencies, JRE dependencies, and inter-project dependencies. These are -- as far as I can tell -- part of the .classpath XML file.
Any ideas on how Eclipse project dependencies could used in an ant script?
Right click on your Project -> Export
"General/Ant Buildfiles".
Choose the projects and there you go.
Otherwise...
I have some experience with ant4eclipse and it is a hassle to get it stable.
Go check Buckminster or Maven Tycho for a good solution.
I'm currently using Ivy along with Ant, Eclipse and Maven.
I just love the way Ivy works.
Currently, we have a workspace with many projects using Liferay (with Tomcat) for the front-end and Glassfish for the back-end.
We were looking for a way to manage our dependencies a lot better than how we were doing it.
So I took Ivy, replaced all of the classpaths and deployment dependencies in eclipse and was able to build my application using 1 ivy file per project using either Eclipse or Ant.
Ivy integrates like a charm in ant and builds are done either from the workspace or by command line.
I strongly suggest you look at this avenue. Additionnaly, by adding Artifactory, we have a local repository in which the ivy files look for dependencies. This helps us maintain and rule which jars are to be used by developpers. Once everything is setup, we will build our application nightly using Jenkins and these builds will be using our Artifactory repository to resolve dependencies since our build servers do not have access to the internet.
Hope this helped
If you are running the Ant script only from eclipse using the "External Tools Configurations", you can add the variable ${project_classpath} to the Classpath.
Depending on if you are in a plugin project and dependencies you might need to add the
${eclipse_home}.
In case you get an error launching Variable references empty selection: ${project_classpath}, make sure the ant xml file or at least the project is selected. This is important.
I believe the ant4eclipse project provides support for executing Ant builds based on Eclipse metadata files.
However, in my opinion that is doing things back to front. You shouldn't have your build (Ant) depending on your IDE (Eclipse) environment. But it is useful if you can derive your Eclipse environment from your Ant build.
This is an approach used successfully in a team I worked in. We had a helper Ant target which applied XLST to project build.xml files to transform these into Eclipse .classpath files. Thus the Ant build.xml files were the single configuration point for our projects.