We Keep Coding

What is the difference between Jib and Jib-Core?

I was recently looking into Jib for my personal Java project I have been working on, but I just discovered something called Jib-Core. I went thru some of the documentation but I can't seem to figure out what the difference between them is, and when you would use one over the other. Is anybody well versed in the two of them?

Jib core is the underlying library that jib tooling is built upon. It is shared by jib-maven-plugin, jib-gradle-plugin, jib-cli and other third party integrations (like quarkus, sbt-jib, etc).
Jib (it seems like you're using maven) is actually the jib-maven-plugin, that is basically all the necessary code for jib-core to be used by maven to build your container. Like exposing configuration in your pom.xml and creating various goals for you to run.
We initially built jib-core to share code for all our products and also for tooling developers. We've had users use it directly to highly customize how they build container, but in general I don't see too many people using it like this.

How can a ninjaframework-web-application be split up?

I just started to develop a java web application based on the ninjaframework. Everything works great, but: With all the ninja-dependencies, the deploy-war has around 25MB. I really hope, I won't have to upload a 25MB java archive all the time - especially due to the fact, that the dependencies won't barely change as often as e.g. a stylesheet of my app.
Is there a practical solution to move the ninjaframework-dependencies to a separated jar? I am working with eclipse, therefore a solution that integrates in the IDE would be great.
So far, I have had a look into the maven dependency-scoping and have (unsuccessfully) tried to move the dependencies into a separated project and refer to the project with a system-scoped dependency (which I would in my understanding be able to deploy as a separated jar file). I currently fail at building this dependency-jar with maven - but I also wonder, if there are better approaches.
I deploy the application on a tomcat-server in a plesk installation

Another option would be to exclude libraries that you don't use. For instance if you don't use JPA you can safely exclude it from the build via Maven's xml tag.
Background: Ninja 4 potentially bundles too many libraries by default. That's cool, because everything will work out of the box without thinking about libraries needed. The downside is that the jar/war may be too big for what you want to do. There are discussions on the way to make Ninja more modular - feel free to chime in on our mailing list :)
But as written above - you can cut Ninja's bundle down yourself using Maven's exclude.

If you have to use all the dependencies, there is no way to avoid deploying them with your application.
You don't tell if you are deploying into a container (maybe Tomcat). If you do, you can try to deploy the needed libraries into the container and set the Maven scope to provided to avoid redeploying the libraries.
Having the libraries provided by the container has benefits, but it can also be a burden. Depends strongly on your deployment and operation processes.

Design a Plugin based java application

I'm trying to make a plugin-based application which means, besides the basic framework, other functionalities should be added with a plugin style.
The majar problem of such system, i think, is how to load new plugins at the runtime. I don't want to recomplie the whole project when a new plugin installed. Just like Eclipse, after new installation of plugin, the user only need to restart it.
So my first idea about that is using java reflection to load the class at the runtime. there might be some plugin configuration files, the system reads them and load the plugin classes with reflection. Maybe i can use the spring framework as well, because its Inversion of Control is just match my request.
Another idea i'm investigating is using the ejb container. when the plugins are ejbs, i can just pack them into jar and deploy them in an ejb container, then i can use jndi to access them. but it only works when the plugin are ejbs.
anyway, i'm a rookie in system design. so i post this topic and want to hear of your opinions.
btw. is there any good book about system design you want to recommand?
thanks alot in advance!

You may first look at OSGI and his implementation (Equinox for Eclipse and Apache Felix) but it would be easier if you give us more information of what you are trying to do.

Plug-in to solve what problem?
Designers of frameworks usually have deep domain knowledge that informs their design choices. Frameworks come about after two or three attempts to solve some problem; the earlier implementations give clues about how to abstract what's important into a framework.
Eclipse solves the problem of an expandable IDE (poorly, in my opinion). EJBs are transactional, distributed components that run in a container.
You've given no indication of what kind of problem you want to solve. Until you do, your ideas won't get very far.

How to modularize a (large) Java App?

I have a rather large (several MLOC) application at hand that I'd like to split up into more maintainable separate parts. Currently the product is comprised of about 40 Eclipse projects, many of them having inter-dependencies. This alone makes a continuous build system unfeasible, because it would have to rebuild very much with each checkin.
Is there a "best practice" way of how to
identify parts that can immediately be separated
document inter-dependencies visually
untangle the existing code
handle "patches" we need to apply to libraries (currently handled by putting them in the classpath before the actual library)
If there are (free/open) tools to support this, I'd appreciate pointers.
Even though I do not have any experience with Maven it seems like it forces a very modular design. I wonder now whether this is something that can be retrofitted iteratively or if a project that was to use it would have to be layouted with modularity in mind right from the start.
Edit 2009-07-10
We are in the process of splitting out some core modules using Apache Ant/Ivy. Really helpful and well designed tool, not imposing as much on you as maven does.
I wrote down some more general details and personal opinion about why we are doing that on my blog - too long to post here and maybe not interesting to everyone, so follow at your own discretion: www.danielschneller.com

Using OSGi could be a good fit for you. It would allow to create modules out of the application. You can also organize dependencies in a better way. If you define your interfaces between the different modules correctly, then you can use continuous integration as you only have to rebuild the module that you affected on check-in.
The mechanisms provided by OSGi will help you untangle the existing code. Because of the way the classloading works, it also helps you handle the patches in an easier way.
Some concepts of OSGi that seem to be a good match for you, as shown from wikipedia:
The framework is conceptually divided into the following areas:
Bundles - Bundles are normal jar components with extra manifest headers.
Services - The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects(POJO).
Services Registry - The API for management services (ServiceRegistration, ServiceTracker and ServiceReference).
Life-Cycle - The API for life cycle management (install, start, stop, update, and uninstall bundles).
Modules - The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).
Security - The layer that handles the security aspects by limiting bundle functionality to pre-defined capabilities.

First: good luck & good coffee. You'll need both.
I once had a similiar problem. Legacy code with awful circular dependencies, even between classes from different packages like org.example.pkg1.A depends on org.example.pk2.B and vice versa.
I started with maven2 and fresh eclipse projects. First I tried to identify the most common functionalities (logging layer, common interfaces, common services) and created maven projects. Each time I was happy with a part, I deployed the library to the central nexus repository so that it was almost immediately available for other projects.
So I slowly worked up through the layers. maven2 handled the dependencies and the m2eclipse plugin provided a helpful dependency view. BTW - it's usually not too difficult to convert an eclipse project into a maven project. m2eclipse can do it for you and you just have to create a few new folders (like src/main/java) and adjust the build path for source folders. Takes just a minute or two. But expect more difficulties, if your project is an eclipse plugin or rcp application and you want maven not only to manage artifacts but also to build and deploy the application.
To opinion, eclipse, maven and nexus (or any other maven repository manager) are a good basis to start. You're lucky, if you have a good documentation of the system architecture and this architecture is really implemented ;)

I had a similar experience in a small code base (40 kloc). There are no °rules":
compiled with and without a "module" in order to see it's usage
I started from "leaf modules", modules without other dependencies
I handled cyclic dependencies (this is a very error-prone task)
with maven there is a great deal with documentation (reports) that can be deployed
in your CI process
with maven you can always see what uses what both in the site both in netbeans (with a
very nice directed graph)
with maven you can import library code in your codebase, apply source patches and
compile with your products (sometimes this is very easy sometimes it is very
difficult)
Check also Dependency Analyzer:
(source: javalobby.org)
Netbeans:
(source: zimmer428.net)

Maven is painful to migrate to for an existing system. However it can cope with 100+ module projects without much difficulty.

The first thing you need to decide is what infra-structure you will move to. Should it be a lot of independently maintained modules (which translates to individual Eclipse projects) or will you consider it a single chunk of code which is versioned and deployed as a whole. The first is well suited for migrating to a Maven like build environment - the latter for having all the source code in at once.
In any case you WILL need a continuous integration system running. Your first task is to make the code base build automatically, so you can let your CI system watch over your source repository and rebuild it whenyou change things. I decided for a non-Maven approach here, and we focus on having an easy Eclipse environment so I created a build enviornment using ant4eclipse and Team ProjectSet files (which we use anyway).
The next step would be getting rid of the circular dependencies - this will make your build simpler, get rid of Eclipse warnings, and eventually allow you to get to the "checkout, compile once, run" stage. This might take a while :-( When you migrate methods and classes, do not MOVE them, but extract or delegate them and leave their old name lying around and mark them deprecated. This will separate your untangeling with your refactoring, and allow code "outside" your project to still work with the code inside your project.
You WILL benefit from a source repository which allows for moving files, and keeping history. CVS is very weak in this regard.

I wouldn't recommend Maven for a legacy source code base. It could give you many headaches just trying to adapt everything to work with it.
I suppose what you need is to do an architectural layout of your project. A tool might help, but the most important part is to organize a logical view of the modules.

It's not free but Structure101 will give you as good as you will get in terms of tool support for hitting all your bullet points. But for the record I'm biased, so you might want to check out SonarJ and Lattix too. ;-)

Projects with browsable source using dependency injection w/ guice?

I often read about dependency injection and I did research on google and I understand in theory what it can do and how it works, but I'd like to see an actual code base using it (Java/guice would be preferred).
Can anyone point me to an open source project, where I can see, how it's really used? I think browsing the code and seeing the whole setup shows me more than the ususal snippets in the introduction articles you find around the web. Thanks in advance!

The Wave Protocol Server is my favourite example app.

I struggled a bit with this exact issue. It's so abstract and simple I was always worried I was "doing it wrong".
I've had been using it in the main project which has dependencies on other projects because the Guice module which sets the bindings was part of the main project.
I finally realized the libraries should be supplying the Modules themselves. At that point you can depend only on an instance of a Module (not a specific one), and the interfaces that are bound by it.
Taking it one step better, you can use the new ServiceLoader mechanism in Java 6 to automatically locate and install all Guice modules available on the classpath. Then you can swap in dependencies just by changing class path (db-real.jar vs. db-mock.jar).

I understand you're in Java-land, but in the .NET space the are several open-source apps written using an inversion of control container. Check out CodeCampServer, in which the UI module doesn't have a reference to the dependency resolution module. There is an HttpModule that does the work. (an HttpModule is just a external library you can plug in that handles events in ASP.NET, in CodeCampServer the UI project loads this DependencyRegistrarModule at run time, without any compile time reference to it.)

I think dependency injection has a way of disappearing from view if used properly, it will be just a way of initializing/wiring your application -- if it looks more fancy than that you are probably looking at extra features of the framework at hand, and not at the bare-bones dependency injection.
Edit: I'd recommend actually starting to use it instead of trying to find examples, and then come back and post questions here if you can't get stuff to work like you'd think it should :-)