Simple JAR/Library repository

General Discussions
#1

Like most people I have multiple projects going. Some of them use similar external libraries (e.g. libgdx, guava, etc) and some projects are common code intended to be used as resources for other projects. Currently, I simply try to store my libraries under a common root directory. There are a number of things I don’t like about this set up:

  1. When I download libraries, I have to manually set up consistent directories to store them in.
  2. Every time I create a new project, I have to navigate up and down the repository directory hierarchy adding the jars I need and also attach the javadoc, source, and natives.
  3. Exporting my own common libraries into my directory structure seems overly cumbersome

What I would like is a simple system that:

  1. Allows me to add a library to my local laptop my specifying a descriptor and have it create the appropriate directories and copy the file(s) over. For instance something like:

add { 
	library-name: libGDX, 
	version:0.9.9, 
	source-dir: c:\users\actual\downloads\
	file:libgdx.9.9.jar, 
	source:libgdx-source.jar, 
	javadoc:libgdx-javadocs.jar
	}

  1. IDE integration: Allow me to select libraries from a flat list of projects in the repository and import them. It would also automatically find and attach javadoc/sources/natives as appropriate.

  2. Simplifies the exporting of libraries that I create by automatically adding them to the correct place in the repository, and including the javadoc/source attachments.

I have a feeling that what I am looking for already exists. I looked at Maven and Apache Ivy, but both seem intended to be used as entire build systems whereas I am looking for something much simpler. Maybe I am just not understanding them properly. Since I am a solo developer, I also do not need to run repository servers, etc. and I am fine with having to first download libraries to my machine.

Creating a simple repository API to add, remove, and query libraries doesn’t seem like it would be too hard but the IDE integration would be trickier. I currently use intellij, but am also comfortable with eclipse and netbeans.

Does anyone have any suggestions or thoughts?

(EDIT: Removed a bunch of white space at the end)

#2

In Eclipse you can add projects to the classpath of other projects (This should be available in other IDEs, but I haven’t used them), and if you put your libraries in the right place, attaching source and docs is easy.

#3

Yup, I can do that in IntelliJ too. I do like being able to deploy versions of even my internal projects rather than linking the source directly. This gives me more freedom to update the source without affecting downstream projects until I am ready to deploy. While attaching sources and docs are easy, it seems like something that a system could do for me.

#4

Well, if you can work out how your IDE handles projects, then it would be quite easy.

In Eclipse for example, you could just make an application that generates the .project and .classpath files and copies files from the filesystem into the appropriate directories.

#5

Just use a standard build system like maven or grandle, it has everything you ever wanted.

#6

Maybe it’s just me, but I hate anything that requires me to use gradle or maven or similar.

It spends 1/2 the time downloading itself and it’s dependencies that will never be used for anything else.

I like small, fast, efficient build systems.

#7

Yes it is just you, because every serious developer is using them.

I don’t want to start a flame-war about what might be the best build system here, but …
There are some matured systems out there, which are used by millions of developers, helping you immensely and are worth investigating/learning, because you probably will be required to use them in the future.

also back to the topic:
OP was asking for an solution and I gave him one which fits all his needs and isn’t proprietary IDE specific.

#8

You are someone who takes good solutions from other people to reach your goals without wasting time. This is senseful.
Other people prefer to make their own stuff so they could understand it as completely as possible. This is also senseful.
Please accept that.

#9

I have been reading up more on Maven repositories and it looks like setting up an “Internal Repository” may be what I want. There is a ton of documentation out there on Maven but so much of it seems impenetrable. My preference is to use something that already exists rather than write my own thing. From what I have been able to understand on how it is used, it might be worth writing a simple wrapper to interact with the repository outside of the scope of a project.

I know that Maven has those who love it and those who hate it. For me, my projects are small and simple enough that as long as the build system integrates into the IDE I think I will be fine.

#10

My problem is that to build a small application, I have to download a huge build system and loads of dependencies that will never be used for anything else. Now I wouldn’t mind too much if I had to do it once or twice, but there are so many build systems in circulation that it just gets ridiculous.

It’s like having a house with all the electrical sockets from different countries.

So in the end, I just make a script that does it for me. It usually takes up no more than a few kilobytes.

(Anyway, the best build system is [icode]./configure; make; sudo make install[/icode])

#11

[quote=“actual,post:9,topic:46460”]
There is no need to setup something like this, maven comes with a standard local repository. You also don’t have to interact with this repository in any way. When you are using maven you don’t need to download libraries from the web anymore, all IDEs have a library search function where you can find any lib from the maven central repository(nearly all libs in existence) and get maven to download them for you.

It is also the same for your own local projects, maven will copy your projects jars into the local repository after a successful build. So no more local copying of your own libs.

#12

Hi

Are you sure that Actual wants to make its own stuff? The both approaches you describe are “reasonable”. There is a time to learn and there is another time to be efficient by avoiding to reinvent the wheel.

I agree with Danny02 about build tools. If Maven and Gradle are too much “heavy” for you, use Ant. When I use Maven, it helps me to use a library without needing to ship it in my project, I can use the specific version or use the latest version, this build system is often rigid but it’s not always a problem. Ant is useful to write portable build scripts very quickly, it’s extensible (I use Ant-Contrib, Antelope and Jsch), it helps me to automatize my whole build from the compilation to the upload onto an SFTP server.

#13

I dislike maven as much as the next guy, on my personal projects I use ant and manual jar management and that is my conscious choice, knowing fully what that beholds.

However, I do use maven extensively at work, jar hell is a concept, we don’t know, everything just works (well, not always…) .
Maven itself is 3mb, it’s a single install and there is nothing more to download. All the downloads maven does, are project dependent, the dependencies come from the jar’s not from maven.
In the end, whatever You build or however You manage Your system, You are doing the same thing, just manually.

As long as You are aware of those things and don’t dismiss the tools as “bloat” (as do C developers dismiss java, cause its “slow” and “bloat” and “noone uses it” and “no real programmer would ever use java”) etc, just because, then whatever choice You make is fine. Just be aware of Your choices and approach openmindedly.

#14

Hmm, Some strange posts here. Maven doesn’t need to become part of your project. It’s more of a tool to assist you with creating your project (like using an IDE for example).

#15

Well, to fully utilize maven’s dependency management and whatever else you need, it’s best to integrate it with your IDE. IDE-maven integration is pretty good with all major IDE:s at least, at least when keeping in line with maven’s conventions/view of the world.

We also use maven extensively at work (and I use it for all my personal projects too); it’s definitely a polar love/hate relationship. If you love it, embrace it - else find something more likeable.