Bloggure

iOS 26.2 Sheet: remove Liquid Glass for small detents

2026-01-27T00:00:00+01:00

I recently encountered an interesting issue with UISheetPresentationController in iOS 26.2. When using a .pageSheet presentation style with a detent of .medium or smaller, iOS automatically applies the “liquid glass” background effect, completely ignoring any custom background settings.

The Problem

In iOS 26.2, Apple introduced changes to the visual appearance of .pageSheet presentations. When a page sheet does not take up the entire screen (typically on larger devices or when content remains visible behind the sheet), iOS automatically applies a “liquid glass” background effect that overrides any custom background settings you may have configured.

Interestingly, this issue only occurs when the sheet does not occupy the full screen. When the sheet takes up the entire screen, the automatic liquid glass effect is not applied and custom backgrounds work as expected.

This made my nice page sheet looks like the following :

Initial Attempts

My first instinct was to try setting the background effect to nil:

if #available(iOS 26.1, *) {
    controller.sheetPresentationController?.backgroundEffect = nil
}

Note that we need to guard the access to this property for 26.1 and later versions.

However, this approach didn’t work - iOS still applied the liquid glass effect.

The Solution

After some experimentation and research, I discovered the solution: using an empty UIColorEffect():

if #available(iOS 26.1, *) {
    controller.sheetPresentationController?.backgroundEffect = UIColorEffect()
}

This effectively tells iOS to use a solid color background instead of the automatic liquid glass effect.

And voilà, I’ve got the result I was expecting (and what was displayed prior to 26.2)

Conclusion

The automatic application of liquid glass effects in iOS 26.2 can be surprising, but with the UIColorEffect() solution, you can regain control over your sheet’s appearance and maintain your desired visual design.

iOS 26.2 Sheet: remove Liquid Glass for small detents was originally published by at Bloggure on January 27, 2026.

Streamlining Finances: Automating Bill Renaming with Apple Shortcuts

2026-01-07T00:00:00+01:00

The Problem: The “Downloads” Folder Chaos

We all know the struggle. You download a PDF invoice from your utility provider or internet service, and the file is named something useless like invoice_839204_export.pdf. These cryptic filenames make it nearly impossible to find specific bills later, clutter your file system, and create frustration when you’re trying to organize your finances.

The goal is simple: automatically rename these files to a standard, searchable format like YYYY-MM-DD_Company.pdf so you can easily find, sort, and manage your financial documents.

Common pain points:

Difficulty finding specific bills when you need them
Messy file organization that grows over time
Time wasted manually renaming files
Inconsistent naming conventions across different providers

The Solution: Apple Shortcuts

I chose Apple Shortcuts for this automation because it’s native to both macOS and iOS, completely free, and syncs seamlessly across all your Apple devices. Unlike complex Python scripts or third-party automation tools, Shortcuts provides a visual, user-friendly interface that makes it accessible to everyone - not just developers.

The best part? You can trigger these automations from the Share Sheet, Quick Actions, or even set up folder-based automation, making it incredibly convenient for daily use.

How the Shortcut Works

Before you download the shortcut, here is the logic behind the workflow. Breaking it down helps if you want to customize it later.

Input: The shortcut accepts a PDF or an image file (via the Share Sheet or Quick Actions).
Text Extraction: It extracts the text from the image, and asks ChatGPT or other AI models to extract vendor and date from the document
Formatting: It standardizes the date to ISO format (YYYY-MM-DD).
Renaming: It combines the variables into a new filename string.
Saving: It changes the file name in-place with the new one

The Logic Breakdown

The shortcut uses a combination of Apple’s built-in actions and AI-powered text extraction:

Text Extraction: Uses OCR (Optical Character Recognition) to read text from PDFs and images
AI Processing: Leverages ChatGPT to intelligently identify vendor names and dates
Date Standardization: Converts various date formats to consistent ISO format
Batch Processing: Can handle multiple files at once for efficiency

Pro Tip: The AI component makes this shortcut smarter than traditional regex-based solutions. It can handle different invoice formats and layouts automatically.

Get the Shortcut

You can download the shortcut directly to your library using the link below:

📥 Download: Rename Bills Shortcut

(Note: You might need to allow untrusted shortcuts in settings if you haven’t already, though Apple has changed how this works in recent iOS versions.)

Requirements:

iOS 16+ or macOS Ventura+
Apple Shortcuts app installed
Internet connection for AI processing (or local/offline alternative)
ChatGPT API key (free tier available)

Privacy Note: If you’re concerned about privacy or prefer offline processing, you can modify this shortcut to use local model or private cloud models instead of ChatGPT. The shortcut can be adapted to use either approach based on your preferences.

How to Set It Up

Once you have installed the shortcut, you need to configure a few variables to match your preferences:

ChatGPT API Key: Add your ChatGPT API key in the shortcut settings for AI processing
Naming Convention: If you prefer Company_Date instead of Date_Company, you can drag and drop the variables in the “Set Name” action.
Date Format: The shortcut uses ISO format (YYYY-MM-DD) by default, but you can modify the date formatting action if you prefer a different format.
File Types: By default, it handles PDFs and images (PNG, JPG). You can add more file types in the input action.

Configuration Tips:

Test with a few sample files first
Adjust the AI prompt if you need different extraction behavior
Consider adding error handling for edge cases

Usage Guide

Here is how to use it in daily life:

On macOS

Right-click a PDF or image file -> Quick Actions -> Select Auto rename Bill
For batch processing: Select multiple files -> Right-click -> Quick Actions -> Auto rename Bill

On iOS / iPadOS

Open the PDF or image -> Tap the Share icon -> Scroll down and tap Auto rename Bill
For batch processing: Select multiple files in Files app -> Tap Share -> Auto rename Bill

Advanced Usage

Folder Automation: Set up a folder action in macOS to automatically process new files added to a specific folder
Siri Integration: Add the shortcut to Siri for voice-activated renaming
Batch Processing: Process multiple files at once to save time

Pro Tip: Create a dedicated “Bills to Process” folder and set up a folder action to automatically rename files when they’re added.

Conclusion

Automation doesn’t have to be complicated code. With Apple Shortcuts, you can save yourself the 30 seconds it takes to rename a file—which adds up over a lifetime of paying bills.

Time Savings Calculation:

30 seconds per bill × 12 bills/month × 12 months/year = 6 minutes/year
Over 10 years = 1 hour saved
Over a lifetime = Significant time savings!

This shortcut demonstrates how AI-powered automation can make everyday tasks easier. The combination of OCR, AI text extraction, and Apple’s automation framework creates a powerful tool that’s accessible to everyone.

Streamlining Finances: Automating Bill Renaming with Apple Shortcuts was originally published by at Bloggure on January 07, 2026.

Tuist build test schemes

2025-05-22T00:00:00+02:00

Tuist build test schemes

I use tuist to build most of my iOS projects nowadays. And like every good software engineer I test the code that I deliver. I want to ensure that everything works according to what I expect is coming to my app.

Xcode and schemes

XCode is a fun IDE, it is slow, has his own temper when it comes to find references, refactor or even launch app. One of the things that is really strange when you’re using this IDE for the first time is that it does only build the active scheme. So, if your project has, let’s say, 10 schemes, and you refactor a method to add an argument. You won’t notice you have a build error until your build all schemes…

Build errors

I tend to have a lot of build errors during refactoring, but this is globally ok, I use them to pave the way to my final implementation. One of the thing that bothers me is that I don’t always catch all errors, and I need the CI to bail out because of a missing argument / protocol conformance method… This is not a cool thing in my daily process, I am interrupted to fix a build error that should never happen.

Build tests target automatically

As I am a tuist user, I want to be able to build all my tests target easily to prevent pushing something that does not even build (even before I can say that my tests are passing).

Command line-fu

At first I tried a basic thing, hoping that it would work (spoiler alert, it does not):

 tuist build '*Tests'

Scripting to the rescue

It seems that it is not supported out of the box by tuist, running schemes by using a wildcard operator to filter them. However, it is rather easy to do using basic bash scripting, so here is my basic solution

set -e
SCHEMES=$(xcodebuild -workspace MyProject.xcworkspace -list | grep Tests | awk '{print $1}')

echo "$SCHEMES" | while IFS= read -r s; do
   echo "Building $s"
   tuist build $s
done

I save this file under buildTests.sh, run a chmod +x buildTests.sh and then I can build my tests targets, in sequence, exiting on first failure. This is perfect for my use case, whenever I refactor too much, or I want to check that tests are still building, I can run this.

Downside

Script execution is rather slow, as there is not any parallelism involved, everything is building from scratch. It might be nice to run everything in parallel, but so far so good, it is ok for my use case !

Tuist build test schemes was originally published by at Bloggure on May 22, 2025.

Swift module registration

2025-04-28T00:00:00+02:00

Swift module registration

Let’s modularize our Swift code!

I am using tuist for a while now in my projects. This tool was initially bring into the project’s scope to ease day to day developer operations : no more fiddling with conflicts in xcodeproject files !

Tuist ?

What is tuist by the way ?

Have you ever booted an iOS project, from a few years things have evolved a bit.

Before 2020 I’d say we were doomed to using xcworkspace for defining complex projects.

Cocoapod and Carthage were the cool kids on the block, allowing to download libraries and use them in our beautiful apps.

After 2020, and still now, Swift development have changed to massively using SPM: the built in dependency management tool baked in the swift toolchain. The process is straightforward and easy to set up, a few clicks in XCode and voila! The other way of using SPM is by using a Package.swift file to describe what you want to achieve.

The swift file works very well but lacks from a lot of advanced features available in XCode projects. Or if it is possible, it is not convenient to do.

This is where tuist fills the gap, like Gradle in the Java ecosystem did a few years ago. We can finally use Swift to describe our Swift projects. This means no more copasting things over and over and the dreaded xcodeproj is no more : you’ll only ever have to merge swift files !

Code modularity appears !

It also came in handy for bringing modularity into our codebase. We managed to split dependencies and make modules per feature or functional scope.

This comes at a cost, having to register our different modules to our main app. When I’m talking about registering, I’m considering handling dependencies, routing and navigation. This can represent a lot of modules, a lot of useless lines in our codebase.

To be clearer, our main app contains authentication logic as well as basic http interactions, our modules are dumb as they depend on this external provider to be able to issue any http call.

First implementation

Every of our module was being added to our ResourceLoader class that would call the necessary initializers to set things in motion like the following

func register(){
  LoggingModule.register()
  …
}

With our ResourceLoader implementing a protocol exposing everything that was useful for our submodules, protocol which was made available through a simple used-everywhere dependency.

Auto-registration for the win !

We can do module autoregistration by scanning embedded frameworks. As we can do with IoC, the idea is to let every module declare itself to the main consumer. No more long register method in our application launch, and new modules are automatically discovered at launch time !

Let’s illustrate this with some code, we declare a protocol that will allow consumer to call registration for our module.

public protocol ModuleRegistration {
    func register()
}

This is our base building block for registration, every module implements ModuleRegistration to contribute to the main app.

In every module project, we then set a class that will be responsible for registration. It will implement this specific protocol and be populated by its full name into Info.plist.

@objc
public class MyFrameworkRegistration: NSObject, ModuleRegistration {
    public func register() {
      // inject into the global context our dependencies
      // for instance we can do
      // Container.register(MyLogging.self, MyLoggingImpl.self)
    }
}

Please notice important things in this class. It needs to be annotated @objc and inherit from NSObject to be discoverable later on.

The magic being this is that we will declare this class to be our NSPrincipalClass in the Info.plist of our framework.

To do so, we add the final touch by enriching the Info.plist of our module using Tuist project’s description :

.target(
        name: "MyFramework",
        destinations: .iOS,
        product: .framework,
        bundleId: "org.9h41.ios.modules",
        deploymentTargets: .iOS("16.0"),
        infoPlist: .extendingDefault(with: [
             "NSPrincipalClass": "MyFramework.MyFrameworkRegistration",
        ]),
        sources: .paths(["MyFramework/Sources/**"])
)

Main app implementation

Then in our main app, we scan for NSPrincipalClass in all of our included bundles , one just need to call the Modules.autoregister() method in application startup.

public enum Modules {
  public static func autoregister() {
          Bundle.allFrameworks.compactMap(\.principalClass)
              .forEach { clazz in
                  autoregister(clazz: clazz)
              }
  }
  static func autoregister(clazz: AnyClass) {
        let instance = clazz.alloc()
        if let module = instance as? ModuleRegistration {
            module.logger.debug("Doing registration for \(clazz)")
            module.register()
        }
    }
}

Our main app will then scan all included bundles, look for NSPrincipalClass, test if it matches the protocol requirement and then calls the registration function.

The declared dependencies in our frameworks are now properly registered inside our app context, dependency injection system or anything you can imagine.

Swift module registration was originally published by at Bloggure on April 28, 2025.

Swift macro : @VisibleForTesting

2024-04-19T00:00:00+02:00

As an ancient Java developer, I’ve learned to use a set of annotations to bring meta programming in my projects.

Meta programming can be considered as an orthogonal thing to your code, you can inject code to log things, to wrap execution in a transaction or simply provide some context to your fellow developer.

One of my favorite context providing annotation at this time was brought by Google-Annotations package : @VisibleForTesting

Its goal is rather simple: provide the context that the visibility of the variable / method is not as restricted as it should be, but this is for the sake of testing.

When going back to my loved XCode (just kidding), I miss these kind of useful information.

Of course you can add a comment, that maybe someone will read if he begins to wonder why the visibility is too important.

// this method should be private but we want to access it from unit test code  
func doStuff() { }

You can also play with the deprecation annotation to trigger a warning (one more to add and parse with your eyes…)

@available(*, deprecated, message: "This is visible for testing")  
var myState: State

But one thing I was really missing is the ability to really set the proper visibility on my fields while keeping the testability.

Recently, Swift 5.9 had added Macro support. Macros can be seen as ways to generate code based on specific instructions (this brings back old Java-apt memories).

Macro types

There are multiples macro types, whether they can attach to fields, and depending on what they can do:

Providing accessors
Generating code alongside the annotated field
Generating code “in-place”

There are two ways of calling macros :

Attached ones with @MacroName
Freeform ones with #MacroName

I will not enter the details of each type and implementation, you will see more on this later here and can scout on GitHub repositories for inspiration.

Attached macros are written with a leading @ and can generate code alongside some of our declaration. This allowed me to introduce my own @VisibleForTesting for swift implementation.

The idea behind this is really simple, generate specific code with public visibility that wraps call to the “non-exposed” real method.

This way we get the best of both worlds, we keep our fields private, we tell our colleagues that this field is available for testing and we are able to test it properly.

What does it look like ?

To use this library, you need to add an SPM dependency on this repository: https://github.com/CedricGatay/SwiftMacroUtils

.package(url: "https://github.com/CedricGatay/SwiftMacroUtils", branch: "main")

Then, let’s say you want to give access for testing to the name var of the Dog struct to your testing code, you simply need to do the following

struct Dog {
    @VisibleForTesting
    private var name: String?
}

Under the hood, the macro will generate a public accessor that you will be able to use in your tests

public var __test_name: String? {
    get {
        self.name
    }
    set {
        self.name = newValue
    }
}

The same goes for let, func, and init . The only specific thing to keep in mind that if you annotate a class initializer, you need to mark it as required, otherwise the build will fail (but a nice comment will tell you why).

Swift macro : @VisibleForTesting was originally published by at Bloggure on April 19, 2024.

Dark Mode iOS Snapshot

2021-01-10T00:00:00+01:00

Dark mode support

As you might know, iOS supports Dark mode since iOS 12. It is pretty straightforward to implement it by using dynamic colors. Either system provided ones or adjust them using trait collections.

Dynamically switch

At times, we can not rely on default colors but we have to listen for traitCollection changes in order to do what is appropriate for adapting the UI to the mode being active.

It is easy to do by checking current traitCollection :

override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {
    super.traitCollectionDidChange(previousTraitCollection)

    let userInterfaceStyle = traitCollection.userInterfaceStyle 
    // Either .unspecified, .light, or .dark
}

App switcher tricks

One thing that I was not aware is that iOS switches back and forth between active mode and the complementary when the app goes to the background :

To have proper representation in application switcher, if the trait collection is changed, the OS takes a screenshot of your app using light and dark schemes.

Consequences

This can lead to subtle problems, in my case, I was loading a specific stylesheet for MapBox, that, when loaded, was registering / refreshing elements on map. Thus, when the app was put to the background, a lot of things were happening, without a clear explanation (and the app was sometimes crashing due to the very fast switching between map stylesheets).

The workaround is rather simple : if the app is in the background we prevent loading the stylesheet, the trade-off is acceptable : the app can display an invalid preview in application switcher, but, it is nicer on CPU / Network.

Dark Mode iOS Snapshot was originally published by at Bloggure on January 10, 2021.

Git-gone

2020-12-31T00:00:00+01:00

Git daily usage

If you’re like most developers nowadays you make an extensive usage of git across a large number of repositories.

The now-classic branching model that consists in using a branch for every fix / feature / experiment before creating a merge request is perfect for collaborating efficiently. However it comes with one downside, local branches can quickly become messy and removing stale branches is not that easy

Removing remote branches

git is a really well designed tool and removing remote references from your local repository is easily done by

git remote prune origin

This will remove local references to non existing branches, however it is not useful to remember this command, we can configure git so that it prunes automatically on fetching :

git config --global fetch.prune true

Removing local branches

This is where things can be quite messy, as local branches might have been merged, rebased, or squashed, and “classic” commands allowing to detected merged branches are not always working as they ought.

If you search how to clean up local branches, you might find a lot of commands involving git branch --merged with grep and xargs all the way.

I found out a little neat tool to do so, called git-gone (github/lunaryorn/git-gone), written in Rust 🧡

Install it

As all rust project, it is packaged and easy to install using cargo

cargo install git-gone

List branches to prune

Before doing anything silly, we can list the branches that are candidate to removal (the -f flag forces fetching remote)

$ git gone -f list
feature/asciidoc
fix/imageCompress

Prune’em all

And finally, you can remove them (the -f flag is still here to sync with remote)

$ git gone -f prune
Deleted feature/asciidoc (restore with `git checkout -b feature/asciidoc 8f007a`)
Deleted fix/imageCompress (restore with `git checkout -b fix/imageCompress af523b`)

git-gone is even clever enough to give you the command to restore a branch if change your mind (as long as you did not git gc the revision is still available locally, so you can restore it)

Git-gone was originally published by at Bloggure on December 31, 2020.

macOS tools checklist

2020-12-06T00:00:00+01:00

Welcome to the mac world

Wether you’re new to macOS or an user coming from different machines, the tools we tend to use is very important to be productive.

Here you’ll find my list and what I install on a fresh machine to get started.

System tools

First and foremost, I start with brew to handle all my packages, but instead of doing so manually, I use my dotfiles and my “magic” install script that does all the heavy lifting for me.

Keyboard tools

I use a TypeMatrix with a Colemak layout and also the internal keyboard of my laptop with its default layout. Colemak layout is available on a fresh macOS install but it is far from perfect as there are a lot of missing dead keys (to type accented letters mainly), so I start by installing the layout provided on this page: Colemak mac

To easily switch between the two and get almost the same feeling, I use Karabiner Elements.

Everyday tools

sdkman: to manage installation of various sdk (mainly Java based)
iTerm: nice terminal app with profiles
tmux: multi terminal in one window, switching terminal with a keystroke
zsh: Z-Shell
starship: fast shell prompt
ripgrep: faster grep
bat: nice cat alternative (with paging / highlighting)
exa: replacement for ls
Alfred: Spotlight with more features, this is my main app launcher / switcher
SetApp: App subscription service, use many tools from this (BetterTouchTool, iStat, BarTender…)

macOS tools checklist was originally published by at Bloggure on December 06, 2020.

SwiftUI UIKit Interop

2020-12-03T00:00:00+01:00

Now that iOS13 is available for more than year, we can start to set it as a lower bound for our deployments.

This allows us to play with all sugar that Apple put in it, one of the biggest thing is the arrival of SwiftUI to supercede UIKit (write cross platform UIs and so on).

Bridging the two worlds

Using SwiftUI from UIKit

The first thing we might try to do, is embedding a SwiftUI View inside our UIViewController based application. To do so, Apple gives us UIHostingViewController which is a simple bridging controller, straightforward to use.

struct MyNewView: View {
    var view: some View {
        Text("I'm in SwiftUI")
    }
}
class MyNewViewViewController: UIHostingViewController {
    init(){
        super.init(rootView: MyNewView())
    }
}

UIViewController in SwiftUI

However, at times we still need to reuse our good old UIViewController, either because we can not afford a full SwiftUI rewrite, so we want to keep old code and migrate pieces by pieces or because we are using something not yet adapted to SwiftUI.

In my case it was using the camera to scan a QRCode.

Non elegant solution

I faced a few issue with examples I found out, most of them are adding an extension to the UIViewController that makes it conform to UIViewControllerRepresentable.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

extension MyViewController: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyViewController>) -> UIViewControllerType {
        self // don't .init() please, class instance is already available
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyViewController>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyViewController()
  }
}

I find this not easy to read, as we’re doing weird thing by returning self from a function named makeUIViewController. Some example are telling to return MyViewController() instead of self. Please don’t do this otherwise you’re creating the UIViewController twice for each call !

I also had a leak when using Combine (more to come about this great framework), my Cancellables were never freed, leading in a memory cycle that kept the UIViewController living even though it was no longer presented.

It is important to do proper house keeping in the dismantleUIViewController method if you don’t want to use too much memory and slow down your app.

Nice looking way of doing

You will find a working example below, basically we need to implement a UIViewControllerRepresentable struct to represent be the container for our UIViewController in the SwiftUI world.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

struct MyGreatView: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyGreatView>) -> UIViewControllerType {
        MyViewController()
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyGreatView>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyGreatView()
  }
}

SwiftUI UIKit Interop was originally published by at Bloggure on December 03, 2020.

XCode unit test and inheritance

2020-12-02T00:00:00+01:00

As I was working on an iOS project, I added unit tests to ensure things are not behaving badly (and will not).

During the process, a common pattern showed up and a few fields were required, I came up with the idea to basically create a BaseTest for my tests, so that everything is unified.

Base idea

I came up with something like the following for my tests

class BaseTest<T, Action>: XCTestCase {
    var subject: T!
    var actions: [Action]!

    override func setUp(){
        subject = T()
        actions = []
    }
}

class LoginTest: BaseTest<LoginMiddleware, LoginAction> {
    func test_loginIsWorking(){
        // ...
    }
}

It worked very well within XCode, I could run the tests by hitting the 🔹 in the gutter.

Bad things happen

The thing that I discovered later (thanks to the CI feedback), is that XCode was not properly discovering my tests as it should. At first I blamed the fact that my new tests were not at the top level of my sources folder (and the other ones were), but it was easy to check that this was not the problem at all.

Then, I blamed fastlane and thought that I’ve missed something in my test target configuration or something, but in fact, the problem was similar when using classical CMD + U key combo.

XCode was simply not discovering my test.

Workaround

Inheritance is often misused, in this case, I think it is relevant, but I applied classical way of working around this. I changed my BaseTest to a BaseHelper instead, to which the test delegates the calls.

With this, the test class properly inherits XCTestCase and is discovered as expected (even in subfolders).

class BaseHelper<T, Action>{
    var subject: T!
    var actions: [Action]!

    init() {
        subject = T()
        actions = []
    }
}

class LoginTest: XCTestCase {
    var helper: BaseHelper<LoginMiddleware, LoginAction>!

    override func setUp(){
        helper = .init()
    }
    func test_loginIsWorking(){
        // ...
    }
}

The nice thing in this solution is that the setUp call is no longer magical !

XCode unit test and inheritance was originally published by at Bloggure on December 02, 2020.

Bloggure revival

2020-12-01T00:00:00+01:00

It’s been a long time

It’s been a very long time since last post (5 years…).

I am convinced that blogging is useful, at least for my present self, and for my future self that tends to lose track of important things.

What will this be about ?

In the past I blogged a lot about Java / Maven and so on, my days have evolved to another languages, so I guess there will be less JVM things (but may be a few Kotlin) and more Swift / Rust on the other end.

Technical stack

In a blog reboot, we (I mean dev) like to follow the latest trend and migrate our blog system to latest hype stack. I will avoid this and focus on writing instead, so the site stays in its 15’ shape:

jekyll
github-pages
markdown (I think jenkins-asciidoc is around the corner though)
github actions for building

The sole new thing is that I’m trying to write using gitpod.io to get a distraction free environment.

Bloggure revival was originally published by at Bloggure on December 01, 2020.

Firebase + XCode

2018-03-13T00:00:00+01:00

Il est courant maintenant d’utiliser Firebase dans les applications mobiles. Que ce soit pour la partie statistiques, les notifications ou le reporting des crashes. L’intégration est très facile, mais peut devenir compliquée dès lors qu’on manipule des target différentes avec des configurations différentes. Cet article va vous détailler une façon simple mais efficace de gérer ces différences.

Multiples fichiers `plist`

Les fichiers plist sont des fichiers XML de configuration pour XCode. Lors de la création d’un projet dans Firebase, il est possible de récupérer une version générée contenant les bonnes variables pour votre projet. Le problème qui peut se produire est lorsqu’on génère plusieurs livrables avec des configurations qui doivent être différentes grace aux target. Il n’est pas possible, ni confortable, de gérer le cas de plusieurs fichiers plist dans les sources. La redéfinition du nom du fichier à faire utiliser par Firebase ne marche pas à tous les coups et il a tendance à aller lire la valeur par défaut GoogleService-Info.plist.

L’idée est donc d’utiliser un script au build qui se chargera de configurer correctement le fichier plist qui sera inclu dans le livrable.

Première étape : variabilisation

Pour être capable de générer le fichier plist correctement, il est nécessaire de le variabiliser. Dans mon cas, j’ai identifié les valeurs suivantes qui devaient être variabilisées:

GOOGLE_APP_ID
BUNDLE_ID
CLIENT_ID
REVERSED_CLIENT_ID

J’ai donc ajouté des variables à la configuration de mon build pour représenter ces valeurs qui doivent être personnalisées. J’utilise des fichiers .xcconfig mais ceci fonctionne également avec l’ajout manuel (dans Build Settings > + > Add User-Defined settings)

Unresolved directive in 2018-03-16-FirebasePListXCode.adoc - include::site/static/lightbox.adoc[]

En plus de ça, j’ai modifié le fichier GoogleService-Info.plist téléchargé sur Firebase pour enlever les éléments qui allaient être remplacés à terme. Plus exactement, j’ai remplacé les valeurs par des chaînes du type WILL BE REPLACED AT BUILD TIME, qui me permettent facilement de me rendre compte d’un oubli de configuration.

Deuxième étape : génération du fichier

Une fois le fichier et l’environnement préparé, il ne reste qu’à générer la version finale. Pour se faire, je me base sur le système de build de XCode qui permet de définir simplement des étapes. Les variables définies dans la configuration du projet sont en effet disponibles simplement lors de l’exécution des étapes de build. En utilisant l’outil defaults inclu dans macOS pour la manipulation des fichiers plist, il est donc facile de définir les valeurs attendues dans le fichier. J’ai ainsi rajouté une étape shell script correspondant à ceci dans le processus de build.

defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" GOOGLE_APP_ID ${GOOGLE_APP_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" BUNDLE_ID ${PKG_IDENTIFIER}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" CLIENT_ID ${CLIENT_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" REVERSED_CLIENT_ID ${REVERSED_CLIENT_ID}

Enfin, il faut ordonner cette étape de build après celle de copie des ressources, pour effectuer la modification uniquement dans le fichier binaire de l’application et non dans les sources du projet.

Bénéfices

Il est donc facile de disposer de configuration différente de Firebase entre le debug et la release par exemple. Ainsi vous pouvez tester l’envoi de notification, par exemple, sans risquer de polluer des utilisateurs de production, ou activer le crash reporting uniquement en production par exemple.

Firebase + XCode was originally published by at Bloggure on March 13, 2018.

Jenkins Workflow Plugin

2016-01-20T00:00:00+01:00

Un des points génants lors de l’utilisation de Jenkins est le coté volatile de la configuration des jobs de builds. Il est souvent nécessaire de jouer de click-click pour faire la configuration des jobs sur Jenkins et de se reposer sur un plugin permettant de versionner, autant que possible, les configurations utilisées.

Mais, une fois que vous aurez lu cet article, vous vous rendrez compte que c’est le passé. Attention toutefois, cet article parle de Jenkins, de Docker et de Groovy, n’ayez pas peur, tout est presque trop simple…

Prérequis Jenkins

Jenkins avec accès à Docker

Nous avons l’habitude d’utiliser un Jenkins lancé dans un container depuis quelques temps.

Nous utilisons l’image maintenue par Michael Bitard agileek/docker-jenkins.

Nous lançons cette image en lui fournissant de quoi exécuter le binaire docker client sans soucis :

docker run
       -d --restart="always" --name jenkins
       -u $(id -u):$(getent group docker | cut -d: -f3) # (1)
       -p 8080:8080
       -v /var/jenkins_home:/var/jenkins_home # (2)
       -v $(which docker):/usr/bin/docker # (3)
       -v /var/run/docker.sock:/var/run/docker.sock # (4)
       -v /usr/lib/x86_64-linux-gnu/libapparmor.so.1:/lib/x86_64-linux-gnu/libapparmor.so.1 # (5)
       agileek/docker-jenkins # (6)

Le container est lancé avec l’utilisateur courant et le groupe docker pour pouvoir accéder au docker.sock
Pour éviter les incohérences de chemin, le chemin racine du jenkins est le même en dehors et dans le container
Le binaire docker du système est fourni dans l’image
Le socket docker est également fourni pour que le client puisse "parler" au démon
La bibliotheque apparmor est nécessaire pour le bon fonctionnement de docker client

Jenkins workflow plugin

Pour utiliser la suite des éléments, vous aurez besoin des plugins gérant la notion de workflow dans Jenkins :

Unresolved directive in 2016-01-20-JenkinsWorkflow.adoc - include::site/static/lightbox.adoc[]

Ensuite, il nous est possible de créer un job de construction de type workflow :

Unresolved directive in 2016-01-20-JenkinsWorkflow.adoc - include::site/static/lightbox.adoc[]

Premier job Workflow

Ensuite, c’est là que la magie opère, plutôt que de devoir sélectionner les n-items voulus et remplir chaque étape du build, nous pouvons maintenant le décrire en utilisant du code ! Ainsi, en copiant/collant le script suivant dans la partie idoine, vous devriez avoir un job bien configuré qui marche, du premier coup !

def m2Repo = '-v /var/jenkins_home/.m2:/home/jenkins/.m2' //  # (1)
def timezone = '-e TZ=Europe/Paris' // # (2)
docker.image("codetroopers/jenkins-slave-jdk8-restx")
    .inside("${m2Repo} ${timezone}"){ //  # (3)
    git branch: 'master', url: 'https://github.com/code-troopers/jenkins-workflow-demo-repo.git' // # (4)
    sh "MAVEN_OPTS=-Dfile.encoding=UTF-8 mvn clean install -B -Ppackage" // # (5)
    step([$class: 'ArtifactArchiver', artifacts: 'srv/target/dependency/webapp-runner.jar, srv/target/*.war, run.sh']) // # (6)
    step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml']) // # (7)
}

Partage du dépôt Maven local (pour gagner en temps de build)
Export de la timezone (pour les tests unitaires de l’exemple)
Démarrage du conteneur de build avec la bonne timezone ainsi que le dépôt partagé
Clonage des sources
Lancement du build (en forçant l’UTF-8)
Archivage des produits du build
Archivage des résultats des tests

Comme vous pouvez le voir, le script est relativement parlant et permet en plus de s’affranchir du clickodrome de configuration dans l’interface de Jenkins !

Il est intéressant de noter que l’image Docker qui sert au build est une image personnalisée. Ce n’est pas parce qu’elle inclut un quelconque fonctionnement permettant de builder en utilisant le plugin Workflow. Elle sert de base uniquement car elle met à disposition la partie npm nécessaire au build de la partie frontend de l’application RestX.

Grouper les étapes

Le plugin workflow permet en plus de grouper les différentes étapes d’un build pour permettre, par exemple, de le lancer sur plusieurs environnement différents. Ici nous ajoutons simplement un nom de groupe pour notre étape de build.

stage 'build' // # (1)
    def m2Repo = '-v /var/jenkins_home/.m2:/home/jenkins/.m2'
    def timezone = '-e TZ=Europe/Paris'
    docker.image("codetroopers/jenkins-slave-jdk8-restx").inside("${m2Repo} ${timezone}"){
        git branch: 'master', url: 'https://github.com/code-troopers/jenkins-workflow-demo-repo.git'
        sh "MAVEN_OPTS=-Dfile.encoding=UTF-8 mvn clean install -B -Ppackage"
        step([$class: 'ArtifactArchiver', artifacts: 'srv/target/dependency/webapp-runner.jar, srv/target/*.war, run.sh'])
        step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
    }

Étape nommée pour l’exécution de la construction de l’application

Mettre de côté les fichiers pour plus tard

La notion de stash bien connue des utilisateurs de git est également présente. Elle permet de mettre de côté des fichiers pour les réutiliser à une étape ultérieure du workflow de build. Ceci permet d’éviter l’archivage de produits du build pour des raisons "techniques".

stage 'build'
    def m2Repo = '-v /var/jenkins_home/.m2:/home/jenkins/.m2'
    def timezone = '-e TZ=Europe/Paris'
    docker.image("codetroopers/jenkins-slave-jdk8-restx").inside("${m2Repo} ${timezone}"){
        git branch: 'master', url: 'https://github.com/code-troopers/jenkins-workflow-demo-repo.git'
        sh "MAVEN_OPTS=-Dfile.encoding=UTF-8 mvn clean install -B -Ppackage"
        step([$class: 'ArtifactArchiver', artifacts: 'srv/target/dependency/webapp-runner.jar, srv/target/*.war, run.sh'])
        step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
        stash includes: 'run.sh,srv/target/dependency/webapp-runner.jar,srv/target/*.war,Dockerfile', name: 'dockerBuild' // # (1)
    }

Enregistrement d’une liste de fichiers associée à un nom pour une utilisation ultérieure

Étape de construction d’une image Docker

stage 'docker' // # (1)
node{ // # (2)
  ws{ // # (3)
    unstash 'dockerBuild' // # (4)
    docker.build("codetroopers/jenkins-workflow-demo:${env.BUILD_ID}") // # (5)
  }
}

Création d’une nouvelle étape
Permet de distinguer un ensemble d’opération de build (peut accepter les labels pour restreindre sur des noeuds)
Déclenche la création d’un nouveau workspace
Récupère les fichiers mis de côté sous le nom dockerBuild
Construction d’une image docker avec pour tag le numéro de build en cours ($BUILD_ID)

Workflow et gestion multibranche

Dans nos façons de fonctionner qui sont maintenant devenues habituelles, nous utilisons de façon intensives les branches pour isoler nos développements. Un des points fastidieux est de configurer un nouveau job Jenkins pour chaque branche afin de valider son bon fonctionnement et ne pas se rendre compte trop tard d’un build au rouge.

Le plugin 'Workflow Multibranch' simplifie de façon drastique ce genre de cas, il suffit de rajouter un descripteur de build dans les sources. Le fichier correspondant est tout simplement appelé Jenkinsfile.

stage 'build'
    def m2Repo = '-v /var/jenkins_home/.m2:/home/jenkins/.m2'
    def timezone = '-e TZ=Europe/Paris'
    docker.image("codetroopers/jenkins-slave-jdk8-restx").inside("${m2Repo} ${timezone}"){
        checkout scm // # (1)
        sh "MAVEN_OPTS=-Dfile.encoding=UTF-8 mvn clean install -B -Ppackage"
        step([$class: 'ArtifactArchiver', artifacts: 'srv/target/dependency/webapp-runner.jar, srv/target/*.war, run.sh'])
        step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
        stash includes: 'run.sh,srv/target/dependency/webapp-runner.jar,srv/target/*.war,Dockerfile', name: 'dockerBuild'
    }

stage 'docker'
node{
  ws{
    unstash 'dockerBuild'
    docker.build("codetroopers/jenkins-workflow-demo:${env.BUILD_ID}")
  }
}

Il faut bien entendu remplacer l’endroit où nous faisions le git clone pour qu’il soit dynamique par rapport à ce qu’on construit. Le terme checkout scm permet de s’assurer de ce fonctionnement.

L’intérêt est que chaque branche qui sera buildée n’aura pas son historique mélangé avec une autre (là où les jobs de validation de Pull Request ont tendance à tout mélanger). De plus, un changement dans le process de build sera directement versionné. Il n’y aura donc pas besoin de penser à éditer le job lors du merge sur master (on a tous vécu ce genre de situation énervante) !

Attendre une confirmation utilisateur

Un des points intéressant de ce plugin est qu’il permet la mise en pause des constructions. Ainsi, il est possible de mettre en pause une construction correspondant à une livraison et de lui faire attendre une validation manuelle par exemple.

stage 'build'
    def m2Repo = '-v /var/jenkins_home/.m2:/home/jenkins/.m2'
    def timezone = '-e TZ=Europe/Paris'
    docker.image("codetroopers/jenkins-slave-jdk8-restx").inside("${m2Repo} ${timezone}"){
        git branch: 'master', url: 'https://github.com/code-troopers/jenkins-workflow-demo-repo.git'
        sh "MAVEN_OPTS=-Dfile.encoding=UTF-8 mvn clean install -B -Ppackage"
        step([$class: 'ArtifactArchiver', artifacts: 'srv/target/dependency/webapp-runner.jar, srv/target/*.war, run.sh'])
        step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
        stash includes: 'run.sh,srv/target/dependency/webapp-runner.jar,srv/target/*.war,Dockerfile', name: 'dockerBuild'
    }

stage 'docker'
node{
    ws{
        unstash 'dockerBuild'
        def built = docker.build("codetroopers/jenkins-workflow-demo:${env.BUILD_ID}")
        input 'Is everything ok ? Run app ?' // # (1)
        echo "We can run the docker-compose up here"
        def outcome = input message: 'We can even have parameters to answer this question', parameters: [ // # (2)
            [name: 'myChoice', description: 'My choice', choices: 'Choice 1\nChoice 2\nChoice 3', $class: 'ChoiceParameterDefinition']
        ]
        echo "You have chosen ${outcome}" // # (3)
    }
}

input met en pause la construction et permet de continuer ou interrompre celle-ci
Il est également possible de permettre à l’utilisateur de faire un choix
Ici la valeur sélectionnée par l’utilisateur est écrite dans la sortie du build.

J’espère que cet article vous donnera l’envie d’essayer de rationnaliser un peu plus la configuration de vos job Jenkins en les stockant dans votre SCM

Jenkins Workflow Plugin was originally published by at Bloggure on January 20, 2016.

Avoid Proxy Headaches in Docker with redsocks

2015-11-16T00:00:00+01:00

Proxying with Docker

When using docker under a corporate proxy, it can be cumbersome to have a working networking in all containers. You often end up being blocked by specific network access which does not seem to be properly forwarded to the proper proxy. For example when using apt.

Classic way of doing

There is a documented way of using a proxy, by adding command-line switches to your docker deamon. However, it does not seem to work everytime and could require exporting additional settings to your in-container applications (in my experience though).

Why not using docker

Nicolas pointed me an image he created to help with the setup of a corporate proxy. It uses redsocks under the hood that listen to the docker socket and automatically add the glue to do the forwarding through the proxy.

Easy proxying in docker is just one command away ! (fill in the blank of your proxy ip and port)

docker run \
       --restart=always \
       --privileged=true \
       --net=host \
       -d ncarlier/redsocks \
       $PROXY_IP $PROXY_PORT

Avoid Proxy Headaches in Docker with redsocks was originally published by at Bloggure on November 16, 2015.

Faster ssh multi hop

2015-09-07T00:00:00+02:00

Multi Hop

It is often required that, for security reason, you have to hop through a SSH gateway to access other machines. While this is perfectly fine and simple to do, it is often cumbersome to open a new session. However, with a small script you can speed up your access to machines even with such a restriction in place.

Classical way of hop’ing

Let’s say our gateway is named gateway and our target host myAppHost the classical way of doing it would be :

ssh gateway
you@gateway $ hostname
gateway.my.tld
you@gateway $ ssh myAppHost
you@myAppHost $ hostname
myAppHost.my.tld

Faster way of hop’ing

A quicker way of doing this is to specify the ssh command directly, there is one thing to tell ssh though: allocating a TTY even if it does not seem to be connected to one. In fact, the command supplied to ssh is not supposed to be interactive, that is why you need to give this hint to SSH :

ssh -t gateway ssh myAppHost
you@myAppHost $ hostname
myAppHost.my.tld

Script this !

The script is really simple, and only consists in the following

#!/bin/sh
ssh -t gateway ssh $1

Save this in your path and give it the run permission then you are all set (mine is named gssh). All you have to do to connect is now a simple gssh myAppHost

Faster ssh multi hop was originally published by at Bloggure on September 07, 2015.

How to get all failing tests for a multimodule Maven project

2015-09-03T00:00:00+02:00

Maven testing

One of the bothering thing being a contractor is that you often happen to work on a project with a skip tests flag set on all developers computer.

One of the thing I tend to do when on such project is enabling tests and trying to fix as much as possible (often the fixes are easy to do).

Multi module testing

By design, surefire plugin make the build fail if there is a test failure. While this is ok in single module, when working with multi-module project it can be nice to run all tests on all modules regardless of the failures happening in some modules.

Maven is a great tool and allows such a behavior very easily, it allows two command line switches for that :

--fail-at-end : will fail the build at the end if there is test failures
--fail-never : will never fail the build, even if there is test failures

Flags behavior differences

There is one thing to understand when using the --fail-at-end flag, it will fail the build at end for a module with test failure but it will also prevents building of dependent modules.

With a small example it become obvious. Let’s say that we have a multi project containing the following :

core : containing model objects and services
web : containing web views for browser access
javafx : containing desktop application classes

It is straightforward to see that web and javafx modules will depends on the core module.

fail-at-end

If using the --fail-at-end flag, a test failure in the core module will prevent building the web and javafx module completely : you will not be able to track tests failure before fixing the ones from core (at least on a single build command).

fail-never

If using the --fail-never flag, a test failure in the core module will be reported but the build and tests of the web and javafx modules will be built and their respective tests errors will also be reported.

Tired of typing

If you find that typing --fail-at-end is too long, remember yourself it short alias : -fae.

The same is also available for the --fail-never flag with : -fn.

How to get all failing tests for a multimodule Maven project was originally published by at Bloggure on September 03, 2015.

Auto apply a keymap using udev when a Typematrix is plugged

2015-09-01T00:00:00+02:00

Switching keymap

As some of you might know, I am now using a Typematrix 2030 on a daily basis. When I switched to this great keyboard I also adopted a new layout on it : Colemak.

However, to be able to pair with others not using a Colemak mapping, I did not set the default mapping to Colemak but I instead use an udev rule to set the input method to Colemak only for the Typematrix.

Write a keymap switch script

Thanks to @BitardMichael tips and existing scripts I ended up with the following script saved in /usr/local/bin/set_typematrix_colemak_mapping

One of the tricky part was having a way of executing the script only when the keyboard is ready, without blocking udev’s job (or the keyboard is not yet visible by the X system). The workaround I found was scheduling the execution of the job with the simple at command.

Tell udev to run the script on keyboard detection

The process is really easy, all you need to do is to add the following to a new file : /lib/udev/rules.d/85-typematrix.rules

Adapting it to your use case

If you are using another keyboard than a Typematrix you will need to adapt the udev rule with the proper Vendor / Product IDs (you can grab them with lsusb). For the xinput part, you will need to adjust the grep to match your hardware.

Of course the same goes for your layout : colemak / dvorak / bépo …

Auto apply a keymap using udev when a Typematrix is plugged was originally published by at Bloggure on September 01, 2015.

Debug Failsafe Integration Test easily

2015-04-13T00:00:00+02:00

Arquillian testing

Arquillian testing is very convenient to get a full environment deployed on an application server and test quickly. However sometimes we need to debug what’s inside.

Launch Maven in Debug mode

One way of doing it can be launching Maven in debug mode with the mvnDebug command instead of the classical mvn. It will open a JPDA debugger on port 8000 by default, you then just need to connect to it with your preferred IDE. But, if there is forked processes, you won’t be able to debug inside them.

Launch Failsafe Integration Tests in Debug mode

When using Arquillian, there is a high probability that Arquillian is running in a forked process (with embedded containers).

There is an easy way to tell maven-failsafe-plugin to wait for a debugger when starting : use the -Dmaven.failsafe.debug property.

You can even specify the options as you would in $JAVA_OPTS to change ports / wait…

Debug Failsafe Integration Test easily was originally published by at Bloggure on April 13, 2015.

Rescue a VPS upgrade with chroot

2014-09-22T00:00:00+02:00

Oops

A few days ago, I finally decided to upgrade the installed Linux on my dedicated box hosted at OVH. As with every task you tend to postpone until it is too late, it failed miserably, Murphy’s law I am looking at you right now !

During the install process, the machine hanged (I am not sure whether the machine is faulty or not, it seems to shut down under heavy load). Fortunately for me, OVH is kind enough to send a tech resets the machine, and if it does not ping when booted, the tech reboots the machine in rescue mode.

Rescue mode

The rescue mode is a lightweight Linux booted on the machine so you can run fsckand other commands to rescue your filesystem (you can even scp files to backup before a reinstall for example.

My problem was simple, I needed to allow dpkg to finish its job in order for me to get a working machine. Then I think of the good old powerful chroot command and I remembered how powerful Unixes are !

Mounting filesystems

As you should know, chroot is a command allowing to change the root of a file system, litterally jailing it into a directory (popular things of today like pico containers like Docker are improved versions of chroot).

The partition layout of my machine is the following :

sda1 contains the root filesystem
sda2 contains home directories

I issued the following commands to “jail” the rescue mode into my machine :

$ mount /dev/sda1 /mnt
$ mount /dev/sda2 /mnt/home
    
$ mount -o bind /proc /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -o bind /dev/pts /mnt/dev/pts
$ mount -o bind /sys /mnt/sys 
$ chroot /mnt/

From then, I was on my machine, with my files and so on, so I have been able to run dpkg to finish the install :

$ dpkg --configure --a

Finally, dpkg sent me back to a working prompt and I have been able to reboot the machine (do not forget to change boot disk in OVH manager to hd or netboot to prevent rebooting in rescue mode).

Rescue a VPS upgrade with chroot was originally published by at Bloggure on September 22, 2014.

Résoudre les conflits de dépendances

2014-09-01T00:00:00+02:00

Lors de nos développements, nous reposons beaucoup sur des projets externes qui nous fournissent énormément de services utiles. Dans un récent projet, nous avons eu besoin de faire fonctionner Neo4j conjointement à ElasticSearch. Jusqu’ici, aucun soucis n’est à déplorer, mais nous avions une exigence particulière : il fallait que l’application puisse démarrer automatiquement un serveur Neo4J ainsi qu’un serveur ElasticSearch sur les postes de développements (ainsi que pour les tests d’intégration).

Problème existant

Les deux outils que nous utilisons se basent sur Apache Lucene pour toute la partie indexation et accès aux données. Mais, et c’est là que le problème se situe, ils n’utilisent pas les mêmes versions de Lucene.

<!-- Extrait du pom d'ElasticSearch -->
<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-core</artifactId>
    <version>4.9.0</version>
    <scope>compile</scope>
</dependency>

<!-- Extrait du pom de Neo4j -->
<dependency>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-core</artifactId>
    <version>3.6.2</version>
</dependency>

ElasticSearch utilise la version 4.9.0, alors que Neo4J utilise la version 3.6.2. Ainsi, en fonction du bon vouloir du Classloader qui sera utilisé par l’application, il se peut qu’ElasticSearch ou Neo4J refuse de fonctionner. La difficulté pour comprendre et détecter le problème est qu’il se manifeste souvent par un obscur NoClassDefFoundError ou NoSuchMethodError qui n’est pas des plus explicites (d’autant plus lorsque notre IDE nous montre une version qui contient ledit symbole non trouvé).

Solution de contournement

Le conflit est assez simple à contourner une fois qu’on a compris ce qui se passe. En fait, il y a deux classes portant le même nom dans les classes chargées, par exemple org.lucene.MaClass, l’une effaçant l’autre aux yeux du ClassLoader. Une pratique courante est de renommer (ou relocate) le package de base d’une bibliothèque utilisée et de l’inclure dans le fichier de package du projet, le plugin maven-shade est conçu dans cette optique. Le choix fait est de renommer la dépendance Lucene dans Neo4J pour notre part, ainsi, nous avons forké le projet et configuré le plugin shade pour qu’il inclue le contenu de la dépendance d’Apache Lucene et qu’il fasse le renommage de org.apache.lucene en shaded.org.apache.lucene.

 <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>2.2</version>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>shade</goal>
                </goals>
                <configuration>
                    <createDependencyReducedPom>true</createDependencyReducedPom>

                    <artifactSet>
                        <includes>
                            <include>org.apache.lucene:*</include>
                        </includes>
                    </artifactSet>
                    <relocations>
                        <relocation>
                            <pattern>org.apache.lucene</pattern>
                            <shadedPattern>shaded.org.apache.lucene</shadedPattern>
                        </relocation>
                    </relocations>
                </configuration>
            </execution>
        </executions>
  </plugin>

Déploiement et nommage

Pour ne pas polluer les dépôts, le numéro de version modifié a été postfixé par -shaded. Le déploiement a été fait sur un dépôt Maven qui est en fait un simple repository Github. Le commit correspondant à cette modification est consultable ici.

Résoudre les conflits de dépendances was originally published by at Bloggure on September 01, 2014.

Bloggure

iOS 26.2 Sheet: remove Liquid Glass for small detents

The Problem

Initial Attempts

The Solution

Conclusion

Streamlining Finances: Automating Bill Renaming with Apple Shortcuts

The Problem: The “Downloads” Folder Chaos

The Solution: Apple Shortcuts

How the Shortcut Works

The Logic Breakdown

Get the Shortcut

How to Set It Up

Usage Guide

On macOS

On iOS / iPadOS

Advanced Usage

Conclusion

Tuist build test schemes

Xcode and schemes

Build errors

Build tests target automatically

Command line-fu

Scripting to the rescue

Downside

Swift module registration

Tuist ?

Code modularity appears !

First implementation

Auto-registration for the win !

Main app implementation

Swift macro : @VisibleForTesting

Macro types

What does it look like ?

Dark Mode iOS Snapshot

Dark mode support

Dynamically switch

App switcher tricks

Consequences

Git-gone

Git daily usage

Removing remote branches

Removing local branches

Install it

List branches to prune

Prune’em all

macOS tools checklist

Welcome to the mac world

System tools

Keyboard tools

Everyday tools

SwiftUI UIKit Interop

Bridging the two worlds

Using SwiftUI from UIKit

UIViewController in SwiftUI

Non elegant solution

Nice looking way of doing

XCode unit test and inheritance

Base idea

Bad things happen

Workaround

Bloggure revival

It’s been a long time

What will this be about ?

Technical stack

Firebase + XCode

Multiples fichiers plist

Première étape : variabilisation

Deuxième étape : génération du fichier

Bénéfices

Jenkins Workflow Plugin

Prérequis Jenkins

Jenkins avec accès à Docker

Jenkins workflow plugin

Premier job Workflow

Grouper les étapes

Mettre de côté les fichiers pour plus tard

Étape de construction d’une image Docker

Workflow et gestion multibranche

Attendre une confirmation utilisateur

Multiples fichiers `plist`