I have problem with new gdx-setup.jar. Now when You are trying to generate new project after choosing everything the gdx will generate whole project from You, it will even configure Build Path - there is where my problems starts.
So gdx is creating a path to its libraries something like 'C:/users/user/28193721946210/.gradle/ ...' and so on.
Now - I want to work on this project on another machine - I am sharing project between computers with bitbucket. I was trying to unpin these dependencies from build path and just import my own libraries instead but I can't do much in here. Gradle have only power here, but in fact - there isn't any path in gradle.build or something - I can't make him to use my won dependencies instead of the generated ones.
it will even configure Build Path ... creating a path to its libraries something like 'C:/users/user/28193721946210/.gradle/
This is correct, as Eclipse or any other IDE needs to know where the files are that it needs, on the actual, local machine.
However, these kind of platform specific settings are not static. They also should not be checked into any shared source versioning system.
If you are using git, the gdx-setup will conveniently generate a handy .gitignore file that will set all eclipse specific config files on ignore, for example .project or .classpath files.
LibGDX projects these days are built via gradle. That's why your IDE needs a gradle plugin to be able to read gradle configuration files, most importantly build.gradle, which defines the dependencies for your projects.
When importing those projects into your IDE, the IDE will parse the config files, understand which dependencies it needs, download them to your local machine and then setup a local build-path to those dependencies. However this IDE configuration can change when you trigger an update. In eclipse you do this for example via a rightclick on the project --> Gradle --> Refresh Dependencies.
Furthermore, it will setup the correct local paths on any machine you want to develop your game on.
Related
Using IntelliJ IDEA, it is often a straight-forward task to check out a project from GitHub and get it to build locally.
Once the base project is imported from GitHub, the IDE will download artifacts which will allow the main project to run. The dependencies can be examined by using File > Project Structure... > Libraries.
So the IDE downloads dependencies to allow running, but not to build from source. The IDE is able to decompile classes, but the IDE will not automatically download the source code for those dependency libraries so that the programmer can alter the code.
This question is about the steps required in the IDE and project configuration such that a selected dependency will be built locally, and thus allow the programmer to alter the code.
What I tried was to import the project on which the main project was dependent, as a separate project, then configure the main project to utilize the local project instead of the downloaded artifact. The first step, downloading the sub-project and getting it to compile, was completed successfully.
So I ended-up with two projects, the main one, and the one on which the main project depended. The task at hand, if this was the appropriate way to get this done, would be to open the main project and take some action to convince the main project to use the local build, rather than the downloaded runtime "jar".
First, I edited the POM.xml to comment out the dependency for the sub project. Checking File > Project Structure... > Libraries, I could see that it was gone, and the build now failed (as expected).
I went to File > Project Structure... > Libraries > + (plus sign) and poked around with New Module, and Import Module, but I was not able to convince the original project to use the locally available sub project. The result from various attempts was that code in the base project was not able to import from the sub project (unable to compile).
What are the specific steps to take in the IDE to get what was a runtime dependency "jar file" to instead to build locally, and use that instead?
Use a SNAPSHOT version for the dependency (you'll need to change this in both your project's pom.xml and the dependency's pom.xml, so if the current version is 2.0.0 change it to 2.0.0-SNAPSHOT)
Then you can edit the dependency's code and run mvn install in the dependency to provide the new version of the dependency to your project.
TLDR: there is no simple and straight-forward way of downloading a project's code and the code of its dependencies to rebuild it in one go as a complete chain.
Your project depends on several other artifacts. From the screenshot, we may assume that this is a maven project, at least we can be sure that there artifacts with compiled classes available for download, because this happends during build. You can view the compiled classes of your dependencies, because Intelli has the capability of decompressing jars and decompiling code, obviously, but the contents you are viewing is read-only.
Sidenote: Maven convention is to create 3 separate jars for each project. One with compiled classes, one with source files only and one with generated documentation. By default intellij may not download these, but you can force it (right-click on pom.xml -> maven -> Download sources and documentation). This will attach the actual source code instead of decompiled classes to your IDE, so it's much easier to understand the code - but still, there is no option to modify it - it's still read-only extract from some jar.
So what if you want to actually edit the source? You have 3 options, all with its own set of problems that need human intelligence to solve:
You extract the decompiled source from classes jar
You extract the attached source from sources jar
You check out git repository of the dependency
Now, beware of the downsides of each approach:
You can be sure that the decompiled source matches your project dependency 1:1. But decompiled code is not easy to read, missing comments, etc. Also, some projects may not ship their build scripts with the classes jar. Anything more complex than mvn clean install may turn out to be a blocker.
You can be reasonably sure the code matches your project dependency, but this actually is not a given. There is a chance of human error, causing the sources to actually not match the compiled classes (build from different revision or whatnot). Much depends on the quality of the project, the discipline put into the build process and care to avoid environment specific configuration that is not part of the source. The larger and older is the project, the less chances are you are able to recompile it successfully using only src jar.
A sane man's approach. You should have your build scripts, readmes, tutorials, etc. Except, of course, if we are talking some obscure company internal project with zero effort put in its maintenance. Surely, there are the same issues as before: not all projects are rebuilt easily on any environment. There may be steps upon steps required for your workstation to be configured as expected. Hopefully, self-respecting open-source java projects are easy to build, but again - not a given - not all project are open-source, not all are self-respecting.
Important note: When checking out the git repo of your dependency - you must also make sure that you are using correct revision. If the project is maintained with respect for git tags/branches naming convention - you are in luck. Not a given by any means.
All the above is enough to discourage any attempts to automatically decompose dependencies to compilable units by your IDE, and all the burden is put into you. So let's assume the best - our dependency is a simple, self-contained java application that is easily built using simple mvn clean install. You have it checked out in a separate project in your IDE. You identified correct git revision that matches version your project depends on.
Now let's apply your little change and test it. First thing you want to do is change pom.xml of your project to use a made up version of your dependency. It should be a -SNAPSHOT version for clarity and tidiness. You may of course build your modified dependency with real release version - but please be wary of how maven manages dependencies. If you install version 1.0 yourself - it stays in your local repo forever. You will forget about it, and will be using your fake 1.0 version when building all other dependent projects unless you manually locate and remove it from repo. So stick to 1.1-SNAPSHOT.
Now every time you need to apply a small fix to your dependency, execute mvn clean install in its repo, then make sure your actual project depends on the correct new SNAPSHOT version, execute your maven clean install and that's it.
Note that all this has very little to do with Intellij. You are not expected to modify any library paths, advanced project settings, or links to jars. Stick to modifying pom.xml and you are set.
i was on a 2-day training introducing as to Java EE. We used there Java EE, Spring Framework, Maven, Springsource Tool Suite (Eclipse), Tomcat.
I took the Eclipse workspace we created there and run it on my work PC. I had, if i remember correctly, only to configure Tomcat properly, and it worked on my PC.
Now i want to save the created Eclipse workspace containing 5 "sub"-projects in subversion so that my work colleagues can checkout this to them and run it on their computers.
How to do this correctly? I found somewhere a svn:ignore rule:
.classpath
.project
.settings
target
Using tortoiseSVN i added to the folder with the workspace this ignore rule, but the found out that the underlying folders target were'nt deleted so i deleted them manually and "added to ignore list". But after that the project in spring source tool suite does not see the mevan dependencies (i think so) because the imports are broken. STS underlines org. in the imports and says it can not resolve this.
How do i correctly version control such a project?
In my project we are using Maven and Eclipse (Helios, currently) and the Maven plugins for Eclipse:
Maven Integration for Eclipse
Maven Integration for WTP
We only have the pom.xml file and the src/ directory tree in our version control system. We make sure not to add the eclipse files there. Then when a new developer starts in the project they do Import -> Maven -> Existing Maven Projects. The Maven plugins for Eclipse then set up perfect build paths, settings and so on.
This way it is also very easy to re-import your projects into Eclipse as needed.
So, my tip is to leave the Eclipse files out of SVN and make sure you can setup the project correctly automatically simply by importing a Maven project.
If I understand your problem the right way, you need to configure Eclipse in order to be able to launch tomcat from it. The key, here, is not maven anymore, but Eclipse, I think. As you've made modifications in your workspace that can't be put in your maven configuration file (the pom.xml), you become "Eclipse dependant".
The key here is that, as you're Eclipse dependant, you need the Eclipse configuration files to work. Consequently, I'm afraid you need to add back .classpath, .project, .settings to your versioning tool... It's not generic, because you force people who work on your project to use Eclipse. But if everybody in your team do so, it shouldn't be a problem.
As I don't use Eclipse anymore, I don't know if versioning theses files can lead to problems. However, I hope this answer will help you to configure your project back...
EDIT : to be more accurate... and maybe give a better answer.
When using a version control system, the main goal is often (always ?) to give all the keys to use the sources, and develop from them. Consequently, you need to put in your VCS your sources, and all the configurations needed to use them efficiently.
In your specific case, the key is that you've become Eclipse dependant through its Springsource Tool Suite plugin. Consequently, it becomes essential to add the configuration files for this tool, because they can't work without them, and if they can't work, you can't work.
I can tell you my way of subversioning maven eclipse projects. First, when you create the project structure you have to commit the .setting, .classpath, .project files into the subversion repository. If you can't do this the other colleagues will can not use the project structure after checkout. After you commit the project structure, the best way is not to commit these files except only when you change something important eclipse or build path settings, because the others will have conflicts due to the system dependent informations. Never commit the maven target directory. Sorry for my english. Hope it helps.
I am using Eclipse IDE and its derivative like Spring IDE for Java development.
In a web application project, I add external jars like Spring MVC jars, Apache commons jars etc to the Web App library folder, hence they are automatically added to the build path. There are many jars in the Web App library folder.
I want to create folder in the project and add all the source files (zip/jar) of the libraries included in Web App library folder, so that I can navigate through the source of libraries from the Java editor window. Whenever I add a source zip/jar file to this folder, Eclipse should detect it and use it whenever I want to navigate to the source of a library.
Is the above possible in eclipse?
Note: I know how to add source files
for each individual jar by navigating
to the build path window and
specifying the source location. But
this is very crude way, and I need to
do for every library individually.
Also the drawback is that source path
is absolute, which means if I import
the project into another computer then
I need to create the source path or
even worse I might have to add the
source files individually again.
One way to automagically get the sources for the jars would be some kind of dependency management system. Most people would scream Maven (2/3) by now, but others exist and work well. Maven does have nice Eclipse integration, so that should be a plus.
The downside is that setting up a Maven project just for it's dependency management can seem overkill. Another point is that all the jars you depend on should be "Mavenized" as well.
As far as I know Eclipse wont automatically detect/scan source archive files and link them up to libraries in your workspace in the way you described it.
I agree with #Gressie on using Maven and the Eclipse Maven plugins -- as in that case it's just a matter of ticking a few boxes and Maven will do that for you.
If however your project is not Maven-ized, you can still do this in Eclipse but it's more tedious:
for each one of the jars in your project (which appear under the dependecies section) right click on it and select properties
in the dialog that pops up you have (at least) 2 locations you can configure: java source attachment -- simply browse to your jar with the sources -- and also javadoc location (point it to the jar with javadoc if you want the javadoc to appear as a tooltip when you hover the mouse over one of the classes/methods/etc in that library).
I have been working solo on a project for some time, and now, new developers are likely to join the project for various reasons.
I, of course, use a version control software but I am afraid importing my project into Eclipse and making it run might prove a little difficult for new comers, and I want to make it as clean as possible.
When I first took over the project, it took me almost two days to have the project built and run it, I documented every step and fixed the most obvious errors, but not all, and I want the project to run as it is when imported.
The project is a mix of java projects for the backend, a j2ee project for the server and a flex project for the client.
The IDE is going to be Eclipse
The version control software is Perforce
Here are some of the specific problems I have right now, should I fix them, and how ?
Eclipse environment variables are used for libs, all the libs are in a folder in the j2ee project but are used by all the java projects (they have to be set in each IDE the project is imported into)
Runtime JRE is specified in .classpath for each project, so each projects property must be edited when trying to build the project in another environment
Apache server is specified in j2ee project property
To avoid exporting the jars of all the java projects into the j2ee project each time I modify the code, there are linked folders in the j2ee projects, linked to each java project bin folders
For (4) I will probably have to use maven, but is it possible to fix problem (1) (2) and (3) without using maven ?
The alternative is to have a one page set up instruction document
Also do you have any other general or specific advices as to how organize this whole mess.
Thank you
Dependency management is a must - use Maven. If you can't use maven, because you are already using ant, go with Ivy.
Make the project buildable with one click - be int ant build all or mvn package. Maven provides integration with the IDE (via the plugin).
Don't reply on IDE metadata. like .project and .classpath. You can still commit them to ease Eclipse users though, but don't restrict the IDE.
Provide build-on-save. Either using Eclipse WTP, or using the FilSync plugin (it sounds like a hack, but is pretty cool)
Use build profiles (maven provides them automatically) - to create different builds for different environments
It's not always possible to configure everything in your maven (or ant/ivy) scripts. For any additional actions, like installing app server - document then in a single file in the root of your project, describing step by step what should be installed, with what config options, etc. Thus the developers have only one place to look at and follow. The document can (and better) be plain .txt
A sidenote: use Continous Integration - download Hudson or TeamCity and configure it to build a project
From my very recent experience - we had a project we've been working on for 6 months. A colleague of mine had to re-import the project on a new machine. It took him 20 minutes. The project is configured with Maven.
My project requires some external libraries to build in in Eclipse. They live in /trunk/lib whereas my project is in /trunk/projectA. To get Eclipse to find the libraries on all machines we set a variable PROJECT_A_HOME.
Now I'm trying to get some builds going with maven and I can not figure out how to add that path (be it environmental variable or relative to $(basedir)) to the build. I really do not want to set up a repository for these dependencies, as I keep them in source control and want builds to continue to work in Eclipse.
I've seen talk about but that hasn't worked for me.
Ideas ?
You should put your static configuration files in resources/ dir. If you have your own or proprietary jars you should set a your own repository so you can download them from the repository or better yet just install them manually , here is how
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
Setting up a file-based repository as suggested in this previous question would allow to keep the libs in your version control system and work seamlessly at the Eclipse level (the libs would be treated like any other dependency). The only problem I can think of could be at the continuous integration level: a build of projectA would require a checkout of trunk/lib. Many CI tools would allow to implement this though. And if not, moving the libs under projectA (or another mavenized project project if you need to share them between modules) would do the trick.