Slick Forums

I agree with @R.D. The only advantage I see here is allowing other devs to use just specific parts of the library. However this isn't really a necessity either. The size of Slick is incredibly minimal compared to other libraries. Organisation of components is not a priority on my list

_________________
Liam (liamzebedee) Edwards-Playne
Cryptum

Hey, no offence. I am just proposing things I had to learn the hard way.

My project was originally one large project as well. Containing multiple applications as well as shared code that were at the end split into multiple jar filed for the different applications. The problem that happened very often was that parts of the game client used parts of the map editor (all thanks to the dependency resolution of Eclipse -.-). Within the development environment everything worked just fine as all the sources were available. Also the ANT buildscript did not took notice of this problem as the entire project was compiled and after this the compiled binary files were split into the jar files. No errors, all cool. But once the application was started those nice "java.lang.ClassNotFoundException" came down on me. In the end I split the project into multiple projects that had a clear dependency structure. And since then: no more problems.

My sole intention was to avoid that just the same thing happens here.

Nitram

_________________
http://illarion.org

Slick should still be modularized for the reasons I gave earlier. Especially for the sake of slick-util.jar, which IMO is going to be the future of Slick now that LibGDX supports HTML 5 rendering.

I'm starting to agree that multiple projects might be the best way. It may introduce more "clutter" in the sense of a fragmented folder structure, but it would also clearly separate sources. And if users wanted to pull slick-shader (for example, a LWJGL user) then they don't need to pull all of the other junk with it.

Of course, this means that things like slick-gui and slick-particle would not be very useful to the straight LWJGL developer, as they would also need to depend on slick-core. These packages would be more useful for removing clutter for those depending more heavily on Slick.

In the end, I feel that our priority at the moment should lie in fixing bugs and RFEs that have been gathering dust in the BUG/RFE forum, and improving features of Slick that are severely lacking. I would like to "re-introduce" Slick as a modularized set of utilities to the LWJGL community, as it would be useful for many of them, but we shouldn't do such a thing until Slick is a bit more stable, optimized, feature-complete, etc.

It's true the it would be nice for the user when he just want's a specific part of Slick. I still think it's a bad idea ( how does it works with SlickAE since it references Slick and so on) but I would suggest making a new branch where this stuff could be tested.

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Slick-AE is implemented in exactly the way I suggested.
The eclipse project "knows" about the dependency between Slick-AE and Slick and makes all compiled sources of Slick available to Slick-AE during the development. (There is no need to implement sources twice or anything like this).

And to avoid running into more missunderstandings I will split slick into some atomic projects in my fork in bitbucket. If its still rejected then... so be it, we just don't pull it into the main repository when. But at least we are all talking about the same thing then.

Nitram

_________________
http://illarion.org

Okay. I extracted two sub-projects from the main slick project.

Namely SVG and Pathfinding.

To be seen in my repository fork here: https://bitbucket.org/Nitram0815/slick/overview

I created the required Eclipse project files along with the build files.
The current result is that the slick-pathfinding.jar and slick-svg.jar contain only the parts the names suggest. Slick.jar still contains everything as I extended the normal building progress with merging both atomic-jars into the main slick.jar (for backward compatibility). That does not sound that useful now, but that is only because slick-core.jar is not yet extracted.

As I pointed out that is a example how I would picture the atomic structure of Slick to be designed. The other sub-projects still need to be extracted and the building progress can be done nicer as well. But I did not want to do all that work for nothing in case it gets rejected.

The advantages I see in such a structure were named by now often enough.

So... what do you think?
Nitram

_________________
http://illarion.org

Anyone and thoughts about this?

_________________
http://illarion.org

My suggestion:
Let's wait until we merge the the development branch with the main branch (we can do that in the next couple days?).

After the merge, we can introduce modularization / atomic projects -- and that way we will have a month to tinker and get comfortable with it before merging again.

The point is rather:

Are you okay with doing it the way I created it as example? Or should it be done differently?
Its just about the general concept.

Nitram

_________________
http://illarion.org

I can't see the canges :/

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!

Yeah because bitbucket+mercurial is a pain in the ass if it comes to a complex version history tree.

https://bitbucket.org/Nitram0815/slick/changeset/f5294d7ec27e
This is the commit that contains the changes. Best use "get source" to download a snapshot of the repository with this version.

Nitram

_________________
http://illarion.org

Ah thanks, I will look into

_________________
Current Projects:
Mr. Hat I
Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!