RomRaider

Glad you like it! :-)


LOL :-p


Cool, suits me! :-)

Okay I have most of the changes up on my repo now.
https://github.com/dschultzca/RomRaider
The JNA stuff came from here: https://github.com/twall/jna
Version 3.4.0 of the Download section.

Dale
I hope my commit was good...

Commit looks OK, though big :-) You forgot to erase the dodgy history first, though. It's nearly 3am here again, but tomorrow morning I'll "fix" it, and record exactly what I do to achieve that, and post it up in the git thread. It basically involves "git rebase -i hashBeforeLastOneYouWantToChangeInSomeWay" and some typing. Pretty straight forward :-) If you're happy with the results "diff yourCurrentCommit yourNewRebasedCommit" == nothing bad, then you should "git reset --hard yourNewRebasedCommit" and go forward from there :-)

I can't see the Network view for some reason.
I guess it's still messed as I didn't fix it from before. I did add the rebase option and also tried a rebase but it said I was already at the latest, or something like that.

Oh, the Network view just popped up. Now I see what you mean.

Yeah, the procedure is rebase -i, I'll do it now, document it in the other thread, and push it to a temp branch in my fork for you to examine and try to reproduce as practice :-)

Done, link for the record: viewtopic.php?f=14&t=8324&p=79692#p79692

I just did an eclipse only git import and maven build of olv here, and in the console I got this:


IE, the same error that you got, however it carried on, did everything, and executed the app just fine.

I did:

Project explorer >> right click olv >> run as >> maven build... >> window pops up, typed "install exec:exec" into the goals field without the quotes, and it "just worked". IE, the SLF4J error seems to mean nothing at all.

Hope that helps :-)

Fred.

I haven't dug into it. I think it's related to the Eclipse Maven plugin. As you found the project builds an executes regardless of the warning.

Yes, its only useful given the correct context. I've been developing code for 25 years and have never heard of maven until just now and had never heard of ANT until using eclipse for Romraider for the first time last year.

Well, I've never typed a line of java in my life really either as I have not had the need for it in the domain I work in...

I'll just take it for granted that you guys are using the common tools in use in the java world.

Short history of Java builds:

• Nothing/make. Didn't last long.
• Apache Ant created to fill void. Used as default until some point after Maven created.
• Maven 1, good ideas, some issues, some adopters, not ideal.
• Maven 2, wide adoption, some minor niggles, if you managed it well, brilliant. Ant gets dropped by anyone with half a brain and open to new ideas/not rooted in the distant past. Only used by legacy systems and stupid stubborn old fashioned (but typically not actually old) "devs".
• Maven 3, Maven 2 with the niggles fixed, you don't have to manage it well to get consistent results. Anyone using Ant now needs to be given a straight jacket and sent to a padded room for shock therapy.
• In amongst the M2 era other tools emerged, particularly based around JVM scripting langs, however AFAIK none are mature yet. And most have similar issues to ant, by choice.

Since M2 days, other projects such as Ivy have been using Maven infrastructure to perform some of Maven's tasks in ant and groovy and so on.

The people who wrote Ant went "not good enough, what do the best developers do in their ant scripts and why, let's make that the default, manage deps properly like apt and call it maven". They got close with m1, VERY close with m2, and are, IMO, there with m3. m3 and m2 are pretty much interchangeable unless you force them to not be. I do that, so m2 will never be used with any project I setup Maven on.

Fred.

An update to this thread.

The structure is in place in the official repo for Mavenisation, and other build system's defaults, too. Along with that came some changes to make RR stand alone without an installation a bit better, though this is not complete yet. Thank Merp for those changes as he did them initially. I had to rework them all to get it included, as some changes were made to the code involved, however Merp should take 99% of the credit there IMO. Which leads me to this:


It seems I was wrong about this. Gradle and BuildR are both pretty mature now. Both follow M2 standards, both are more succinct and less verbose than M2/M3. Gradle is now used to build the Spring Framework, which is a huge "yep, it can't be bad" tick box. BuildR uses JRuby, so, just like Maven and Ant, it can run on the JVM keeping options wide open. Gradle is Groovy which also runs on the JVM, keeping the doors open to the widest selection of tools possible.

So, the options then:

• Ant + Ivy
• Maven 3
• Gradle
• BuildR

It's feasible that all four could be there together, after all, they're just a single file each. As seen above, I've already mostly completed Mavenisation of RR. There were a few outstanding issues, some solved by Merp, some still remaining to be solved. Once the remaining issues are cleared up, it paves the way for a few good things:

• Introduction of build control files for all three currently unused systems.
• A standalone Windows executable (and standalone jars for other platforms, too.)

By a country mile, Maven is the most common, most well known, and most supported system, with robust out-of-tree dependency handling out there. Maintaining and extending a Maven build should be easily handled by any dev worth their salt. I have zero experience with Gradle and BuildR, so I, at least, would not be much use assisting in maintaining or setting up those.

Ant + Ivy doesn't handle release management, so that very clearly rules it out from my perspective.

Do we have any Gradle or BuildR experts in our midst? If so, go ahead, the stage is all yours :-)

Fred.

For the benefit of others not familiar with what the current steps are to get RomRaider from source to a release people can download and use, I thought I'd outline what I currently do.

First off, I’m not a software engineer and have had only introductory courses in some software languages. I think the first being Commodore BASIC. So my knowledge of current build systems is basically nonexistent.
That said, in the few hours of reading about build systems I thought Gradle looked most intuitive to me.

Anyway, back to the purpose of this post. I inherited the RomRaider project as a result of a couple of plugins I wrote and bug fixes I offered. Once I became the "lead" developer I set myself a few steps to follow to keep things consistent. So once I have a new version to provide for review here's what I do.

• test bug fixes and new features
• build the application
• validate the application will install and run on Windows and Linux
• validate the standalone package will unzip and run on Windows and Linux
• upload the four files to the server for public access
• update the Download wiki page
• update the News wiki page
• post an announcement in the RomRaider Development forum about the new version
• wait for the good and the bad feedback
• correct problems and repeat the steps starting from the top of this list

RomRaider is currently provided in four flavours, there’s an installable version for both Windows and Linux and a standalone ZIP version for both Windows and Linux.
The installable versions allow a user to “install” the RomRaider applications onto their system in a user specific or a global (all users) way taking into account user permissions to install software. It also creates shortcuts in a RomRaider program group in the desktop start menu, which can start the Editor or Logger with the appropriate Java VM custom settings. It also offers an uninstaller that cleans RomRaider from the file system and the start menu but leaves customization files intact. The Windows installer (setup.exe) is by far the most download of the four flavours.

The standalone version is provided as a zip file which can be unzipped and stored anywhere on the file system that the user has access to. RomRaider is started from the command line by the “run.bat|sh” file. This file contains the Java VM custom settings that RomRaider uses. By default the run file launches the Editor, but you can make a copy of it and uncomment the line that will launch the Logger directly.
The standalone version offers the user the ability to have coexisting versions of the RomRaider application on their system. This is not easily achieved with the installer.

Moving forward with the current build system to support the 64 bit platforms would result in eight flavours of RomRaider. Four for the 32 bit systems and four for the 64 bit systems.

Regarding changing the build system, I have a some questions which I’ll ask in the next post.

Dale

From the various wiki and blogs I’ve read there’s advantages/disadvantages, pros and cons with each and every system.
So my questions.
First, do we need a change, what is driving that?

If we change, to which system? That’s the ultimate question of course.

I do see that the “newer” systems appear to be “lifecycle” related. So if I conveyed the lifecycle correctly in my previous post then the new systems add some features and automate a few steps, providing reports and review of the source code.

Fearless (Fred) had shared with me a sample set of reports from the Maven work he started about 8 months ago. I found the reports quite useful and I believe this information is invaluable especially as it pertains to the quality of the source code. (that’s a pro)

The new build systems offer automated software releasing as well as building web site files to go along with the current build. I guess these could be useful if we had the appropriate servers to host them. Maybe these new build systems can accommodate what’s in place now, if not we can ask our host server provider if they can be added alongside the RomRaider web site as a “dev.romraider.com” site or something like that. This I suspect will only be of interest to developers.

As far as these reports go, is there a new set of documents created for each version, or is it just an update of the current documents as the versions are issued?
JavaDocs are also created but I don’t think they are all that relevant to RomRaider as an application.
Do the documents even need to be hosted anywhere or can they just stay local?

The new build systems also appear to separate the dependency files from the source project. If I’m correct this can reduce the repository size as these dependent files are stored in a repository of their own on public servers. Does this mean that you need to be online and connected to the Internet to build the project?
How does the dependency repository store their own dependents if they are native files like .dll or .so libraries?

We currently have the build and packaging tools in the RomRaider repository such that anyone can download the repository and with the press of a button build their own version of the RomRaider project including the four files that encompass the installable and zip packages. These additional tools add to the repository size and are only needed by a developer who is providing releases. I think these can be disassociated from the repository and replaced with a few instructions indicating what tools are needed and where to install them so anyone can use the “one button build” currently in place.
I suspect some of this may go away with a change to a different build system if it can provide the distribution packages that the users need to install RomRaider...?

I’m sure I’ll have more questions as we discuss this topic.

This is a HUGE mistake. One flavour with intelligence and resources inside is sufficient. Wrap it with which ever installation methods you wish, at that point.


I used to want to do some work on RR for various reasons. It was me driving a change in build technique, as I see it as a minimum requirement for my involvement. I do however have other minimum requirements, which I'll elaborate on shortly.


You can easily have this and tune it to your taste without switching to a real system entirely if this is all that interests you.


For site deploy, just a simple SSH connection is all that's required, though you can use more antiquated approaches like FTP or different approaches like webdav, or whatever else you want to write a plugin for. Same goes for artifact deployment. There is no need for a "fancy" nexus instance such as the one that I use. You can simply have apache + ssh for that. It's just a dir structure really. Just put it on a subpath of the existing site and get the CMS to ignore it.


New each time. Including dev builds in between releases. I operate my stuff on a versioned path with a symlink to latest so that google can index one copy primarily.


It's optional, but harmless to include.


You don't have to deploy them, they could just stay local, though you lose a lot of the benefit of transparency this way.


Ideally you'd have no dependencies that aren't in central, however reality often dictates that you do. Once again, a simple directory setup through apache + config pointing at it, is sufficient for this, no need to get fancy with nexus. With the exception of the stuff you've added since I did my work, it's all online on my nexus instance anyway. This can easily be mirrored/moved to your server so as to not rely on me.

With regards repository size, it can't reduce it, but it can stop it growing. If I were in the driver's seat, I'd make the switch, then filter the entire repo to remove all history of jars and so forth. At that point I'd move the old project to an archive name and consider the filtered one the master copy. Anyone working with the old copy would be affected and require notification first. This may be over your head somewhat, though, or perhaps not.


No idea about gradle/buildr, but maven has -o for offline. You build it once online, then -o in future until a dep changes.


Search? I'd bundle them within the jar if I were doing it. I think JNA does this. It works everywhere.

I hope some of that assists you in the direction that you choose to move, even if it's "no where". In closing, though, the recent censorship of at least three members harmless posts has left a bitter taste in my mouth and zero desire to assist the RR project in becoming more professional. My final contribution will be my now-outdated pom.xml and settings.xml files so that you can at least do your report generation.

The code might be free, but if the community is not, it's not worth a damn to me.

Fred.