[CLOSED] LWJGL Applet Loader as an independent project

Started by arielsan, February 16, 2011, 13:19:04

Previous topic - Next topic

arielsan

I believe we have talked this on IRC before, the idea is simple, extract the LWJGL Applet Loader and create a new project LWJGL independent (I mean from LWJGL code and dependencies, etc, not to be outside of LWJGL svn).

Currently the LWJGL Applet Loader code doesn't depend on anything from LWJGL code, managing it as a separated project will benefit developers in several ways. For example, it could be updated and deployed independently of LWJGL each time a patch is applied and LWJGL version will not be modified (they will have different versions). It is also easier to develop for it, now if you open LWJGL in Eclipse, for example, it will not compile since you need generated files from natives and other stuff but as the Applet Loader doesn't need those it could compile without any problem.

Another important thing, it could be uploaded to maven central repo without any restrictions since it doesn't depend on anything extra. And of course, JNLP LWJGL Applet Loader will depend only on LWJGL Applet Loader, that will be nice since I could upload it too to maven central.

Hope you like the idea, I am willing to help in anything you want if you want to go ahead with this RFE.

kappa

The LWJGL AppletLoader will never depend on any LWJGL code or natives, the whole idea is for it to be standalone and independent from all the other jars (as its suppose to download and load them). The AppletLoader is also in its own separate jar file (lwjgl_util_applet.jar) and the latest version is always available daily in the nightly builds. So I'm not exactly sure what extra changes you're asking for in this respect.

As for not compiling on Eclipse, its just the way the LWJGL project is, its intended to be built using the ANT build.xml file. Besides its pretty easy to copy the single AppletLoader class to another project and compile it.

We could probably modify the ANT build.xml file to include an option just to compile the appletloader (lwjgl_util_applet.jar) instead of the whole LWJGL Project, making it easier to compile and this would also help with this RFE as it'll make it easier to compile just that jar to Java 1.4 compatibility.

As for Maven, again these changes can be handled in the maven build file.

So am I correct in assuming its the above two build file changes (ANT and Maven) are what your proposing?

kappa

hmm, reading it again, looks like your proposing another project outside the LWJGL folder on SVN, if that's the case, it'd need its own build.xml and probably changes to the nightly build server.

Guess that will just depend on the benefit to hassle ratio :) and Matzon who makes the releases.

arielsan

Exactly, I am proposing it to be treated as a separated project inside same SVN, this is because I feel 1) they are totally independent from each other and 2) the life cycle of both projects are some kind of coupled, if you want to release a bug fix or improvement for the Applet Loader you have to release again LWJGL but it may have no changes at all. So, for the regular user who uses only LWJGL (without the Applet Loader), why will he use the new release of LWJGL? (same thing vice versa, if you make a bug fix or improvement in LWJGL)

But, on the other hand, I don't want to complicate the LWJGL to maven central repo process....

kappa

This was discussed briefly on IRC and was decided not to separate it due to the hassle of yet another release and having to manually sign more jars.

The main advantage with this RFE would be that the proper signed version of the AppletLoader would reach developers much faster when changes and fixes are made to it (The nightly builds already creates the unsigned version every time a change is made). So only an advantage for those that use the lwjgl pre-signed jars, doesn't effect those that sign their own jars.

The AppletLoader codebase is pretty much stabilising now (dare I say almost done) and not actively changed as it was before. So again not much benefit in an independent project.

arielsan

Hope the part of "stabilising now" comes true... :D