When a jar file that I am using changes names (usually the version number is what changes), is there a better way to update the name than deleting the old jar and adding the new in the Eclipse Java Build Path Libraries tab? What I am really looking for is a way to manage this whole upgrade process of downloading the jar, putting it in my project lib directory, removing the old one, and updating Eclipse. For instance, right now I am using the .jar, source, and javadoc from
cucumber-core-1.1.5.jar
and would like to update it along with its source and javadoc files to version 1.2.4. In fact there are four different version numbers used by six jar files associated with Cucumber - times three because of the associated source and javadoc files. And my project is also dependent on two other tools, which have their own set of jars and version numbers. How do I set things up so that I can just go in and reset these version numbers in a simple way in the Java Build Path Libraries tab? Or even better, just dump these new jars in a jar/lib directory and Eclipse should work, right?
If that's impossible, how do you suggest I handle version numbers. Do I have to learn how to handle maven or gradle integration with Eclipse, or have you found a simple way to manage upgrading your tool versions?
I looked at the Eclipse .classpath at the root directory of my project, and found that the source and javadoc locations are included there with the classpathentry tag. For instance, here is what I have for JUnit:
<classpathentry kind="lib" path="vendor/junit-libs/junit-current.jar" sourcepath="vendor/junit-libs/junit-current-sources.jar">
<attributes>
<attribute name="javadoc_location" value="jar:platform:/resource/myproject/vendor/junit-libs/junit-current-javadoc.jar!/" />
</attributes>
</classpathentry>
Notice that I am using "-current" anywhere that the files I downloaded had a version number. I originally did that because I couldn't get variables to work in a previous version of Eclipse. Now, I'm thinking that I could use this "-current" trick as part of a scheme to only enter version numbers in a single place, a Gradle file or Ant build.properties file.
Gradle has a very convenient way to download libraries and get them installed in the Eclipse build path. See jmruc's example at https://stackoverflow.com/a/17008509/1759555 . But I could find no evidence in the Gradle documentation that Gradle takes care of source and javadoc
My strategy for attacking the problem is going to be
use "-current" in Eclipse where the downloaded files have a
version number
download the files and change their names with Ant
use an Ant build.properties file to store the file names and version numbers in a single place for my project
Related
So the way I gather it, eclipse stores its project specific files in two or three hidden files such as:
.project
.classpath
are there more?
Do I sync the .project file through the version control? the .classpath? (I'd assume not). To be able to import a project easily, I'd definitively assume the .project has to be there :p.
So my problem seems to be that it's not just to create a project on machine A, put the entire contents of the project folder on some version control, and import it on machine B. It always seems like it works wonderfully (as it should) on machine A, and becomes a mess with invalid classpaths for libGDX jar files on machine B, and we have to manually fix these afterwards by going into each libGDX 'sub-project' (since it has one project per target platform) and link it to the correct gdx.jar, gdx-native.jar etc....
Can't this be automatic? Am I doing it wrong? A lot of people probably use libGDX, and they probably collaborate right? So how do you do it? :)
2 notes here:
I know this is a one time setup kinda thing, and once you do this, we un-track the .project .classpath files so they no longer mess each other up. But it's still a pain to do this for every project... I still think this should not be such a turn-off when starting a collaborative project with libGDX / eclipse.
I was contemplating making this question more specific about libGDX, since this is what I am using at this particular instant together with others, but it would seem to be applicable to most eclipse projects anyway.
OK, so I finally found a solution!
some info:
eclipse does support relative paths (since 3.5 apparently) for libraries and the build path. (I want to credit #VonC, here: .classpath and .project - check into version control or not?)
the libGDX setup tool creates an eclipse project for you (yay!), but it does so with absolute paths to the build path libraries (bad!)
solution:
apparently there is no nice GUI method of editing the .classpath file from eclipse that I could find (without navigating using the file browser), so open the .classpath file in a text editor, and change the path from absolute to relative like this:
"/some/absolute/path/to/project/libs/gdx.jar" ---> "libs/gdx.jar"
and here are my exact lib entries in the .classpath file for my project-desktop project (after making changes):
<classpathentry kind="lib" path="libs/gdx-backend-lwjgl.jar" sourcepath="libs/gdx-backend-lwjgl-sources.jar"/>
<classpathentry kind="lib" path="libs/gdx-backend-lwjgl-natives.jar"/>
<classpathentry kind="lib" path="libs/gdx-natives.jar"/>
These might be of interest due to them being relative paths (thus presumably identical to what others would want in many cases (libGDX cases!)).
version control?
Now (with relative paths) we can safely put all our eclipse project settings in our version control / repository, and anyone can just clone and run our libGDX projects with ease! :)
(I hope libGDX makes use of relative paths for their project setup tool in the future)
I am about to use maven to automate my builds. Unfortunately, I am not able to get all the features I want, even after reading several tutorials :(
I would be glad if somebody could explain a way I can achieve all my goals!
I want to automate 3 specific build tasks with several actions for a project from within eclipse, using m2e:
Build snapshot
compile
define current project version + date as version
build jar file
copy jar file into the local repository in the project path itself (ยง{project}/builds/)
Debug snapshot
build snapshot as mentioned above
copy jar file to plugins folder of a local test server
build another project the current project depends on, copy its jar file to the plugins folder aswell
launch server / connect to eclipse debugger (I know how to do that, the previous steps are the important ones)
Create release
compile
define current project version as version
build jar file
copy jar file into the local repository in the project path itself
create javadoc
copy source files and javadoc to an archive folder
increase the project version (for example v6 -> v7)
As mentioned I don't need a perfect solution, just a way to realize this ;)
(Annotation: Chaining multiple launch configurations is not a problem.)
Edit:
Which sections of the pom.xml do I have to modify to realize these steps and how can I invoke them using an eclipse launch configuration?
Hi based on your requirements i can say the following:
Build Snapshots
Building a SNAPSHOT is usually the convention during development cycle.
1.1 just using the conventions.
1.2 Date as version
This is a bad idea, cause Maven has some conventions how a version looks like (1.0-SNAPSHOT or 1.2.3-SNAPSHOT etc.)
1.3 Build jar file
Usually done by the jar life cycle (mvn package)
1.4 The local repository is on your home drive in ${HOME}/.m2/repository for all your projects. Technically you can do what you like but it's against the Maven conventions. The question is why do you need such thing?
2.1 Usual procedure
2.2 Usually a deployment is not a job for Maven but you can do such things by using cargo-maven-plugin (integration testing).
2.3 If you have dependencies between project you need CI solution like Jenkins to do such things otherwise you need to do this manually. But that is different from a multi-module build.
2.4 Integration testing different story. Depends on what exactly you like to do.
3.
1-7
The maven-release-plugin will handle such things except copying to the project path itself which is against the conventions. For such purposes you need a repository manager.
I can recommand reading these books: http://www.sonatype.com/Support/Books
I want to modify automatically the order on which classpathentry are written by the Maven Eclipse plugin. Is there a way to do that?
I want to do that for two reasons.
First reason: in my application, the interface org.w3c.dom.Node is provided by several third-party libraries (for XML processing), as well as the JDK (1.6). However, the version of org.w3c.dom.* classes provided by these libraries are quite old compared to the JDK. For example, the method Node.getTextContent() does not exist there.
Running mvn eclipse:eclipse on my project will place these library before the JDK container in the .classpath, using this method in Eclipse will result in a compilation error. So the idea is to put this line:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
at the beginning of the .classpath file.
The second reason (less important) is when I run mvn eclipse:eclipse, it always set my src/test/* packages before src/java/* ones, which bothers me a little (yes, I know that in TDD we develop tests first, but still...)
Technical information: Java 1.6, Maven 2.2.1, Eclipse plugin 2.8
Edit: There is a question here that could look similar to mine, but it did not help me as it only deals with the order for third-party dependencies...
See this post: Maven classpath order issues. I can confirm that the 2.9 plugin has fixed this issue (or allows you to futz with the config).
for adding jars, when i select Deployment assembly-add-java build path entries...i have nothing ....no jars are there to select....what should i do?Please send me the ans.
Building WAR/EAR's uses a different mechanism from the Java Build Path. You will need to include jar files specifically in this list to have it included in the generated file.
Can anyone explain where the Eclipse GWT plugin defines it's entry points?
In an attempt to get my old GWT project working again with GWT 2.0, I created a default GWT 2.0 project in Eclipse and was able to run it successfully. It's the one that asks for a name and calls the 'greet' servlet on the server, which responds etc... so far so good.
I then ported all the classes from my older maven GWT project over to this new GWT project in the hopes of getting the RPC calls to work. It had many dependencies, so I also copied over the maven pom.xml, commented out all of the gwt related plugins in the pom, and managed to get the Eclipse M2Eclipse maven pluging to recognize the pom and adopt all of the maven dependencies. All of the issues in Eclipse are now resolved and it looks good to go.
However, when I click on the GWT compile icon for the project, it pops up a "GWT Compile" dialog now asking me to "Add an entry point module". There are no entry points listed to choose from in this dialog. This is frustrating because I kept the exact same GWTApp.gwt.xml and moved my code into the previously-working auto-generated GWTApp.java class.
I can't imagine why the Eclipse plugin doesn't look in the GWTApp.gwt.xml file to figure out what the entry points are.
Can anyone explain how these entry points are defined or suggest why the project stopped working?
Thanks!
I'm certain the following is the problem and solution. I've been doing GWT for about 6 years.
Whenever you import an existing maven (namely from a Mojo-generated archtype, but probably others) project into eclipse, you will get a broken configuration which will not allow you to debug until you fix it. But the fix is simple. What happens is the build path will be set to exclude all files from '[proj]/src/main/resources', and this has the effect of hiding the [proj].gwt.xml module file from eclipse. So all the GWT dialogs that look for those modules can't see them! So you can't even create a debug configuration that works.
Here's the fix:
Right-click the project, and open Properties -> Build Path dialog -> Source Tab, and look for the one ending in '.../src/main/resources', and you will see it has excluded: . So highlight just that entry and remove the '', so that it reads "Excluded: (None)". Now the dialogs (namely the debug configuration dialog), for GWT will all see your module file, and everything will work.
Just to be sure, that wouldn't be similar to this case, where the exclusion filter was a bit too large?
<classpathentry kind="src" output="target/classes" path="src/main/java"/>
<classpathentry excluding="**" kind="src" output="target/classes"
path="target/base-resources"/>
I think that you may have an exclusion filter which is too aggressive on your "target/base-resources" directory.
It seems that you have an exclusion filter of "**". Won't that match everything?
You are right! This was the problem! :)))
I didn't know what the exclusion filter was and somehow it was added automatically during the development.
Thanks for the suggestions to my question - you prompted me to find the answer. I looked and did not have any exclusion filters but checked the Java Build Path in the project properties.
When I'd added the maven dependencies, it must have implicitly changed the defined source directory of the GWT eclipse project. (Probably to src/main/java or whatever that dumb long-winded maven default path is). Eclipse offered no hints that the Java classes were not on the project build path. Once I defined the src directory explicitly for the project, the gwt.xml module appeared in the GWT Compile dialog box!
On to the next hurdle... coz it still ain't working yet! :(
Thanks for your help!
Sonatype's eclipse maven plugin is infamous for many things. One of them is excluding all the files in your resources maven folder for a given module whenever you allow it to rebuild the eclipse classpath.
m2eclipse will probably be the single reason that I re-evaluate using Intellij...
I had the same problem.
Right click the project and select properties.....
There was empty dialog (no entry points suggested).
After some digging I found that mymodule.gwt.xml file was accidentally marked as "lib" in .classpath (eclipse project file in the root of the project folder). I seems it was marked as "lib" on .classpath automatic generation (I was importing clean maven GWT project, not eclipse project).
Simply delete line with mymodule.gwt.xml from .classpath file, cause it is in src/main/resources, that is normal "src" classpath.
Right click the project and select properties. Expand and select Google -> Web Toolkit. The right pane will have a section called Entry Point Modules. Click the add button and select your .gwt.xml file.