We Keep Coding

Exchange vars between API and software's core

I am developping a screenshot software which can load plugins from JAR. Thoses are developped using the API package, which is made of interfaces to implement, so the person who wants to make a plugin does not have to use the full source code.
This works well for adding like action (Upload to X or X host for example), but what if I want to send variable the other way around, like from a plugin TO the core ? How am I supposed to do this?
The only solution I can think of would be to use callbacks, but I don't find this so clean...
By the way, is my solution to use interface that devs implements, which I then instanciate is correct ? Or there is a better way?

Your solution is the most common way to implement such a scenario. You give plugins an instance of a class (instantiated by core) and they can store it for future use (e.g. to pass data to the core or trigger another action). Normally name of such classes ends with Context (e.g. BundleContext, PluginContext, etc.).
Another pattern is to use a sort of Mediator class. A class with some static methods that plugins can use to send some data to core or trigger some actions. I don't like it and it's not a very clean solution, but it makes it much easier for plugin developers to access the API as they don't need to store the context instance and respect its life cycle. This pattern is used widely in IntelliJ IDEA architecture.
As you're developing a plugin based system, I highly recommend you to take a look at OSGi architecture and APIs. It can be helpful in this regard.

Java developing an app with plugin capabilities

I'm currently working on an application in Java that contains a core set of functionality, this has to be extended for several different purposes (~10 different purposes) and as such, the best solution that came to mind was the option to add plugins to expand the functionality when needed as opposed to having a different code base for each.
Is the best way of doing this simply creating an interface and extending that in the relevant plugins?
public coreCode()
{
// Core
doThis();
doThat();
// Call plugin code
plugin.doStuff();
}
// Plugin
public interface PluginInterface()
{
doStuff();
...
}
I've looked into JSF etc but due to work limitations (not spcifically authorized etc), they are sadly not a viable option.
--EDIT--
It should roughly work like this:
purpose A, B and C require a certain set of functionality and so plugin1 is developed for them, bundled with them and then deployed. purpose D and E require a different set so plugin2 is developed for them, bundled and deployed. etc.

For plugins you could create a certain directory where class files implementing a certain interface or extending a certain abstract class are located. Then you can create new instances of these classes and see if they are an instance of the abstract class/interface you want them to be, then make a certain list of them and give users the ability to enable/disable them. If they are enabled you can then cast and execute them.

I would suggest you to look into OSGi - a dynamic component model where applications are developed and deployed as a set of bundles/plug-ins that can be added, started, stopped and removed remotely without even requiring a reboot of the core/host application.
You can model your application on the Eclipse RCP platform (one the best implementations of OSGi) and create a head-less (without any UI) core RCP application. All other application functionalities would then be developed as plug-ins that can come bundled or added later on to your core RCP application in any combination you like (or your clients may request) even after the application has gone live.
If you're application would have a UI and you like the Eclipse IDE's look and functionalities like "New Project" Wizards, use of Perspectives to change the layout of Views, Workspaces, context-sensitive Help functionality and over-the-network updates through plug-in repositories etc. then it's definitely worth considering. Have a look at this RCP FAQ page to see if this fits your needs.
The only thing that put developers off is that it has a bit of a steep learning curve. The dependencies are always declared declaratively with XMLs and within the code all the components are so de-coupled that you always find yourself interacting with the framework more.
The use of JFace for building UI components puts a lot of stress on the separation between the Model and the View. So, while all of this translates to good application design it doesn't allow rapid application development if one is new to the framework. Most of its other complexities come from the fact that RCP just has so much to offer.

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 organize projects?

I've been working with Visual Studio for a long long time, but now I'm been requested to work on a Java web project. We've decide to use Spring MVC as framework, and we want to use Log4J (for logging obviously =P) and JUnit for unit testing. Now, in the "Microsoft way" I will create a Solution, and I'll add A web project and a Unit testing project; now that I'm usign Netbeans, is it possible to do like that? Or how should I organize my projects?
Thanks for sharing your experience!

Have you thought about using Maven as a way to manage your project? I've heard really good things about it.
You can find a list of what Maven is, exactly, here.
In short, it has the following goals (I took these from the web site):
Making the build process easy
Providing a uniform build system
Providing quality project information
Providing guidelines for best practices development
Allowing transparent migration to new features

Try to use maven, and there is a standard way for a project :)

In Netbeans you specify what type of project you want to create, say Java Web Application. Netbeans will then create the files and folders to support that project. Within the project view explorer, you can see the 'Test Packages' node, this is where you add java classes to support your unit testing. When you add a unit test, Netbeans will add a reference to the correct JUnit library to your project (you can see this on project properties > libraries > compile test).
For Spring MVC, the same goes. You add a dependency in Netbeans, either at project creation time, or from the properties dialog afterwards.
This is just tip of the iceberg. So I hope this information allows you to at least get started and you can return with more specific questions as you get further in.

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 :-)