RomRaider

I don't think git has changed this, people always played with and contributed just not in the visible way that git provides...

Git log says otherwise :-p

It removes you as a middle man, to some extent. People can make Git changes without your assistance or a username. That wasn't possible before. It's MUCH easier to do that than to work on something in a read only SVN checkout and then generate a patch/diff and then email/post it to you and then have you apply it, etc.

If you were taking patch files and applying them under your username in the past, OK, but the strong impression that I got was that only you were doing any work for many months. The feeling, if not the reality, has changed. It's more welcoming to use git :-)

Fred.

Yes that's exactly how I was adding other people's contributions which I would note in the commit or release notes. I'd get a couple updates a year from others...

So we're up by a factor of 12, or so, then, so far? :-)

Bump, still planning to complete the Maven migration, though I have no idea when. How much more than that I'll do, I don't know.

Other than the reasons listed above, I stopped because I found a few code structure road blocks that needed sorting out, and I didn't have the resources to sort them out myself.

I did have it running, though a bit broken, under Maven. There was more work to do to properly package it all for each platform, however.

Fred.

I haven't been active here for a while, but thought I'd check in to see how things were going. I wrote the original ant build automation for Jared almost five years ago (when it was still Enginuity) and then worked with Paul to get it stabilized. I'm glad to see it's still working, and has needed only minor tweaking to keep it going.

Once I discovered the repository had been moved over to git I set up to build. I checked the versions of IzPack and Launch4j to see if they needed upgrading, but things are pretty current.

I've got a little time at present (rare these days). Are there any specifics with the build system that you'd like to see changed or enhanced? All the active tickets I see are for the RomRaider product itself.

Hi, thanks for checking in.
I'd like to see IzPack and Launch4j updated to the most recent stable versions if you could manage it.

There are instances when people attempt to install RR on a system with the 64bit version of Java. Usually the install will fail to complete and leave people hanging at a blank window with no feedback on what's happening. I'm not sure if the latest versions correct this behaviour, but at least there should be a Java version check and warning to the user that they are working with a non-supported version of Java if it's 64bit. We still need to use the 32bit version on all systems due to some supporting libraries not being up-to-date for 64bit systems.

I'm able to successfully *build* using 64-bit Eclipse Juno SR1, but have not tried to run anything. Without a Subaru, I'm not sure what the point would be.

Anyway, yes, the 32 vs. 64-bit problem persists. A 64-bit process cannot load a 32-bit DLL, and I don't expect that to change. The current version of IzPack is only off a patch level or two from what I last checked in, so I don't think that'll help much. Still, if that's a point of aggravation, I'll investigate.

IzPack was already in use when I did the build automation, so I just automated what was previously done manually. I think the whole process went from about five hours to about 80 seconds (my current workstation did the whole thing in about 20 seconds). Since then I've used IzPack at work, so perhaps I can apply some of that experience to this. No guarantees, but I'll see what I can do. There's a newer version still in beta, but I'll see what the released version can do before I start with that.

-- Steve

I still strongly feel that the app should function fully without installation as such. Most resources can be embedded within the jar/meta-jar leaving only the defs, which are a post-install download anyway. I did some work on this ages ago, but ran into various blocks. I should likely update and publish what I DID do so that perhaps someone else can step up and finish it.

With respect to launch4j/izpack versions, if converted to Maven, they're a declaration away from updates at any time. I've not put any time into Izpack, however I do know exactly how to get good results from launch4j with Maven, and in fact, I was the one that did the last release of the maven launch4j plugin to central! :-)

If the app is bundled up nicely to be a standalone, then izpack solely offers menus and icons and file associations, and of course the familiar "ok, ok, ok, ok, yes I accept, ok ok ok" install process :-)

What's the story with the installer hanging? Is that an installer bug? IE, does the installer use 32 bit binary components? It's not really an RR issue, if so. Just something to put in neon letters flashing on every web page.

Fred.

All true. The application does not require anything to run other than what is bundled, except for the JRE. More on that below. At work, for some O/Ss, e.g. Linux, I create both an installer and a simple gzipped tar file. The IzPack installer is pretty much a wrapper of convenience around such a compressed archive though, with the menu items and shortcuts included as a bonus. Oh, and the uninstaller: that will remove all the files it added, but leave behind files added or modified by the user. That's nice if you want to upgrade, since you won't lose your configuration and definition files.

I've found that most users like to have the menu shortcuts and such. Savvy users (and those who are comfortable building from source) may prefer a zip of sorts. That's simple enough to do (half a dozen lines of XML, tops) but would add one more package to publish for each platform.



Updates to launch4j have been minimal in the last five years. When I first set this up, it was 3.0.0. I updated to 3.0.1 four years ago (git says 3 years, 12 months - sounds like four years to me), and the current version is 3.0.2, out for almost two years. I'll look at the ant maven tasks, but with the frequency of updates, this may not be worth the effort.

IzPack has been a little more active in development than launch4j. I've been waiting for the next major update, but I'm a little behind on the stable release here (4.3.2 vs. 4.3.5). I'll look at the changelogs and see what's been done. I think they fixed a bug that I filed, but I think that only applied to 5.0 Beta.



I suspect it's not the installer, but the installed RomRaider. The installer will run with either the 32-bit or 64-bit Java JRE, but RomRaider itself will only run using a 32-bit JRE. Some of the native libraries (Windows DLLs and Linus SOs) are only available in 32-bit form, and the 64-bit JRE cannot load them. Again, I'll investigate a bit, although perhaps Dale can provide more information here.

No, it's the installer that hangs.
viewtopic.php?t=8745
viewtopic.php?t=8574
viewtopic.php?t=8250
viewtopic.php?t=8204
viewtopic.php?t=7252

We know RR Logger fails for sure on startup in 64bit, mostly because of RXTX. But other libraries contribute as well.

Thanks. I'll look those over.

Currently the app depends on on-disk resources, this sucks. My point was that if that was fixed, users with installer issues could grab the standalone exe and not be much worse off.


Yep, I know. The release I did was to make the m2 plugin compatible with later OS X variants.


Urr, what? Why? I completely fail to understand what it is that you want to achieve. I've NEVER once had to use the m2 ant plugin for anything. If I did, I'd consider myself as a failure :-) There's virtually always a decent m2 plugin for what you want to achieve. If not, it's a strong clue that you're "doing it wrong". Or are you being really weird and wanting to run m2 plugins from ant? That'd be bizarre :-) Anyway, moot point, if moving to maven, launch4j is covered. If not, it's already fine.


Seems not! :-)

Fred.

That's an issue with the app. I'm not sure why it sucks though. The app uses configuration files that are on-disk and write to logs files, again on the disk. Am I missing something? If we provided a zip file either in addition to or instead of an installer, that would bypass any installer issues.


Yep, I know. The release I did was to make the m2 plugin compatible with later OS X variants.




I was suggesting that perhaps the ant/maven integration might handle the dependency check and update. I like ant. I use it for several large build systems that I wrote from scratch. I was looking to see if there were enhancements to a system I wrote, and find it's been functioning for years with minimal change.

Weird? I was trying to be nice ;^). I thought I'd see if there was something you proposed that might be an incremental improvement. Now, I'm not sure what you're talking about. Perhaps that's because I don't use maven. I won't be scrapping the (working) ant system for maven though. Ant versus Maven is apparently a religious battle, and one I'm not willing to fight.




IzPack should run with either. The fact that it's not indicates that there is probably something fixable. It looks like only WIndows users reported the problem, so that should help determine a solution. It might require some custom code though. I'm not sure yet. A quick check didn't reveal any built-in fuctionality for that, but today was not the day for research. We're moving our office and I'm custodian of the source code repository. Safety of that ensures continued employment.

Looking at the installer, it seems unchanged since I did the first build automation. I took the existing installer XML file and converted it to a template to be generated, but I didn't modify any of its operation. I'm glad I didn't break it. It's a long-standing deficiency though and with the increasing prevalence of 64-bit operating systems, it should be addressed.

Hopefully, it's not something too complex. I don't have a 64-bit system without a 32-bit JRE, so setting up to test might be a pain.

Also, since I don't have a Subaru anymore (and even then, it was a non-turbo) my motivation is somewhat diminished. Now, I'm only in it for the girls and the glory. So far, the return been disappointing