LimeWire Code Update

[Sam]

Hi Folks,

We've just committed a major change to the structure of the LimeWire code. The major change is the introduction of a new module, 'components', that is a collection of commonly-used code. These components are independent of the LimeWire product, but designed to make developing a client-side Java application easier. We've gone through a lot of steps to make sure that this change doesn't make it harder for people to use LimeWire for the first time.

Over the course of the week we'll be updating the Wiki (although you're welcome to help out and do it first!) to reflect the new & improved way of getting LimeWire.

The new, easiest, way to get LimeWire is to checkout the 'limewire' module from CVS. The 'limewire' directory that's created can immediately be added to Eclipse as a project, and will have everything setup to use LimeWire. You'll still need to create a 'run target' as before (if you want to run LimeWire from within Eclipse). There should be no warnings & no errors in the project that's created.

Please let us know how this effects you, and if there are any changes that would make things easier for you.

Thanks!

[Sam]

This is a dependency graph of the way LimeWire is setup.

'core', 'gui' & 'tests' are just as before. (Not shown is 'lib' which contains various jar files.) New is 'mojito' which is the upcoming DHT. Also new are the various components, 'collection', 'io', 'security', 'setting', 'common', and 'test-util'. These components are required to build & run LimeWire.

http://www.limewire.org/limewire-dependencies.png

[jum]

Oh well, lots of conflicts and quite a few changes to get the build procedure working again. Will take a bit of hacking to get that up and running again.

[jum]

Doing a clean checkout gives me the following error in Eclipse:

Severity and Description Path Resource Location Creation Time Id
Project limewire is missing required source folder: 'components/collection/src/main/resources' limewire Build path 1168311548802 226347

I did use the following command to checkout:

cvs -d :pserver:guest@cvs.limewire.org:/cvs checkout limewire

As opposed to the web page http://www.limewire.org/checkcode.shtml
I had to insert a space after the -d argument. The page should be updated say a thing about the new layout as well, I suppose.

[Sam]

Yup, we're going to update that. Sorry we rolled it out before all the documentation was updated... We'll definitely get it clean by week's end. Over the course of the next few months we'll probably be moving more utility classes into the various components. What's there now is the minimum required to be able to compile the Mojito DHT without requiring the rest of the LW classes.

We'll look into Eclipse not working automatically -- I think Steffen checked in some fixes for that, so it might be working now. If not, it'll be fixed by tomorrow night. I have to update the ant script also to make sure certain directories exist before they're referenced.

Very sorry about conflicts & troubles with setting up scripts again... We knew this would be a problem, but went to a lot of pains to make sure it was as little a problem as possible. All the components, as well as core, gui & tests now contain maven pom.xml files, so the components can be described using maven pretty easily. There's also a build-macros.xml file in components/common that contains a bunch of commonly used targets for the components.

We're trying to move towards a codebase that's much more cleanly separated. After years of building up LimeWire, it got to the point where understanding anything required understanding how everything else used it and altered it. Breaking the code into tiny libraries forces a different understanding of the code, and lets people grasp it easier, since it's in chunks.

[Sam]

The Wiki & other .org are now updated to reflect how to checkout & build the new LimeWire. Please let us know if they're missing anything (or fix it yourself!).

[jum]

I am probably too dumb to get that working, I updated the CVS tree I checked out yesterday (using the limewire module) and Eclipse still mentions that it is missing components/collection/src/main/resources. Any clues what I am doing wrong?

[Sam]

Sorry I forgot to update the Eclipse portion -- will fix that in a minute.

[Sam]

Is fixed now.

[verdyp]

The schema abose is already a bit outdated:

actually the Mojito module has been componentized too, into two new modules, "mojito" and "mojito-ui", which were both moved within "components".
As well the two modules "nio" and "statistic" were added into "components" (and removed from the "core").

Personnaly, I have setup the components module as a single Eclipse project: to avoid compilation errors due to package naming, you just need to specify the source subdirectories instead of the project directory:
component/*/src/main/java
component/*/src/main/native
component/*/src/main/resources
component/*/test/main/java
component/*/test/main/resources

But the "mojito-ui" subcomponent requires an additional source subdirectory that does not conform to this naming scheme:
"component/mojito-ui/misc/java" instead of "component/mojito-ui/src/misc/java"
which would be included in the list above (where "misc" replaces "main")
This subcomponent contains a separate demo of the Mojito DHT and classes implementing a complete Mojito DHT graph viewer (I still can't link it within the LimeWire GUI, but this is probably the reason why this it is named like this, and the "Tools/Mojito Arcs View" menu item in the LimeWire GUI is still disabled; as this is a recent addition to the project, this visual component is probably still in work, and its "misc" classes -- the DHT Routes Visualizer and the DHT Tiles Visualizer -- are just experimental; I don't know exactly what they are supposed to demonstrate).

Anyway, the RoutesViewer is working separately, but the graph which is built has a strange dimension and is not centered (sometimes I get a graph that goes outside of the limits of the viewer plane, with nodes too low and too much on the right, and I need to unzoom and move them around manually); also the graph may probably be more compact, as there are very large unused white areas, but I know that computing a 2D graph from an internal graph is a known very difficult problem solved only by non-optimal heuristics; at least the graph is readable, it does not seem to have overlapping nodes, and arcs don't have too many intersections.