next »

['n ddrylliog]

Hi !

I am pleased to report that OneClick is now officially a SourceForge.net project.

I already added Cylab as a Developer (welcome!), if any other is interested, just let me know, this is open source (BSD).

My plans for the future of OneClick :
- Bug fixing (by an intermediary launching class, taking care of the logging and allowing auto-send of stack traces)
- GUI improvements (make the whole thing look like a "Wizard", if you know what I mean)
- XML storing of packaging configurations (so that you don't have to enter data every time you make a build )
- Creation of an install system : currently OneClick is ideal for betas, but it has to be useable for final versions, too.
- Package/dependency system. I don't want to redownload Xith3D when just a few models/maps have been added to the game.

These items are in order of importance. I'll be regularly posting tests here, and I would happy if a maximal of users would run them (testing on a diversity of platforms is a Good Thing^TM).

Enjoy !

[horati]

I don't have time to actively participate on that project too, but I'll be happy to partake in any coversations that take place on this board about it   Before you design your own packaging system, be sure to have a look at some of the existing ones.  I know that there is a pretty good OS packaging/dependency system based on XML out there although I haven't used it personally and can't remember the name.

[Patheros]

May I make a feature suguestion/request?

Implement web a based updating like JWS. Another way to look at it is an Automatic Update function.

[Mathias 'cylab' Henze]

I would advise against build in autoupdate functionality and package dependency support. I would rather concentrate on this playing nicely with JWS, so we can have the benefit of separate JVM launching by oneclick in conjunction with already existing functionality provided by JWS. This way we can utilitze the autoupdate and dependency handling of JWS by providing oneclick packages as JWS extension libraries.

[Patheros]

I would advise against build in autoupdate functionality and package dependency support. I would rather concentrate on this playing nicely with JWS, so we can have the benefit of separate JVM launching by oneclick in conjunction with already existing functionality provided by JWS. This way we can utilitze the autoupdate and dependency handling of JWS by providing oneclick packages as JWS extension libraries.

I believe one of the Amos goals is to not have to deal with the problems he sees with JWS. Take a look at http://www.xith.org/forum/index.php?topic=294.msg2523#msg2523. Also it just seems like too much overhead to have to deal with both.

['n ddrylliog]

Well, that's a hard decision to make, isn't it ?

In a way, I don't consider too difficult to make a wrapper for a JWS app, and on the other hand, I don't see which advantage would JWS have over a quickly self-made system.

Auto updates are just a matter of comparing dates, isn't it ? As to dependencies, some metadata in packages and it's done.

Well maybe I'm a bit too optimistic, I think it's time rather than knowledge/ideas that is missing. 

[Patheros]

Auto updates are just a matter of comparing dates, isn't it ? As to dependencies, some metadata in packages and it's done.

In my mind my auto update would involve checking dates and going online and downloading newer jars.

[horati]

Well maybe I'm a bit too optimistic, I think it's time rather than knowledge/ideas that is missing. 

Yes.  At first, it seems like a downright trivial task.  Once you get into it, there is definitely some real work.  Obviously, it isn't rocket science but why re-invent the wheel?

In my mind, there are 3 pieces to your solution:

• IsolationClassLoader
• auto-updates
• dependency management

ICL is unique as far as I know and already 80% implemented so go with it.  Auto-updates should be pluggable for JWS or the easy version.  There is at least one very good dependency management tool out there based on XML and I'm sure more than one.

I don't think it's terribly important to implement JWS immediately; however, I think you shouldn't prevent compatibility if possible.  An abstract factory pattern should pretty solve the issue without too many hassles.  There will always be people interested in the widest possible distribution of their software.  Today, that means JWS.  Even if you completely duplicate JWS's functionality (which has not been suggested by anyone in this thread), there will be people who simply won't install something they perceive as foreign on their hard drive.  This would diminish the value of any full or demo application that someone places on their web site.

As far as dependency management, check out [url href="http://www.openlogic.com/downloads/OpenLogic.CertifiedLibrary.pdf"]OpenLogic white paper[/url].  I know their open source tools management product uses one, and I think they include it in their project suite.  So it should be one of the projects listed in that white paper.  Shouldn't be too hard to cross reference against dependency management tools.

Hope this helps

['n ddrylliog]

In my mind my auto update would involve checking dates and going online and downloading newer jars.

Yeah, yeah, sure, don't joke me 
I may be stupid, but not *that* stupid.