I am pleased to announce to final release of MapGuide Open Source 4.0!
It has been 6 years, 6 months and 14 days since the last major stable release (3.1.2). What started as something that was supposed to be the 3.3 release stretched out to what is now the 4.0 release. Maybe some things could've been done better to not make this release gap so big, but things transpired the way they did and what's done is done.
We're on the home stretch now!
The first (and hopefully only) release candidate of MapGuide Open Source 4.0 is now available.
This release has the following changes since Beta 3:
A new beta release of MapGuide Open Source 4.0 is now available.
The main driver for this release is updating an assortment of bundled components:
We start the new year with a double-header release of:
This took way longer than expected, but the 2nd beta release of MapGuide Open Source is now available.
The main driver for this release is to update our various web tier components to their latest respective versions:
As the title implies, this blog post is about my experience test driving Avalonia UI.
So why am I doing this?
I've been getting growing questions lately about whether MapGuide Maestro works on Linux via Mono.
Sadly I no longer emphasize anything regarding Mono compatibility because.
And in terms of .net multi-platform UI frameworks, there's only one logical choice: Avalonia UI
While it is not in my immediate plans to rewrite MapGuide Maestro's UI in Avalonia, I wanted to at least explore the feasibility of building such a UI even if all the actual functionality is mocked up, just to see how easy or difficult the whole process is.
Hence the motivation for this post.
So why Avalonia?
Avalonia is effectively the "spiritual successor" to WPF, and adopts most of the same patterns and practices when building UIs for Avalonia.
I had first heard about Avalonia when it was formerly known as Perspex and at the time, from the screenshots of example Perspex applications on Windows and non-Windows platforms, it was clear at that point in time the range of possible applications one can build with Perspex was quite limited and building an application like Maestro on top of Perspex was not feasible.
Just recently, I had heard about the framework now known as Avalonia again and this time round there was a lot more positive buzz around it, so I gave it another look and was much more impressed at its capabilities and richer suite of UI controls to build applications with.
My objective with this Avalonia learning exercise was to build a minimal multi-document interface skeleton application, mimicking the primary functionality (UI-wise) of MapGuide Maestro.
%20-%20Microsoft%20Visual%20Studio.png)
%20-%20Microsoft%20Visual%20Studio.png)
%20-%20Microsoft%20Visual%20Studio.png)
%20-%20Brave.png)
There will be a slight change of plans in the MapGuide Open Source 4.0 release timeline.
Namely, the next release will not be the Release Candidate, but rather a 2nd beta release.
The main driver behind this decision is because of my intention to remove the recently introduced support for Mapbox Vector Tiles. While I initially had high hopes with this implementation, additional testing with data outside of the example Sheboygan dataset has revealed rendering issues I do not have the capability to address. Rather than ship a half-baked implementation that may never bake fully, I'd rather bow out while we still can, remove this immature implementation, and leave MVT tile generation to dedicated external tools.
A 2nd beta release will also mean that the other changes I want to get in will also have some time to bake before the Release Candidate stage.
I am hoping the 2nd beta release will be out late January in the new year.
nuget.org support finally provided a resolution on my account issue and I was able to regenerate my publishing keys.
As a result, the 6.0m12 release (6.0.0-pre500) nuget packages are now finally available on nuget.org
There were a few things I left out of the previous announcement that I'll use this post to address.
Firstly, the 6.0m12 release of MapGuide Maestro formally drops all Fusion editor support for integration with Google Maps tiles and services. We no longer support Google Maps integration in Fusion and the editor in previous releases gave the false impression that this is still possible. That is no longer the case with this release.
Secondly, the more important thing (and the subject of this post) is that if you are using the Maestro API and consume this through nuget packages from nuget.org you may be wondering why there are no new versions?
The answer to that one is simply: My nuget package publishing keys have expired and something in the nuget.org website or something with my nuget.org account is preventing me from regenerating these keys or to generate a fresh set. As a result, I currently cannot upload any new nuget packages to nuget.org
But do not fret, because there is an alternative solution.
As part of the MapGuide Maestro release on GitHub, the nuget .nupkg files are also included
From here, you can set up a local directory-based nuget package source, drop the .nupkg files into it and the this version of the package is available to install in your Visual Studio solution.
If/when I get a resolution on this publishing key matter, I will upload the .nupkg files for this release and make another announcement. Until then, this local package source is a suitable workaround.
Next stop on the tour: A new release of MapGuide Maestro
This release includes the following notable changes.
This release improves the MapGuide Open Source 4.0 authoring experience with support for the new label justification setting for basic stylization labels.
This setting is part of the new v4.0.0 Layer Definition XML schema, whose .xsd file is now also included with this release (so XML validation against this schema will work)
This release includes several enhancements to the Fusion Flexible Layout editor to support various features that can be taken advantage of when loaded into a mapguide-react-layout viewer. These new enhancements are accessible from the layout settings panel and require the latest release of mapguide-react-layout to leverage these new features.
The Manage Custom Projections button opens up a new dialog that lets you manage and pre-register custom proj4 definitions for your application. By pre-registering these definitions in the Flexible Layout document itself, you can avoid needing to perform a epsg.io lookup for any projections found in the viewer init process that is not EPSG:4326 or EPSG:3857
Our journey needed to make a temporary detour, with another release of mapguide-react-layout.
This release has the following notable changes
We've arrived at the next stop on the tour, a new release of mapguide-react-layout
This release has the following notable changes
As I said near the end of my MGOS 4.0 Beta 1 announcement, I will be momentarily stepping away from MapGuide development/maintenance to give some of my sibling projects in the MapGuide/FDO space some long-overdue attention.
So for the next few weeks, I will be embarking on the "I haven't forgotten about you $PROJECT" tour with stopovers at the following projects:
Due to real life priorities and commitments, this release look longer than expected to finally come to fruition, but that's all in the past because we're finally here! The first (and probably only) beta release of MapGuide Open Source 4.0 is finally available for the following platforms:
After a long an arduous development journey, it is finally here! The 4th preview release of MapGuide Open Source 4.0 is now available for the following platforms:
In the previous installment, we had gotten a test MapGuide installation with bundled PHP 8.1 up and running, and we were able to successfully produce a PHP error when hitting the Site Administrator.
This PHP error referenced previously was a milestone because it meant that our PHP 8.1 setup (FastCGI on Apache via mod_fcgid) was working, our PHP code was actually running and so the actual errors is the result of the vast swaths of our current PHP web tier applications needing to be migrated across to work against this new PHP 8.1 binding for the MapGuide API.
And so for the next few months I did just that, not just for PHP, but also for Java and .net. You can consider this post to be a preview of what you'll need to do yourself if you want to migrate your PHP/Java/.net MapGuide applications to MGOS 4.0.
PHP Migration Overview
The PHP binding was the one I expect to be the most work because besides finally supporting PHP 8.1, the major feature of this new PHP binding is that constants.php is no longer required! This is because with vanilla SWIG we now can bake all the constants of the MapGuide API into the PHP binding extension itself! So I expect a lot of "include 'constants.php'" references needing to be removed.
Once all the constants.php references are removed, we found the prime issue with this new PHP binding. PHP didn't like some of our C++ classes had overloaded methods whose signatures did not exist in the parent class. This manifested in the form of fatal PHP errors like the following:
PHP Fatal error: Declaration of MgCoordinateSystemMeasure::GetDistance(MgCoordinate|float|null $arg1, MgCoordinate|float|null $arg2, float $arg3, float $arg4): float must be compatible with MgMeasure::GetDistance(?MgCoordinate $arg1, ?MgCoordinate $arg2): float in Unknown on line 0
In this case, our MgMeasure class has a GetDistance method of the following signature:
double GetDistance(MgCoordinate* coord1, MgCoordinate* coord2)
In the derived MgCoordinateSystemMeasure, it has a new overload of GetDistance that has this signature:
double GetDistance(double x1, double y1, double x2, double y2)
However, when this converted to PHP proxy classes by SWIG, PHP doesn't like this class setup because under its inheritance model, it is expecting the GetDistance overload with 4 double parameters to also exist in the base MgMeasure class. This is not the case, and thus PHP throws the above fatal error.
To workaround this problem, we had to use the SWIG %rename directive to rename the conflicting overload signature in MgCoordinateSystemMeasure in PHP to the following:
double GetDistanceSimple(double x1, double y1, double x2, double y2)
With this rename, there is no longer a signature conflict in the generated proxy class and PHP no longer throws a fatal error. Fortunately, only 2 classes in the MapGuide API have this problem, so the amount of method renaming is minimal.
Once this issue was addressed, I tried firing up the PHP implementation of the AJAX viewer and I got an interactive map! Everything seemed to be working until I tried to generate a map plot, and found my second problem. I was getting PHP fatal errors like this:
PHP Fatal error: Uncaught TypeError: No matching function for overloaded 'MgRenderingService_RenderMap' in quickplotgeneratepicture.php:115
Fortunately, this one was easier to explain and fix. In PHP 8.1 (maybe even earlier in the PHP 7.x series), the type checking became more stricter which meant int parameters must take integers, double parameters must take doubles, etc, etc, you couldn't pass ints as doubles or vice versa, and for a method like RenderMap of MgRenderingService, there are lots of overloads that take many different combinations of int and double parameters.
Our map plotting code was passing in strings where int/double parameters were expected. In PHP 5.6 this was allowed because the type checking was evidently more lax. Now such cases cause the above PHP fatal error. This was easy enough to fix, we just use the intval and doubleval functions to make sure ints are being passed into int parameters and doubles are being passed into double parameters.
And with that, the rest of the changes involving fixing up our exception handling code due to a major change with how MapGuide applications should be handling exceptions from the MapGuide API. As part of this SWIG binding work, we've flattened the MapGuide exception hierarchy into a single MgException class, and introduced a new exception code property to allow handling MapGuide exceptions on a case-by-case basis.
So if you were handling specific MapGuide exceptions like this:
1 2 3 4 5 6 7 8 | try { //Some code that could throw } catch (MgUnauthorizedAccessException $e) { ... } |
You would now rewrite them like this:
1 2 3 4 5 6 7 8 9 10 | try { //Some code that could throw } catch (MgException $e) { if ($e->GetExceptionCode() == MgExceptionCodes::MgUnauthorizedAccessException) { ... } } |
The reason for flattening the exception hierarchy was:
Java Migration Overview
.net Migration Overview
This migration was the one I had been dreading the most. Not because I feared this binding was going to be fragile, because we already had an exhaustive test suite which this binding passed with flying colors.
But rather, I had been dreading this one because all of our .net code that is going to use this binding (AJAX viewer, code samples, etc) are all legacy pre-historic aspx webforms and I wasn't sure if such code would accept the brand new .net development story I had planned for it.
Consider the current .net development story.
What does netstandard2.0 support imply? It implies your MapGuide application using these packages can work on all of these platforms. Now practically speaking, despite now being netstandard2.0 packages, these packages will only work on platforms where the underlying OS is Windows and (maybe) Linux as those are the platforms where we can actually compile the underlying supporting native libraries needed by these nuget packages. So no Mac OSX, no Xamarin, etc.
In practical terms, it means you are no longer shackled to legacy .net framework for building MapGuide .net applications. You can now use .net core from its earliest netstandard2.0-supported iterations all the way to the latest .net 6.0 (as of this post).
That's great and all, but going back to the original issue: Can the current suite of aspx webforms code accept this new way of consuming the .net MapGuide API and come along for the ride? I hope so! Because the alternative is to rewrite all of this code with more modern .net web technologies (razor pages maybe?), and while such a rewrite has merit and probably warranted, it is not warranted right now because that would add many more months of dev work to my already time-poor schedule. We have bigger fish to fry! We just hope this current codebase will cooperate with our new .net packaging paradigm with minimal effort.
So let's start with the basic facts.
Getting this to work on Linux
With the bindings now all being generated by vanilla SWIG and all working on Windows, it was a case of getting the build system fully working again on Linux with these new bindings and updated web tier components.
Fortunately, on the binding front, most of the CMake configurations added in the initial phases of this work only needed minor adjustments, so the bulk of the work was actually building PHP 8.1 and integrating this into the Apache httpd server, which we are also building from source and updating our various httpd/php config file templates to work with this new version of PHP.
Where we stand now
We now finally have MapGuide API bindings generated with vanilla, unmodified SWIG that work on both Windows and Linux. This has been a long and arduous journey and I can finally see the light at the end of this tunnel!
A new RFC has been posted for PSC discussion/voting. I hope there isn't strong opposition/dissent on these changes, because I truly believe that this work is absolutely necessary for MapGuide going forward. Newer versions of .net/Java/PHP will always get released and inevitably we will need our MapGuide API bindings to work on these newer versions. Our current infrastructure to keep up with newer .net/Java/PHP versions is just not maintainable or tenable.
If/when this RFC is adopted, the long overdue Preview 4 release should drop not too long after!
Posts
All Comments
