Developing with IntelliJ 9.0.2 Community Edition, on the Mac.
This is a follow-up to this post about including jar files in an artifact, which has not received any replies. I'm hoping that the reason is that somehow, in creating my artifact (or setting my project settings), I unwittingly did something which people don't tend to do, and which is causing my problem, and that by asking people here to share how they create jar artifacts and set up projects, I will discover what it is.
To recap: I have a Java project which depends on two library files. I need to package up the entire thing, with the jars inlined (such that on doing jar -tfv <filename> I see ALL the classes listed, including the ones in the two libraries), into a single jar file. I can make an artifact, I can add the library files to the Output Layout pane, but I CANNOT, no matter what I do, I cannot get the "Inline Artifact" item in the context menu to be selectable (i.e. non-grey) when I right-click on one or other library file.
The thing is, making a jar which contains library files as well as the project code is NOT an unusual situation in the Java world! So I figure there are lots of IntelliJ folks out there who have done what I need to do. And I would really like to hear from you folks.
What project settings do you use? (be specific, please :-)
And exactly how do you set up your jar artifacts? (again, as many specific details as possible, please :-)
Clearly, I'd be particularly interested to hear from folks with similar setups to mine (above) who are successfully doing what I need to do.
Grateful thanks in advance, folks.
I don't think there is much you can do from inside IntelliJ, but there are several ways to do it from outside by merging the JARs.
See here: Selective jar packaging
Related
I'm currently trying to write my first own library. It's just for testing, I want to find out how libraries are written, compiled, distributed and used in order to prepare for some upcoming personal projects.
Yet, what really causes me to wonder, is why exactly my Javadoc isn't compiled with the Library. I know that comments and annotations are not compiled, but for example the JDK (which is basically a huge library) comes with a working doc as well.
I've tried to compile a JAR (libraries aree normally JARs, right?) from not the compile output, but the sources (so I had a JAR of .java files), but this failed to be included in IntelliJ. I could add it as an external library, but neither did it show up in my explorer, not could I import or use any of my classes.
I know there must be a mistake somewhere here, all libraries I've ver used, whether it was Java, C# or whatever else always came with a working documentation (IntelliJ shold show that on mouse hover), and I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
Thanks to everyone in advance!
Because it isn't needed, and would bloat the file size of the executable. If you have a library in C or C++, the documentation may be bundled in a zip file, but you won't find it in the compiled .so or .dll. One just holds the binary and resources needed for the project. The .jar is equivalent of that- it's the compiled output. Documentation is hosted/downloaded separately.
When you download the JDK, you're not just downloading a giant .jar. It includes other things, like documentation in the download.
I'd like to know how to correctly build a library that I can share with a team partner, so he just needs to download it, add it as a library in IntelliJ and has all the functionality, but also the documentation.
The short answer is that you provide your team partners with your project source code as well as the binaries. They then can configure their IDE (Intellij, NetBeans, Eclipse, whatever) with the location of the source code and the IDE will be able to extract the javadoc comments on the fly and render them as requested.
Sharing the source code also has the additional benefit that your partners can debug their (and your) code better. By themselves, javadocs are rarely sufficient for debugging complicated problems.
Alright, if everyone ever has this probelm again, here's a complete tutorial:
As #Gabe Sechan already said, the Doc is not compiled into the JAR for some valid reasons. Instead, I recommend you to add the following to your JAR:
module compilation output
content of "src" directory / alternatively: module sources
Build --> Artifacts --> All Artifacts.
Now, if you add your library JAR into a project, it will show "Classes" and "Sources" in the right tab, as IntelliJ automatically recognizes you've bundled both into the JAR.
Now, IntelliJ should show your documentation, as it lives within the source files.
If, for some reason, IntelliJ switches from its "fancy" documentation popup to unformatted plain text, proceed as follows:
Navigate to File -> Settings -> Advanced Settings, and in the 5th block, where it says "Documentation Components", just tick everything you find. That's gonna fix it.
Thanks to Gabe Sechan again, your answer helped me to understand what won't work, and finally I've found a way to make it work myself.
I just inherited a project I did not write so I'm trying to really learn how it works. It includes a lot of jars in the libs folder and I would like to investigate why many of them are there, or if they are necessary.
I am new to IntelliJ IDEA (although I am very familiar with Android Studio if that draws any parallels or is worth mentioning). Is there a way to check and see if a jar is used in the project, or see where its usages are? Thanks!
You can remove the jar from the classpath and see what breaks. You will very quickly find where that jar is used, and if it is necessary!
I want to start moving some of my projects onto github repos. I'm a little overwhelmed on how to organize the files on these repos. I want to make sure I do this right. The specific project I've been working on is a Java project I've been building in Eclipse. It is essentially an 'engine' of sorts, so the ideal outcome would be that people clone the repository and build onto it as their own project that uses the engine.
Here is my local project structure.
src
--com
----myName
------projectName
test
--com
----myName
------projectName
bin
config.properties
README.md
.gitignore
.classpath
.project
One of the first things I did was gitignore everything in the bin folder and all class files.
This doesn't really feel like the 'right' way of doing things. I'm just making guesses. Are there any standard conventions I can adhere to?
Also let me ask some specific questions
Is it okay that the java packages are creating many (seemingly redundant) subfolders?
Is it correct to ignore the bin folder? Or will that complicate the project if someone else was to clone it?
I want to say that the classpath and project folder should also be ignored, but they do reflect changes in files. Am I right in thinking that these should be commitable files?
Do I need to make any special changes in organization to reflect how this particular project is an 'engine' that I intended people to clone and use in their own projects?
I feel this is a simple concept I may be over complicating but I want to make sure this is done correctly the first time. Any resources that anyone can point me to regarding git repo organization would be appreciated!
Thanks in advance.
To what my understanding of things, you can do two things :
Share your sources as a Java Library wrapped in a jar file. You can avoid all this "how do i share" questions.
Or you can share the project in a software version tool, like GIT. Ideally you will have to provide to the clients two things : The code and a way to easily setup their environment for coding.
In your case
To share the code: The code is under your java source is under src and tests folders.
To allow other persons to setup quickly their environment for working : Let's see, you are using the build system that employs Eclipse, so you should study how to share a eclipse project from a machine from other. What i can tell you in advance is... i thing the bin folder is not necessary (2). But the .classpath and .project it is. That is necessary in order to open the project within the eclipse IDE... the problem is that your IDE perhaps has some particular library or classpath configuration that other Eclipse don't and problems may arise (3).
What i recommend is to share your project using an independent-ide builder. Like maven, for example. Yes.. you always depends on something.. is only a question of what is more easier, and mankind has prove that with things like maven it is more easy.
About question (1), is not bad as long it has sense.
and (4) I think not.
Using IDEA 9/10, I don't want to use MVN2 anymore (reasons mostly similar to http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html), but I enjoy some of the things that it provides. The most important point is having my library management include code and documentation automatically.
Jars are not the problem, because I can just throw a folder at IDEA and tell it that my "jars are there". Is there a way to place docs and source relative to that folder so that javadoc and source get detected by IDEA automatically?
(I don't want to check in ipr/iml any more, that just led to constant merge conflicts for us.)
There is no such feature at the moment, you always have to attach sources and documentation manually if your project is not managed by Maven.
Total Maven newbie, trying (along with the rest of a sizeable team) to convert a monstrous pile of legacy code from ant over to Maven. It's working reasonably well, but I'm having the following problem.
I have a project, let's call it Core, that at runtime needs to load some files checked in under some different projects, let's call them Resources A and B. The Core code is started in a certain working directory, let's call it core/runtime, and there's a properties file it reads in order to determine what to load from Resources A and B, complete with the relative path to the resources in question, e.g.
resource.ham=../../resources-a/files/ham.rsrc
resource.eggs=../../resources-b/files/eggs.rsrc
(Yes, I'm aware this is sick and wrong and we should be loading resources as resources, from a JAR via a classloader and maybe some sort of container or dependency injector or whatever. Not my idea, not my current problem, not on the table to be fixed now.)
(Seriously, please don't bother suggesting we fix the underlying problem. We know we need to fix the underlying problem. We knew we needed to fix the underlying problem before we switched to Maven, and before we switched to Maven the stupid hack actually worked. I know it makes you feel good, but it's not helpful. This is a ten-year-old codebase with tens of thousands of classes and believe me, there are plenty of more important things wrong with it.)
This relative-path hack is only an issue in Eclipse, during development; in the actual deployed application the files live somewhere completely different and are loaded in a somewhat more sensible way.
Anyhow, this all worked fine when these were vanilla Eclipse projects, so the directories in question had paths like:
c:\workspace\core\runtime
c:\workspace\resources-a\files
c:\workspace\resources-b\files
However, now that these are checked out as Maven projects, the directories are now something like:
c:\workspace\core\runtime # Inexplicably unchanged
c:\workspace\maven.8675309\resources-a\files
c:\workspace\maven.6345789\resources-b\files
Questions:
Can I make these maven.7762323 directories go away?
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Any solution has to be one I can check into SVN so the other developers on my team can use it out of the box.
Update
Okay, I figured out where the maven.[number] directories come from: When you select a parent directory in the SVN repository and say "Check out as Maven project", you get a maven.[number] directory corresponding to the parent, with all the actual projects as subdirectories. It would be very convenient, if only the code was actually all in the same parent directory, or even in the same SVN repository.
Can I make these maven.7762323 directories go away?
Where do they come from? What do you mean exactly by checked out as Maven projects?
(EDIT: As the OP wrote in a comment, these directories come from m2eclipse that allows to check out maven projects from SVN. I don't use this feature so I dont know much about it. However, after some googling, my understanding is that these names are kind of temporary and m2eclipse should rename them at the end of the checkout. Maybe something something went wrong with eclipse during the checkout. I'm not sure actually.)
If not, is there some way in Eclipse to get the path to a project directory, and then pass that as a system property in a launch configuration, or something like that?
Eclipse has a {build_project} variable that could be used in the arguments of a runtime configuration. Maybe {workpsace_loc} would be more appropriate in your case. The whole list is available with a description in the Arguments tab of a runtime configuration.
(EDIT: I'm still not sure I get the real goal but I have the feeling that using svn:externals could help.)
Okay, solution was to use {workspace_loc:project name} variables to set a handful of project directories as system properties, and use those to infer everything else. Now if I can just figure out how to get the ridiculous system for loading plugin JARs to work with Maven...