I run into this obstacle when my debugger steps into some classfile
without corresponding source. Finding it is often difficult:
You have to search for the site hosting the respective project,
and find its ``download source'' page (for instance, last time I searched
for the JPA API, and it took me hours to obtain the sources). Or, you might
be required to check it out from revision control.
You need to know the exact version you are using. Otherwise
the debugger might step into comments and empty lines :)
There is no convention for packaging source code—some
projects include it in the jar itself; some provide a separate zip file;
others put it in a src/ subfolder within the zip.
I know Maven has the capability of downloading source from its repository and
including it in the src paths when an IDE config file is generated. But
Maven's repo is so poor in terms of content—few libs actually have
their source uploaded.
Why is it so complicated when it can be made straightforward? We could have
some central repo which relates a classfile (or a hash thereof) to the source
file it was compiled from (or a link to it). Maybe a rather huge repo, but
pretty simply structured. An IDE plugin could query it to fetch what's needed automatically.
Have you, guys, experienced the same?
How do you obtain the sources to attach?
Both m2eclipse and IDEA will download the sources and javadocs for any dependencies. The m2eclipse sources can be downloaded by right-clicking on a dependency (or the whole project if you want all sources) and clicking Maven->Download Sources.
On newer versions of m2eclipse you can also automatically download sources by going to Window->Preferences...->Maven, then selecting the "Download Artifact Sources" option. When you open a type in a dependency jar that there are currently no sources available for, Maven will download the sources in the background and update the source attachment in the background.
Haven't seen a satisfactory solution myself.
I tend to roll my own repo, without Maven (Maven is fine, but it doesn't click with me). I run something similar to the BSD ports system, that is, one big structured tree that contains little Ant build files. These build files either checkout the source of a project, pull its dependencies from somewhere else in the tree and build it (these are for the projects I want to build- i.e., mine) or pull binaries from somewhere else (which might be an external source or my own binaries repository).
The system could easily be extended to pull src jars, but I do that manually now.
it may be complicated but it is worth the initial effort.
i do it the following way:
in my project directory i have three major directories,
src (my own)
lib
suppl (sources / javadocs when no sources exist)
i put in suppl one zip file per library, containing the sources. in intellij this gives me not only debugger superpowers, but also javadocs.
you are right, obtaining the sources is a pain. sometimes the sources come deliveded in the .jar file of the lib, sometimes as a seperate download (my favorite) and sometimes i have to create a seperate cvs/svn dir where i can checkout the sources. i usually need to re-package them the way i like them, even if provided in a zip.
i am sceptical about maven. i just don't like to hand over my decisions about choosing libs to a program.
we do something similar to Andreas. Our lib directory has subdirectories categorizing further. One such sub dir is source or debug which has the source JAR/ZIPs of all the jars that we want to debug. Do it once and you're good. We use an IVY repository for the jars and source jars.
This is all done automatically if you use M2eclipse (http://m2eclipse.sonatype.org).
Related
Hello so I'm working on a Java project for a class, using Intellij. My teacher does not want an SRC folder or anything else that Intellij makes on the Github Repo. Would it be possible to initialize a git repository in the SRC? or would it create problems for Intelj
There are several possibilities to approach this problem:
Create the git-repository in a separate folder. Note though that this approach is a bit tricky to get right! There are actually two options for this:
git --work-tree=<project-location>/src to use git from a separate directory.
git --git-dir=<rep-location> to use the specified location for the repository. This will require you to use --git-dir every time.
Initialize the repository inside the src-folder. This one for sure is ugly, but IntelliJ shouldn't care at all about any non-java files during compilation and if it still complains you could even exclude the directory from being compiled
Use a .gitignore-file to exclude files from VCS. This would leave the src-folder in the repository, but apart from that you can exclude any file you feel like from being versioned. (See the official documentation and #CrazyCoders answer for more details on this)
Do something funny with symlinks. I.e. create the repository somewhere else, place a symlink in the src-folder and use the repository via the symlink.
Check this page. You can exclude IntelliJ IDEA project files (.idea directory and .iml files from the version control).
Here is the sample .gitignore for IntelliJ IDEA projects that you can adjust for your needs.
I"m going to have to re-organize my directory/folder structure in order to use git with Eclipse, since repo's are not supposed to be located within the workspace.
Being a git newbie I'd like some confirmation that my intended structure makes sense before I start re-organizing and init'ing repos.
My current workspace includes an Android project, a GAE/J project, some common code shared between them. Aside from some 3rd party libraries, my projects are closely related so I'm going to put them into a single repo.
Here is my proposed structure:
root_dir/
workspace/
.metadata
.git (<--- main git repo for my projects)
GAE_Project/
.project
src/war/etc.
Android_prject/
.project
src/bin/etc.
Shared_Code_Project/
.project
src/etc.
3rd_Party_Lib_Project/
.git (<--- has its own repo)
.project
src/bin/etc.
Based your proposed structure, it would seem that all the projects under workspace is in one repository. Your proposed structure is fine with one caveat that I can see. You may have to ignore the third party project because it is located under workspace (which is the Git repository).
Eclipse projects do not necessarily have to be located within the workspace directory. It can be located anywhere on your system. It may be better to place the third party projects in a different directory.
As long as your repos are outside of your workspace, it doesn't matter where they are relative to the workspace. In your example root_dir contains the workspace and your projects, and I wanted to point out that the workspace could be at /some/random/path and your projects could be /at/totally/different/path, it shouldn't matter where they are relative to each other.
I keep my local repos in ~/dev/git/ in unix and /c/dev/git in Windows.
I keep my workspaces wherever Eclipse wants me to keep them, which is the first directory it pops up for me, sometimes ~/Documents/workspace, or %USERDIR%\workspace. Usually I don't even know where my workspace is, and it doesn't really matter, because the important and interesting part is where my code is.
I am working on a Hadoop project in Eclipse that depends on another one of my projects; I've included the other project in my build path, but when I export the dependent project, it only contains the classes from that same project.
Ordinarily, this would not be a problem, as I could just link the other project with the -cp flag, but Hadoop requires you to pass the jar as an argument, meaning that all of my dependencies must be inside that jar.
Is there a way, in Eclipse, to automatically build and include classes from projects that you depend on?
Thanks.
You coud use Ant to automatically build, test and export. It needs some time learning it, but its worth.
There are possible tasks (fileset, zipgroupfileset, copy) to include files, jars (unzipped) or anything into the final jar. By this way you definitly know whats inside your distribution jar and you don't need an eclipe installation running.
I suggest you take a look at maven as a build tool. You define the dependencies and build steps for each of your projects in files called pom files. The maven plugins for Eclipse (the m2e plugins) can take the configuration in the pom file and setup your Eclipse build paths and project description so that you can access the classes in your other project in Eclipse. Maven can also create a jar for you that has the classes from both projects (a "jar-with-dependencies").
In maven terms, your two projects are called "artifacts" with one having a dependency on the other.
The one downside to maven (and the cause for many negative comments about maven) is an initially steep learning curve that can be frustrating. What you're trying to do, however, is very straightforward and I expect you can find a number of examples showing you exactly what you want to do.
The first step, and that's what my answer is about, is to take a look at maven. It may seem overly complex, but it can scale to handle just about any build configuration you need as your hadoop apps get more and more complex.
You can export a project as a Runnable jar, which can be useful if you want a single jar, with dependencies included.
Select the Project. File > Export. Select the Java section. Select Runnable JAR file.
See related answer:
Eclipse: How to build an executable jar with external jar?
Post ADT 17, non-Android libraries need to be included either in the "libs" folders of the project or exported via the "Order and Export" tab in the build path. What's the difference (if any) between importing a library externally:
And internally:
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
How do you add external jar dependencies into your Android project's build path (internally or externally) make no difference on the actual build process (more specifically at compile and dex step), all it does is to tell build process where to looking for the required jars at compile and dex step.
The Android Dependencies element shown in Java Build Path - Libraries window is just another abstract layer that ADT plugin used for managing/grouping jar dependencies. where your external jar files (in your case android-support-v4.jar) appears (inside or outside Android Dependencies) in that window makes no difference.
Since r17, dependencies management has been much improved, and it is recommended to use libs/ directory store all jar dependencies (refer to you internal way), which is considered as a automation approach (as ADT plugin becomes more smarter now), see Revisions for ADT 17.0.0:
New build features
Added feature to automatically setup JAR dependencies. Any .jar files in the /libs folder are added to the build configuration (similar to how the Ant build system works). Also, .jar files needed by library projects are also automatically added to projects that depend on those library projects. (more info)
However, you can still use the old way (refer to you external way) if you prefer, which is considered as a manual approach (as ADT plugin was stupid before), see Recent Changes for r17 Release:
Important: If you are still referencing jar libraries manually instead of putting them under libs/ be aware of the following:
If the project is a Library project, these jar libraries will not be automatically visible to application projects. You should really move these to libs/
If the project is an application, this can work but you must make sure to mark the jar files as exported.
Is there an advantage to importing a library in a way that it is included in the "Android Dependencies" group?
Automation vs. Manual from dependency management perspective, automation is always considered as more errorless than manual in the world of computer science.
The number one, show stopping, 'I can't believe they didn't test this', disadvantage of putting external jars in the libs directory is that you can't set the javadocs location for them, as the option shows as 'None (non modifiable)'.
Hence I still use Export option in build properties
It has to do with library dependency management of Android. for details see http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
From the Eclipse FAQ
An internal resource resides in some project in the workbench and is therefore managed by the workbench; like other resources, these resources can be version managed by the workbench. An external resource is not part of the workbench and can be used only by reference. For example, a JRE is often external and very large, and there is no need to associate it with a VCM system.
So, quite simply, if you want to be able to manage a JAR as part as the project, exposing it to SCM and such, then treat it as a internal resource otherwise, treat it as a external resource. It will not make any difference in the APK produced in the end, its simply a eclipse thing.
If you want to avoid creating a copy each time you want to use your library, treat it as a external resource. But, can I suggest you look into maven and the android maven plugin, maven has a bit of a learning curve (especially if you are used to "make" or "ant" style build scripts), but it is very much worth the effort.
I am new to maven and ran into the following question/problem:
Given Hibernate as example: When I use maven, I can easily mange dependencies by including Hibernate as a dependency. The jars are manged perfectly. But Hinbernate consits of quite a lot of other (config) files that are required to get it running (like hibernate.cfg.xml).
1.) Does Maven provide any solution to also download these files (so I can use them as a basis for my additions. It would not make sense writing these complexe xmls newly from the scratch). => For Example is there "goal/target" in maven that spits out these required "relataed config" files into a specifc directory?
2.) How do you handle this case? Although I use mave, does this meand that I neverless have to download the common zip/gz Project-Files that used to contain these files? (As i did it in the past)=>So maven only manages/solves a part of the "problems" that I have in this regard.
Update: The files I am talking about are normally files I need to edit quite often (configuration files). So they are mostly not provided as a static config file inside the jars.
UPDATE 2 => Real live example: I just started to write a POM for my project and googled the dependency-names, like "hibernate-core", "hibernate-validation", "rome" (RSS Lib), "tuckey" (Rewrite Filter) and included them in my POM. Now I have all the jars downloaded via maven (great!), but however I do not have any (sample/base) config files. The Web-app can not be run...
Formerly (when I did not use maven) I downloaded the official distribution zip/gz package and they contained everything: jars and sample config files. Ok its great that maven helps me with the jars, but in the end I do have to navigate to every project webpage and also download the zip/gz distribuation package (as I did before) to only get the sample config files to include them in my project and then make some smaller changes... (without hibernate.cfg.xml hibernate does not start and writing it from scratch is an absolute nightmare, the best solution is take their sample file and update some specific stuff...
Thank you very much for any advice.
Markus
Most people handle this by including files like this inside their jars and referencing them via classpath.
If this doesn't appeal to you, and you have a bunch of them, the Maven solution is (a) use the assembly plugin to combine them into a jar or zip or tar; and attach the resulting item as an artifact with a non-empty classifier, and (b) use the maven-dependency-plugin to download the artifact and unpack it under target/something.