RomRaider

The installer has a series of panels. It appears to be hanging on the Shortcut Panel, not the Installation Panel. The DLL that is called by IzPack through JNI to create those shortcuts can't be loaded because it's 32-bit and the loading process is 64-bit. This just doesn't work.

Perhaps the easiest solution is to bundle the redistributable JRE RomRaider requires with RomRaider. Any opinions on this?

EDIT: I'm trying to figure the minimum JRE that will work, and it seems it'll make the package significantly bigger. I'll have to get back to this later.

Thanks for narrowing it down. At least we have a reason for the hang.

I had considered doing the same. And as you have found it would at least double the size of the distribution. I'm not that keen on bundling in a JRE for each of the OSs. Sure there's a few install help requests because of the 32bit dependency, but most come from people who don't read instructions in the first place and there's no way to fix that. They'll still come back with other questions. All of this car tuning stuff requires a certain level of skill and knowledge. If users are not willing to read, learn and help themselves then they should not be pursuing tuning in the first place.

So for now we can consider this matter closed with, no further chance of girls and glory.

Is there no way to check the installed JRE or installer process type? It would be simple and effective to have the installer quit and open a browser to the instructions (or a special instruction set for special people) or a JRE link. I'd be surprised if there wasn't a better way to skin this cat.. even though we are talking about java.

What about bundling an "online installer"?

I know how to detect the JVM bitness in ant. I can't believe that no one has dealt with this in an IzPack installer. I haven't give up yet, although I'm also reluctant to put in too much effort to help people who can't be bothered to read. A little effort is worthwhile though, just to reduce the annoyance complaints.

Quite likely!


No, I'll be taking care of that personally.


No, it's just a matter of not wasting time writing ant scripts to do things worse than what they can be done automatically in M2/M3. Nothing more, nor less. I can create, build and execute a new application in 30 seconds. 5 minutes later I can have it tagged and released. All automatically. Try that with ant. You can't.

You're in the wrong thread for discussing ant, anyway. This thread is my personal TODO list for RR, what I planned to do, and what I'm still planning to do. Precisely none of it involves ant. (which I won't even install, along with SVN, its equally bad friend)


Excellent work! Thanks :-)


What Dale said. Dislike.


LOL! :-)

Fred.

Do what you want. There was no build automation at all, I stepped up because I knew I could make it work. I did, and the ant scripting has worked for years. You plan to scrap a working system that you admit you won't even try, and admitted that you don't have the resources to work it out under Maven. The current build system is a straight, procedural mechanism, as it should be.

As for what can't be done using ant, I'm not sure your the ultimate authority, since you refuse to even install it.

Sorry to dump on your own personal TODO thread. I was trying to find where to pick up from the work I did before. I'm going to see what I can do with the installer, given my time and motivation. I'll take that discussion elsewhere.

Don't worry, I will.


And it was valuable and continues to be valuable, that doesn't mean it should be kept forever, though.


Rubbish, I've used it. Apple, unfortunately, install ant as part of XCODE so I had no choice.

I think you need to take a chill pill and not take the replacement of an Ant(iquated) build system so personally! I assure you, it's not personal; as point 3 in "disadvantages" states, you'll live.


Right now, no, but I will, some time :-)


As with most, though not all, ant scripts, it's woefully incomplete from a project life-cycle point of view. Releases are entirely manual, which is a maintenance overhead for Dale.


I was writing ant scripts since 2000 when Ant was shiny and new and replaced misuse of make.


My pleasure, I assure you :-)


You succeeded, and found the issue with the shortcut panel :-) Such work will continue to be valuable irrespective of the build system in use.


Likely a good idea, it'll just get lost in here, eventually :-)

Fred.

I guess that my old-fashioned ways are preventing me from seeing beyond my permanent residence in Disadvantage #3. Perhaps I'll live. That remains to be seen.

I'm still of the opinion that you're trying to fix something that's not broken (see Advantages #2 and #5).

I'm not a fan of git at the moment. That may change: I can see advantages for an open source project with many contributors working separately.

Re 2, there's no transparency right now. Lib versions are mostly known only to me (because I did the hard work of figuring it out) and not easily traceable. Also not checkable for compatibility. Anyone that's mavenised an ant project before (I've done plenty) knows the meaning of the phrase "dependency conflict".

Re 5, Ant hasn't been the industry standard for a VERY long time :-)


:-o Likes ant, doesn't use Maven, doesn't like git. Next thing you'll say "I like SVN" and if you were working for me the next words spoken would be "pack up your things and go home" ;-)


Let's hope so :-)


Once you start to use it, you'll see many many many other advantages. It's vastly superior, in every way.

I'm reminded of this: John Stuart Mill - "It is better to be a human being dissatisfied than a pig satisfied; better to be a Socrates dissatisfied than a fool satisfied. And if the fool or the pig thinks otherwise, it is because they have no experience of the better part."

You make it sound like there is only one "industry standard." Sadly, that couldn't be farther from the truth. I use ant because it works, and has numerous tasks that are designed for the type of things I need to do and I have a substantial repertoire of constructs I've developed over the years. It's a tool, and it works. Let's face it, this is not that complex of an application. Don't get me wrong: Much work has gone into it by a small number of dedicated people, but it hasn't been a team of 20 engineers working full time for a decade.

Oh, and it looks like maven builds with ant. Guess I'm not the only fan. ;^)

I'm assuming that you're talking about the "legacy" libraries that have been unchanged for as long as I've known about Engi ... er ... RomRaider? The graphics libraries, serial libraries, etc? I investigated them all when I started here, so I can understand your desiere to track them all down. As I recall, some were all but dead (like rxtx). I haven't tracked them since, so don't know how much they've changed.



Although I do not like SVN, it's still a good thing I don't work for you. Or you for me. You're at least as abrasive as I am.
Not so far. My first experiences with it have done little to enamor me of it. I tried to do a simple upgrade of IzPack and am not even sure if it went anywhere beyond my local clone. The nomenclature is different than I'm accustomed to, the workflow is different, and it's not the most intuitive, particularly using the Eclipse integration. At least in that respect, SVN was easier. Again, it's a tool. I didn't put RomRaider in SVN and didn't port to git. I'll either cope or leave.


Once you start to use it, you'll see many many many other advantages. It's vastly superior, in every way.
[/quote]
Superior to everything? As I noted, I can see the advantages for a project like this: many individuals working separately, each having their own repository clone. Many people may make changes and never commit anything. I first got invloved because I tried to fix something based on the source code bundled with the application. It didn't work. It wasn't the same code as was used to build it. That hasn't happened since.



Ah, Socrates. I'm probably misquoting, but he told me it was likely close enough -- "By all means, marry. If you get a good wife, you'll be happy. If not you'll become a philosopher."

At any given time, in a single specific category, yes.


Yeah, we got that already, to paraphrase: "I use it because I'm used to it and it's all that I know."


Relevant, how? Not at all. Be the app a one liner that wraps an excellent lib, or a 1000 module 10,000,000 line monster that underpins an entire organisation, Maven's the only sane choice AT THIS TIME. More than 7 years ago, Ant was the best choice, but for the last 5+ years, Ant has been an increasingly poor choice.


Quoted, not for truth, because it contains none, but for amusement, because such comments should never be lost to the winds of time.


I really don't think you do understand, as it's not a desire at all, it's essential to a solid understanding of your working final artifact.


LOL!!! That would never happen. I have standards and all interviews are bi-directional.


ROFL :-)


LOL! If you need some help, Dale, Merp, Scott, Masaki, and many others have recently (or not so recently) gained mastery of it to various levels. I'm sure they'd be most happy to help you come up to speed.


Old dogs can learn new tricks, you'll see. :-)


That'd be sad. Don't do it on my account.


I didn't say that. The context was SVN. It IS vastly superior to SVN in absolutely EVERY way, yes. This page has a good quote under the heading Subversion: "Previously, we relied on Subversion as our version control system. Git is considerably better." So understated, and yet under a heading of Subversion, without an SVN repo in sight :-) There are other excellent systems too, Mercurial is one of them. Perforce isn't bad either, though I don't like it. Liking it and how good it is are quite different things.

Really, stop wasting your time arguing the benefits of a dead build system in this thread. In doing so, you're wasting mine, and that's completely unacceptable.

Fred.

It's on the Maven page. Get the source, run ant. That's more than zero truth.



I think you win in the "personal insults" category though.


That'd be sad. Don't do it on my account.[/quote]

You've assumed far more than is reasonable based on my advocacy of a particular tool, and belittled me in doing so. I like open source projects, but this is a strong downside.

I'll cease wasting my time in this thread. Oh, and yours too.

The latter is the obvious interpretation of your ambiguous statement. I'm sure they needed something to build it when it didn't exist. And yes, if you read the docs, it's purely for "bootstrapping" the project in an M2-free environment for the first time. A nice touch, I guess, though I can't imagine a situation where you'd need to boot strap it as the build works with maven too, and is, according to them, faster that way anyway: "If you already have Maven installed, it can be faster to build a new version with Maven, rather than a clean bootstrap." http://maven.apache.org/guides/developm ... ng-m2.html Interesting stuff:

"The first time you build Maven from source, you have to build Maven without
Maven. This Ant script builds a minimal Maven, just enough to re-launch
Maven again in this directory and generate an installation assembly. Then we
extract the assembly and re-run the Maven build one more time, this time
with the full generated Maven."

If you look in their build.xml they actually use a bunch of maven classes to do the build anyway ;-) Interesting stuff, you learn something every day!


Funny that Maven is a MUCH bigger project than RR, used by virtually every Java dev in the world, save you, and the ANT build descriptor for bootstrapping it is smaller. I guess they know their stuff.


Wasn't trying to be insulting. Apologies if some of the facts were upsetting.


As far as I can tell, I've assumed nothing at all. If you've become belittled in the process, that's a shame. Chin up, you'll get over the self-imposed feelings of belittlement.


Thanks! It was fun, but enough's enough.

Fred.

I'll agree with that...