DEV Community: khalil la

Meet Semantic Components — A Modern Angular UI Library

khalil la — Wed, 25 Feb 2026 19:26:58 +0000

After waiting so long for an Angular UI library that actually met my needs, I decided to stop waiting and build my own. The result is Semantic Components — an open-source Angular UI library built on Tailwind CSS, Angular CDK, and Angular Aria, heavily inspired by shadcn/ui.

GitHub: https://github.com/gridatek/semantic-components
Package: @semantic-components/ui
Website: https://semantic-components.com

Why Semantic Components?

The Angular ecosystem has always had fewer off-the-shelf UI options compared to React. Libraries like shadcn/ui, Radix, and Headless UI have raised the bar for what a component library can be — and Angular deserves the same quality.

Semantic Components is my attempt to bring that standard to Angular, while leaning fully into what makes Angular great.

Core Design Principles

Semantic

Every directive or component is named to describe its role in the interface, not just the feature it belongs to. Take the tooltip as an example. Angular Material gives you a single matTooltip directive:

<!-- Angular Material -->
<button matTooltip="Save changes">Save</button>

In Semantic Components, it's scTooltipTrigger:

<!-- Semantic Components -->
<button scTooltipTrigger="Save changes">Save</button>

scTooltipTrigger — because ScTooltip is already the component that renders the actual tooltip bubble. The directive on the button is not the tooltip — it's what triggers it. These are two different things, and the names reflect that. ScDrawerTrigger, ScSelectValue, ScSelectTrigger, ScSidebarBody — you know exactly what each piece does before reading a single line of docs.

This principle extends to the HTML elements themselves. When possible, components/directives are applied to the right native element rather than a generic <div>.

Declarative

The entire UI is described in the template — no imperative open(), close(), or DialogService.create() calls. Take the dialog as an example:

<div scDialogProvider [(open)]="isOpen">
  <button scDialogTrigger scButton variant="outline">Open Dialog</button>

  <ng-template scDialogPortal>
    <div scDialog>
      <button scDialogClose>
        <svg siXIcon></svg>
        <span class="sr-only">Close</span>
      </button>
      <div scDialogHeader>
        <h2 scDialogTitle>Edit profile</h2>
        <p scDialogDescription>Make changes to your profile here.</p>
      </div>
      <!-- content -->
      <div scDialogFooter>
        <button scButton variant="outline" (click)="isOpen.set(false)">Cancel</button>
        <button scButton type="submit">Save changes</button>
      </div>
    </div>
  </ng-template>
</div>

readonly isOpen = signal(false);

The open state is a signal. The trigger, the portal, the close button — all declared in the template. No service injection, no imperative show/hide, no ViewContainerRef gymnastics. You read the template and immediately understand the full structure of the dialog.

The naming reinforces this. ScDialog is not a service — it's the <div role="dialog"> element itself. In Angular Material, MatDialog is a service you inject and call .open() on. Here, scDialog is the thing rendered in the DOM. Same naming principle: the name describes exactly what the piece is, not what it does behind the scenes.

There is a tradeoff: scDialog requires an extra wrapper element in the DOM scDialogProvider. It acts as the coordination point between the trigger, the portal, and the close button — sharing state through Angular's DI tree. It's a conscious choice in favor of keeping everything in the template, at the cost of one extra <div> that you may need to style or account for in your layout.

Composable

Each component is a set of small, focused pieces that you assemble yourself. There are no magic [content] inputs or hidden <ng-content> slots — you write the structure, and the pieces plug into it.

The Select is a good example of how far this goes:

<div scSelect #select="scSelect" placeholder="Select a label">
  <div scSelectTrigger aria-label="Label dropdown">
    <span scSelectValue>
      @if (displayIcon(); as icon) {
      <svg scSelectItemIcon siTagIcon></svg>
      }
      <span class="truncate">{{ select.displayValue() }}</span>
    </span>
  </div>
  <ng-template scSelectPortal>
    <div scSelectPopup>
      <div scSelectList>
        @for (item of items; track item.value) {
        <div scSelectItem [value]="item.value" [label]="item.label">
          <svg scSelectItemIcon siTagIcon></svg>
          <span>{{ item.label }}</span>
        </div>
        }
      </div>
    </div>
  </ng-template>
</div>

You own the structure — the trigger layout, the item layout, the icons, the display value
You extend freely — want a custom empty state in the list? A header above the items? Just add it
The library handles behavior — keyboard navigation, selection state, ARIA attributes — you handle the markup

This also composes across components. A button can be a drawer trigger, a tooltip trigger, and an icon button all at once:

<button scButton size="icon" scDrawerTrigger scTooltipTrigger="Open menu">
  <svg siMenuIcon></svg>
</button>

One element. Three responsibilities. No wrappers.

The tradeoff is verbosity. Because you own the structure, you write more template code than you would with a batteries-included component that hides everything behind inputs. That's a deliberate choice — explicit over implicit. You always know what's in the DOM because you put it there.

Tailwind + CVA for Variants

The library follows the shadcn/ui design system — same CSS variables, same color tokens (bg-primary, text-muted-foreground, border-input…), same default styles. If you're already familiar with shadcn, the visual language is instantly recognizable.

Styles are written in Tailwind CSS and managed with class-variance-authority. This means:

Predictable, overridable class names
Consistent variants (default, outline, ghost, destructive, link) across all components

export const buttonVariants = cva('inline-flex items-center justify-center rounded-lg border ...', {
  variants: {
    variant: {
      default: 'bg-primary text-primary-foreground',
      outline: 'border-border bg-background hover:bg-muted',
      ghost: 'hover:bg-muted hover:text-foreground',
      destructive: 'bg-destructive/10 text-destructive',
      link: 'text-primary underline-offset-4 hover:underline',
    },
    size: {
      default: 'h-8 px-2.5',
      sm: 'h-7 px-2.5 text-[0.8rem]',
      lg: 'h-9 px-2.5',
      icon: 'size-8',
    },
  },
});

Built on Solid Foundations

The rest of the library's design is guided by a few core principles:

Attribute selectors over element selectors. Instead of custom elements like <sc-button>, the library uses attribute selectors on native HTML. No extra wrapper elements, native accessibility roles preserved, and multiple components/directives can stack on the same element:

<button scButton variant="outline" scDrawerTrigger>Open</button>

Modern Angular, all the way down. Signals (input(), output(), computed()), standalone components, native control flow (@if, @for), inject(), and OnPush everywhere. Overlays and positioning are built on @angular/cdk. Accessible patterns like focus trapping and live regions use @angular/cdk/a11y and @angular/aria. Forms are signal-based. The library is also zoneless-compatible — no zone.js required. No legacy APIs, no NgModules.

@Directive({ selector: 'button[scButton]' })
export class ScButton {
  readonly variant = input<ScButtonVariants['variant']>('default');
  readonly size = input<ScButtonVariants['size']>('default');
  readonly disabled = input<boolean, unknown>(false, { transform: booleanAttribute });
}

Accessible by default. Every component is built to pass WCAG AA minimums — proper ARIA attributes, full keyboard navigation, focus management on dialogs and drawers, and screen reader support. Where possible, this is powered by Angular CDK's accessibility primitives (@angular/cdk/a11y) and @angular/aria.

Tradeoffs

This library makes deliberate choices that prioritize the future of Angular over backwards compatibility. That means it is not for every project — and that's intentional.

Zoneless only. The library is built for zoneless Angular apps.
OnPush only. All components use ChangeDetectionStrategy.OnPush.
Signal-based forms only. Form integrations are designed around signals, not NgModel or reactive forms.
No NgModules. Everything is standalone. There are no module exports, no forRoot(), no compatibility shims for module-based apps.

What's in the Box

`@semantic-components/ui` — Core Library

50+ components:

Category	Components
Actions	Button, Button Group, Link, Toggle, Toggle Group
Layout	Card, Separator, Aspect Ratio, Toolbar, Scroll Area, Typography
Forms	Input, Textarea, Checkbox, Radio Group, Switch, Select, Native Select, Label, Field, Input Group, Slider, Range Slider
Overlays	Dialog, Alert Dialog, Drawer, Sheet, Popover, Hover Card, Tooltip, Toast, Backdrop
Navigation	Breadcrumb, Pagination, Tabs, Menu, Menu Bar, Navigation Menu
Display	Alert, Badge, Avatar, Skeleton, Spinner, Progress, Kbd, Empty, Item
Data	Table, Accordion, Collapsible, Calendar, Date Picker, Time Picker
File	File Upload

Icons: `@semantic-icons/lucide-icons`

Icons are distributed as Angular components from @semantic-icons/lucide-icons. Every icon is a standalone component you apply to an <svg> element:

<svg siStarIcon></svg>
<svg siUserIcon></svg>
<svg siArrowRightIcon></svg>

This approach is fully tree-shakable — only the icons you import end up in your bundle. No icon fonts, no sprite sheets.

Getting Started

npm install @semantic-components/ui

Add the styles to your global stylesheet:

@import '@semantic-components/ui/styles';
@source "../node_modules/@semantic-components/ui";

The @import brings in the CDK overlay styles and the shadcn-compatible CSS variables (colors, radius, spacing tokens). The @source tells Tailwind v4 to scan the library's files so its utility classes are included in your build.

Then import what you need directly in your standalone component:

import { ScButton, ScDialog, ScDialogBody, ScDialogTitle } from '@semantic-components/ui';

@Component({
  imports: [ScButton, ScDialog, ScDialogBody, ScDialogTitle],
  template: `
    <button scButton>Open Dialog</button>
  `,
})
export class MyComponent {}

No module registration. No forRoot(). Just import and use.

JVM-Level vs Spring Boot-Level SSL Configuration

khalil la — Mon, 27 Oct 2025 11:56:15 +0000

1. Introduction

When securing a Spring Boot application, SSL/TLS configuration can occur at two different layers: the JVM level and the Spring Boot level. Although both deal with certificates and encryption, they operate independently and serve different purposes. Understanding this distinction is essential for correctly securing traffic both into and out of your application.

2. JVM-Level SSL (Global to the Process)

JVM-level SSL configuration applies to the entire Java Virtual Machine, affecting all outbound TLS communication initiated by the application.

What it controls

Outbound HTTPS calls
Trust anchors (which CAs the JVM trusts)
Client certificates for outbound mutual TLS

Configuration example

-Djavax.net.ssl.keyStore=/etc/certs/client-keystore.p12
-Djavax.net.ssl.keyStorePassword=changeit
-Djavax.net.ssl.trustStore=/etc/certs/jvm-truststore.jks
-Djavax.net.ssl.trustStorePassword=changeit

3. Spring Boot-Level SSL (Embedded Server)

Spring Boot-level SSL is used by the embedded web server (Tomcat/Jetty/Undertow). This controls the TLS endpoint your application exposes to callers.

What it controls

Inbound HTTPS traffic
Server certificate presented to clients
Optional client authentication for inbound mutual TLS (configured via server.ssl.client-auth)

Configuration example

server:
  ssl:
    enabled: true
    key-store: classpath:server.p12
    key-store-password: changeit
    key-store-type: PKCS12
    trust-store: classpath:client-truststore.jks
    trust-store-password: changeit
    client-auth: need  # Options: none, want, need

Note: The trust-store property is only used when client-auth is set to want or need. It validates client certificates during mutual TLS authentication.

4. Key Differences

Aspect	JVM-Level SSL	Spring Boot-Level SSL
Scope	Entire JVM (default for all connections)	Only Spring Boot web server
Direction	Outbound (and default inbound)	Inbound (overrides JVM)
Use case	Trust upstream services, outbound requests	Serve HTTPS to callers
Config	`-Djavax.net.ssl.*`	`application.yml`

Clarification: JVM-level settings provide defaults for all SSL/TLS connections, but Spring Boot's embedded server overrides these defaults with its own configuration for inbound traffic.

5. When You Need Both

A typical microservice often acts as both a TLS server (for inbound requests) and a TLS client (for outbound dependencies). In this scenario, both SSL layers must be configured.

6. How to Combine JVM-Level and Spring Boot-Level SSL

Combined Use Case

Requirement	Layer	What is configured
Present a server certificate to clients	Spring Boot	`server.ssl.key-store`
Trust incoming clients for mTLS	Spring Boot	`server.ssl.trust-store`
Trust upstream service certificates	JVM	`javax.net.ssl.trustStore`
Present client cert for outbound mTLS	JVM	`javax.net.ssl.keyStore`

Combined configuration example

JVM-level (outbound)

-Djavax.net.ssl.keyStore=/etc/certs/outbound-client-keystore.p12
-Djavax.net.ssl.keyStorePassword=changeit
-Djavax.net.ssl.trustStore=/etc/certs/outbound-truststore.jks
-Djavax.net.ssl.trustStorePassword=changeit

Spring Boot-level (inbound)

server:
  ssl:
    enabled: true
    key-store: classpath:inbound-server-keystore.p12
    key-store-password: changeit
    trust-store: classpath:inbound-truststore.jks
    trust-store-password: changeit
    client-auth: need

When to keep them separate

Different certificate authorities
Different rotation lifecycles
Security boundary separation
mTLS with asymmetric trust domains

When they can be merged

Single CA for both directions
Small trust domain
Simplified deployment model

7. Advanced Considerations

HTTP Client Libraries

Some HTTP client libraries (RestTemplate, WebClient, Apache HttpClient, etc.) may allow or require custom SSL context configuration beyond JVM-level settings. This is useful when you need:

Different trust stores for different downstream services
Per-client SSL configurations
Programmatic certificate validation logic

Example with RestTemplate:

SSLContext sslContext = SSLContextBuilder.create()
    .loadTrustMaterial(trustStore, null)
    .build();

SSLConnectionSocketFactory socketFactory = 
    new SSLConnectionSocketFactory(sslContext);

HttpClient httpClient = HttpClients.custom()
    .setSSLSocketFactory(socketFactory)
    .build();

RestTemplate restTemplate = new RestTemplate(
    new HttpComponentsClientHttpRequestFactory(httpClient)
);

8. Summary

Traffic Direction	Layer	Config
Inbound (clients → you)	Spring Boot	`application.yml`
Outbound (you → others)	JVM	JVM `-D` flags

Both layers serve different purposes but can work together when an application is both a TLS server and a TLS client.

Announcing `tw-prose`: A CSS-Only Typography Plugin for Tailwind CSS v4

khalil la — Wed, 10 Sep 2025 21:28:55 +0000

I'am excited to introduce tw-prose — a CSS-only implementation of the Tailwind Typography plugin built specifically for Tailwind CSS v4.

Typography is at the heart of every content-driven website, and tw-prose makes it simple to get elegant, consistent text styling — without any plugin overhead.

Why `tw-prose`?

⚡ Lightweight – no JavaScript, no plugin complexity
✨ Beautiful defaults – headings, paragraphs, lists, code blocks, tables, blockquotes, and more
🌓 Dark mode ready – just add prose-invert
📏 Responsive variants – prose-sm, prose-lg, prose-xl, prose-2xl
✅ Compatible with Tailwind v4

Install & Go

npm install tw-prose

@import "tailwindcss";
@import "tw-prose";

Then use it in your HTML with the prose class:

<article class="prose">
  <h1>Hello, world!</h1>
  <p>Typography made simple.</p>
</article>

Perfect For

Blogs and content-heavy sites
Projects where bundle size matters
Teams that want zero-config typography out of the box

Get Started

tw-prose is available now on npm:

👉 npmjs.com/package/tw-prose

Try it today and make your text shine with effortless typography in Tailwind CSS v4.

🚀 Ng New Command Generator

khalil la — Sat, 30 Aug 2025 10:02:35 +0000

Starting a new Angular project always begins with ng new, but remembering all the flags (routing, styles, strict mode, standalone, etc.) can be tricky.

That’s why I built the Ng New Command Generator — a small tool for the Angular community that makes project setup super easy.

✅ Enter your project name

✅ Pick your options (routing, style, strict, standalone)

✅ Copy the ready-to-use command

The best part? Your choices are saved in local storage, so next time you visit, your defaults are already there.

👉 Try it now: ng.gridatek.com

Deploy Angular App to Cloudflare Pages using GitHub Actions

khalil la — Wed, 20 Aug 2025 18:16:41 +0000

This guide walks you through creating a new Angular application and deploying it to Cloudflare Pages using automated GitHub Actions.

What You'll Build

⚠️ Important: Choose Your Own App Name

Since this is a template guide, you'll need to pick your own unique project names. Throughout this guide, we use your-app-name as a placeholder - replace it with your chosen name everywhere it appears.

Angular App Name: your-app-name (choose your unique name)
Cloudflare Project: your-app-name (same as above)
GitHub Repository: your-app-name (same as above)
Live URL: https://your-app-name.pages.dev

Prerequisites

Node.js installed locally
GitHub account
Cloudflare account (free)

Step 1: Create New Angular Application

1.1 Install Angular CLI

# Install Angular CLI globally
npm install -g @angular/cli

# Verify installation
ng version

1.2 Create New Angular App

# Create new Angular application (replace 'your-app-name' with your chosen name)
ng new your-app-name

# You'll be prompted with options:
# ? Which stylesheet format would you like to use? CSS [ https://developer.mozilla.org/docs/Web/CSS]
# ? Do you want to enable Server-Side Rendering (SSR) and Static Site Generation (SSG/Prerendering)? No
# ? Do you want to create a 'zoneless' application without zone.js? No
# ? Which AI tools do you want to configure with Angular best practices? https://angular.dev/ai/develop-with-ai None

# Navigate to project directory (use your chosen app name)
cd your-app-name

1.3 Test Your App Locally

# Start development server
ng serve

# Open browser to http://localhost:4200
# You should see the Angular welcome page

Step 2: Setup Cloudflare Account & API Token

2.1 Create Cloudflare Account

Go to cloudflare.com and sign up
Verify your email address

2.2 Create API Token

Navigate to Dashboard → My Profile → API Tokens
Click Create Token → Create Custom Token
Configure the token:

   Token Name: Angular App Deploy
   Permissions:
   - Account - Cloudflare Pages:Edit

   Account Resources: Include - Your Account

Click Continue to Summary → Create Token
Copy and save the token (you won't see it again!)

2.3 Get Account ID

Go to Cloudflare Dashboard
In the right sidebar, copy your Account ID

Step 3: Create Cloudflare Pages Project

To set up a Cloudflare Pages project for your Angular app using Wrangler CLI, follow these steps. Wrangler is the official Cloudflare CLI tool that lets you create, manage, and deploy Pages projects quickly.

# Install Wrangler globally
npm install -g wrangler

# Authenticate with Cloudflare
wrangler login

# Create your Pages project (replace 'your-app-name' with your chosen name)
wrangler pages project create your-app-name

During setup, Wrangler will ask for the production branch name. Enter main when prompted.

Step 4: Initialize Git and Setup Repository

4.1 Initialize Git Repository

The Angular CLI automatically initializes a Git repository when you create a new project.
You can confirm this by running:

git status

If the repository is not initialized, you can set it up manually:

git init
git add .
git commit -m "Initial commit"

4.2 Create GitHub Repository

Go to github.com and create a new repository
Name it: your-app-name (same as your Angular app - use your chosen name)
Don't initialize with README (we already have files)
Copy the repository URL

4.3 Connect Local Repository to GitHub

# Add remote origin (replace YOUR_USERNAME and your-app-name with your values)
git remote add origin https://github.com/YOUR_USERNAME/your-app-name.git

# Push to GitHub
git branch -M main
git push -u origin main

Step 5: Setup GitHub Secrets

Go to your GitHub repository
Navigate to Settings → Secrets and Variables → Actions
Click New repository secret and add:

Name: CLOUDFLARE_API_TOKEN, Value: Your API token
Name: CLOUDFLARE_ACCOUNT_ID, Value: Your Account ID

Step 6: Create GitHub Action Workflow

6.1 Create Deployment Workflow

Create .github/workflows/deploy-cloudflare.yml with the following content:

⚠️ Important: Replace your-app-name with your actual app name in the YAML below

name: Deploy to Cloudflare Pages

on:
  workflow_dispatch:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy Angular App

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build Angular app
        run: npm run build

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: pages deploy dist/your-app-name/browser --project-name=your-app-name

6.2 Commit and Push Workflow

# Add the workflow file
git add .github/workflows/deploy-cloudflare.yml

# Commit the workflow
git commit -m "Add Cloudflare Pages deployment workflow"

# Push to trigger first deployment
git push origin main

Step 7: Deploy Your App

7.1 Monitor Deployment

Go to your GitHub repository → Actions tab
Watch the "Deploy to Cloudflare Pages" workflow run
Check Cloudflare Dashboard → Workers & Pages → your-app-name for deployment status

7.2 Access Your Live App

Once deployed, your app will be available at:

Cloudflare URL: https://your-app-name.pages.dev

Step 8: Example Implementation

You can see a working example of this setup in this public repository (but remember to use your own app name):

Example Repository: https://github.com/gridatek/angular-cloudflare-demo-app

No more PEM files in Spring Boot – Load SSL certs straight from Vault

khalil la — Fri, 08 Aug 2025 17:04:00 +0000

Hey folks,

I made a small library that lets your Spring Boot app load SSL certificates directly from HashiCorp Vault — no need to download or manage .crt/.key files yourself.

🔗 Code: https://github.com/gridadev/spring-vault-ssl-bundle

🧪 Demo: https://github.com/khalilou88/spring-vault-ssl-bundle-demo

It works with Spring Boot's built-in ssl.bundle config (3.2+). Just point it to your Vault path in YAML and you're done.

✅ No file handling

✅ No scripts

✅ Auto-ready for cert rotation

✅ Works for client and server SSL

Try it out and let me know what you think!

PEM vs. JKS: Why Modern Spring Boot Apps Are Ditching KeyStores

khalil la — Mon, 04 Aug 2025 14:20:57 +0000

As the Java ecosystem evolves, Spring Boot developers face a critical choice when it comes to TLS/SSL configuration: PEM or JKS? Historically, Java KeyStore (JKS) has been the default. But with the introduction of SSL bundles in Spring Boot 3.1+, PEM is emerging as the smarter, more interoperable option.

In this article, we’ll break down the differences between PEM and JKS and explain why PEM should be your go-to format for certificates and keys in modern Spring Boot projects.

🔍 What’s the Difference?

Feature	PEM	JKS
Format	Text-based (Base64 encoded)	Binary Java-specific format
Tools	OpenSSL, widely supported across platforms	`keytool` (Java-specific)
Portability	High (used in NGINX, Apache, Kubernetes, etc.)	Low (mainly Java)
Human Readable	✅ Yes	❌ No
Spring Boot Support Before 3.1	❌ No	✅ Supported via `server.ssl.*`
Spring Boot Support After 3.1	✅ Native via `spring.ssl.bundle.pem`	✅ Supported via `server.ssl.*` and `spring.ssl.bundle.pem`
Conversion Required?	❌ No	✅ Yes if integrating with non-Java systems
DevOps/Cloud Friendly	✅ Very	❌ Limited

✅ Why PEM is the Better Choice

Interoperability Across Platforms
PEM is the universal format for TLS in Kubernetes, Docker, NGINX, Istio, cert-manager, and more. It plays well in hybrid environments where your Spring Boot app needs to coexist with services written in Python, Go, or Node.js.
No More Format Conversion
With JKS, you're often forced to convert certificates using keytool or openssl just to get Java to understand them. PEM eliminates that friction—no unnecessary conversions, no extra tooling.
First-Class Spring Boot Support
Starting with Spring Boot 3.1, PEM is natively supported via spring.ssl.bundle.pem, allowing clean separation of private keys, certificates, and trust chains—all without touching keytool.
Better Transparency and Auditing
Since PEM files are human-readable, it’s easier to inspect certificates, audit chains of trust, and debug SSL issues. Compare that to the opaque .jks binary format, where you’re dependent on tooling to explore its contents.

🔄 But What About JKS?

JKS still has a few legacy advantages:

It integrates seamlessly with older Java EE servers.
Some Java tools and libraries still expect .jks or .p12 formats.
Existing enterprise setups may be deeply tied to JKS conventions.

However, in a modern Spring Boot environment, especially for cloud-native and microservice-based apps, these advantages are increasingly irrelevant.

🚀 How to Use PEM in Spring Boot

Example using SSL Bundle (Spring Boot 3.1+):

server:
  ssl:
    bundle: my-pem-bundle
spring:
  ssl:
    bundle:
      pem:
        my-pem-bundle:
          certificate: classpath:certs/cert.pem
          private-key: classpath:certs/key.pem
          trust:
            certificate: classpath:certs/ca.pem

That’s it—no keytool, no conversions, no headaches.

Final Thoughts

In 2025, there's no good reason to stay locked into Java-only formats like JKS. PEM is portable, readable, flexible, and natively supported in Spring Boot. It’s the clear choice for teams building modern, secure, cloud-native Java applications.

Install Hadoop on Fedora

khalil la — Thu, 17 Jul 2025 21:42:50 +0000

Prerequisites

First, ensure you have Java installed since Hadoop requires it:

# Install OpenJDK 8 or 11 (Hadoop works well with both)
sudo dnf install java-11-openjdk java-11-openjdk-devel

# Verify Java installation
java -version
javac -version

Download and Install Hadoop

Download Hadoop:

# Create a directory for Hadoop
sudo mkdir -p /opt/hadoop
cd /tmp

# Download Hadoop (replace with latest stable version)
wget https://archive.apache.org/dist/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz

# Extract and move to /opt
sudo tar -xzf hadoop-3.3.6.tar.gz -C /opt/hadoop --strip-components=1

# Change ownership
sudo chown -R $USER:$USER /opt/hadoop

Set up environment variables:

# Edit your ~/.bashrc file
echo 'export HADOOP_HOME=/opt/hadoop' >> ~/.bashrc
echo 'export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop' >> ~/.bashrc
echo 'export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin' >> ~/.bashrc
echo 'export JAVA_HOME=/usr/lib/jvm/java-11-openjdk' >> ~/.bashrc

# Reload the configuration
source ~/.bashrc

Configure Hadoop:

Edit the Hadoop configuration file:

# Set JAVA_HOME in Hadoop's environment
echo 'export JAVA_HOME=/usr/lib/jvm/java-11-openjdk' >> $HADOOP_HOME/etc/hadoop/hadoop-env.sh

Basic Configuration (Pseudo-distributed mode)

For a single-node setup:

Configure core-site.xml:

cat > $HADOOP_HOME/etc/hadoop/core-site.xml << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
</configuration>
EOF

Configure hdfs-site.xml:

cat > $HADOOP_HOME/etc/hadoop/hdfs-site.xml << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file:///opt/hadoop/data/namenode</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
        <value>file:///opt/hadoop/data/datanode</value>
    </property>
</configuration>
EOF

Create data directories:

mkdir -p /opt/hadoop/data/namenode
mkdir -p /opt/hadoop/data/datanode

Set up SSH (required for Hadoop)

# Install SSH server if not already installed
sudo dnf install openssh-server

# Generate SSH key pair
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa

# Add key to authorized_keys
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys

# Start SSH service
sudo systemctl start sshd
sudo systemctl enable sshd

Initialize and Start Hadoop

Format the namenode:

hdfs namenode -format

Start Hadoop services:

# Start HDFS
start-dfs.sh

# Start YARN (optional, for resource management)
start-yarn.sh

Verify installation:

# Check running processes
jps

# Check HDFS status
hdfs dfsadmin -report

# Access web interfaces:
# NameNode: http://localhost:9870
# ResourceManager: http://localhost:8088

Test Hadoop

# Create a directory in HDFS
hdfs dfs -mkdir /user
hdfs dfs -mkdir /user/$USER

# Put a file into HDFS
echo "Hello Hadoop" > test.txt
hdfs dfs -put test.txt /user/$USER/

# List files in HDFS
hdfs dfs -ls /user/$USER/

# Get file from HDFS
hdfs dfs -get /user/$USER/test.txt downloaded_test.txt

Stop Hadoop

When you're done:

stop-yarn.sh
stop-dfs.sh

This setup gives you a working single-node Hadoop cluster on Fedora. For production or multi-node clusters, you'll need additional configuration for security, networking, and resource management.

Hive Internal vs External Tables

khalil la — Thu, 17 Jul 2025 12:28:17 +0000

Internal Tables (Managed Tables)

Internal tables are managed by Hive, meaning Hive controls both the metadata and the underlying data files.

Characteristics:

Hive manages the complete lifecycle of the table and its data
Data is stored in Hive's warehouse directory (typically /user/hive/warehouse/)
When you DROP the table, both metadata and data are deleted
Hive has full control over the data location and format

External Tables

External tables are not managed by Hive - Hive only manages the metadata while the data remains in its original location.

Characteristics:

Hive only manages table metadata, not the actual data
Data can be stored anywhere in HDFS or other file systems
When you DROP the table, only metadata is deleted, data remains intact
Useful for sharing data with other systems or when data is managed externally

Key Differences Summary

Aspect	Internal Table	External Table
Data Management	Managed by Hive	Managed externally
Data Location	Hive warehouse directory	Any HDFS location
DROP Behavior	Deletes both metadata and data	Deletes only metadata
Data Sharing	Difficult to share with other systems	Easy to share with other systems
Use Case	Hive-only data processing	Data shared across multiple systems
Performance	Slightly better (optimized location)	Depends on location and access patterns

When to Use Each

Use Internal Tables when:

Data is exclusively used by Hive
You want Hive to manage the complete data lifecycle
You need maximum performance optimization
Data doesn't need to be shared with other systems

Use External Tables when:

Data is shared with other systems (Spark, MapReduce, etc.)
You want to preserve data when dropping tables
Data is managed by external ETL processes
You're working with existing data that shouldn't be moved
You need to point to data in different locations or formats

External tables provide more flexibility and are commonly used in enterprise environments where data needs to be accessed by multiple tools and systems.

Streamlined Git Flow: Managing Projects with Master, Feature, and Delivery Branches

khalil la — Mon, 12 May 2025 08:52:36 +0000

A Practical Approach to Git Branching that Maintains Code Integrity While Preserving Release History

1. Introduction

Version control is the backbone of modern software development, and having a clear, consistent Git workflow is essential for team productivity and code quality. This article presents a streamlined Git flow that balances simplicity with robustness, using three primary branch types: master, feature, and delivery.

2. The Branch Structure

Our Git flow revolves around four key branch types, each with a specific purpose:

Master Branch: The main branch where active development occurs, serving as the integration point and the source of truth for your codebase.
Feature Branches: Short-lived branches for developing new functionality.
Delivery Branches: Long-lived branches that capture the state of each release.
Hotfix Branches: Branches created to quickly address and fix critical issues in a released version, ensuring immediate resolution without disrupting ongoing development.

3. The Workflow in Detail

3.1. Starting a New Feature

Every new development task begins by creating a feature branch from the latest master:

git checkout master
git pull
git checkout -b feature/my-new-feature

This ensures your feature is based on the most current codebase.

3.2. Feature Development

As you develop, commit your changes regularly to your feature branch:

git add .
git commit -m "Implement specific functionality"

To avoid painful rebase conflicts later, regularly incorporate changes from master by rebasing:

git checkout feature/my-new-feature
git fetch origin
git rebase origin/master

Rebasing instead of merging keeps the history linear and avoids unnecessary merge commits, which can clutter the history.

3.3. Completing Your Feature

When your feature is ready for review, push it to the remote repository:

git push origin feature/my-new-feature

Then create a pull request to merge your feature into master. This step often involves:

Code review by team members
Running automated tests
Making requested changes

Note: Before submitting the pull request, it's good practice to rebase the feature branch onto the latest master to ensure your changes are based on the most up-to-date version of the code:

git checkout feature/my-new-feature
git fetch origin
git rebase origin/master
git push --force-with-lease

This ensures that the pull request will apply cleanly and reduce potential merge conflicts.

3.4. Managing Releases

When preparing for a release, it's important to handle versioning carefully, ensuring each phase—next version, release candidate, and final version—has its own distinct marker.

3.4.1. Next Version Tagging

The next version refers to the ongoing work for a new release and can be tracked using the -next suffix. This version helps developers track continuous progress during the development cycle, signifying that the code is still evolving but intended for a future release.

3.4.1.1. Version Tagging Format:

Example: v1.0.0-next-0, v1.0.0-next-1, v1.0.0-next-2, etc.

The -next suffix is followed by a sequential number that increments with each iteration or set of changes in the code. This makes it easy to distinguish between different stages of the development process.

3.4.1.2. Creating and Pushing a Next Version Tag:

3.4.1.2.1. Update Master Branch:

Make sure your local master branch is up-to-date:

git checkout master
git pull origin master

3.4.1.2.2. Create the Next Version Tag:

Tag the master branch with the next version:

git tag v1.0.0-next-0
git push origin v1.0.0-next-0

3.4.1.2.3. Incrementing the `next` Version:

Each time a new iteration is made, update the -next suffix to reflect the next step in development, e.g., v1.0.0-next-1.

3.4.2. Release Candidate (RC) Versioning

The release candidate (RC) is a stable, pre-release version that has passed all functional testing but may still need some validation. This version indicates that the code is ready for production but may require final tweaks.

3.4.2.1. Version Tagging Format:

Example: v1.0.0-rc-0, v1.0.0-rc-1, v1.0.0-rc-2, etc.

Similar to the next version, RC versions increment sequentially as new release candidates are tested and prepared for final release.

3.4.2.2. Creating and Pushing an RC Tag:

3.4.2.2.1. Create a Delivery Branch from Master:

First, ensure that your delivery branch is ready by creating it from master:

git checkout master
git pull origin master
git checkout -b delivery/v1.0.0

3.4.2.2.2. Final Testing:

Perform final tests, fix bugs, and prepare documentation or version updates as necessary.

3.4.2.2.3. Tag the RC Version:

Once the release candidate is stable, create an RC tag:

git tag v1.0.0-rc-0
git push origin v1.0.0-rc-0

3.4.2.2.4. Iterate Through RC Versions:

If there are issues in the RC version, increment the rc number with each new fix, e.g., v1.0.0-rc-1, v1.0.0-rc-2, etc.

3.4.3. Final Release Version

The final release version is the last step in the release cycle. It represents the version that is stable and ready for deployment to production.

3.4.3.1. Version Tagging Format:

Example: v1.0.0

Once the release candidate has passed all tests and final adjustments have been made, the version is tagged as the final release version.

3.4.3.2. Steps for Creating the Final Release Tag:

3.4.3.2.1. Finalize Delivery Branch:

Once the RC is ready, finalize the delivery branch by ensuring it's up-to-date and stable:

git checkout delivery/v1.0.0
git pull origin delivery/v1.0.0

3.4.3.2.2. Create the Final Release Tag:

Tag the final version with the v1.0.0 label:

git tag v1.0.0
git push origin v1.0.0

3.4.3.2.3. Do not merge the Delivery branch into Master:

After creating the final release tag on your delivery branch, it's important to avoid merging the delivery branch back into master. There are several critical reasons for this approach:

Maintaining Release Integrity: Delivery branches should remain as historical snapshots of what was released, unaltered by future development.
Preventing Feature Contamination: Master typically evolves with new features and changes during the release stabilization period. These features weren't intended for the current release and shouldn't be mixed with released code.
Avoiding Unexpected Side Effects: Merging delivery branches back to master can introduce unexpected behavior, especially if master has significantly diverged since the delivery branch was created.

Instead, when issues need to be fixed in a released version:

# Use the hotfix workflow described in Section 6
git checkout delivery/v1.0.0
git checkout -b hotfix/critical-issue-fix

# After implementing and testing the fix
# Apply to both the delivery branch and master separately

This approach ensures clean separation between versions while still maintaining the ability to apply critical fixes where needed. It preserves the purpose of your branches: master for active development and delivery branches as immutable records of releases.

3.5. Housekeeping

After a successful release, clean up your completed feature branches:

git branch -d feature/my-new-feature

Importantly, keep your delivery branches as a permanent record of each release.

3.6. Handling Hotfixes

When a critical issue is discovered in a released version, start the fix directly from the relevant delivery branch. This ensures the fix is based on the exact code that was deployed:

git checkout delivery/v1.0.0
git pull
git checkout -b hotfix/critical-issue-fix

After implementing and testing the fix, follow these steps:

3.6.1. Update the Delivery Branch with the Hotfix

Create a pull request to merge the hotfix into the delivery branch:

# After committing your changes to the hotfix branch
git push origin hotfix/critical-issue-fix

Once your team has reviewed and approved the hotfix, merge it into the delivery branch using your Git hosting platform (GitHub, GitLab, etc.).

3.6.2. Tag the Updated Delivery Branch with a Patch Version

After merging the hotfix, create a new patch version tag on the delivery branch:

git checkout delivery/v1.0.0
git pull origin delivery/v1.0.0
git tag v1.0.1
git push origin v1.0.1

This creates a new release version that includes your hotfix.

3.6.3. Apply the Hotfix to Master

To ensure future releases also include this critical fix, create a separate pull request to apply the same fix to master:

# Create a new branch from master for the same fix
git checkout master
git pull origin master
git checkout -b hotfix/critical-issue-fix-master

# Apply the same changes as in the original hotfix
# This may require cherry-picking or manually implementing the same changes

Push this branch and create a pull request to master, ensuring the commit message references the original hotfix and issue number for traceability.

3.6.4. Clean Up Branches

After both pull requests have been merged, clean up the temporary branches:

git branch -d hotfix/critical-issue-fix
git branch -d hotfix/critical-issue-fix-master

This approach ensures your hotfix is applied both to the released version (via the delivery branch) and to ongoing development (via master), while keeping these processes separate to maintain the integrity of each branch. It also preserves the delivery branch as an accurate historical record of what was released.

4. Benefits of This Approach

4.1. Simplicity + Structure: Using just three core branch types (with hotfixes as needed) keeps cognitive load low.

4.2. Release Preservation: Delivery branches act as immutable records of what was released—this is excellent for traceability and auditing.

4.3. Rebase-Driven Clean History: Encouraging rebasing over merging avoids tangled commit graphs and unnecessary noise in the log.

4.4. Isolated Hotfix Workflow: Handling hotfixes off the delivery branch directly is an elegant solution that minimizes risk to in-progress work.

5. Conclusion

This streamlined Git flow provides a balanced approach that works well for many development teams. By incorporating git rebase into your workflow, you ensure a cleaner, more linear commit history, which is easier to maintain and navigate. It also reduces merge commits, which can sometimes clutter the project's history. By following these straightforward patterns, your team can focus less on Git complexities and more on delivering great software.

Have you implemented a similar Git flow in your team? What challenges or improvements have you discovered? Share your experiences in the comments below.

Building a Properties Configuration Library for Angular in Nx Workspaces

khalil la — Sun, 27 Apr 2025 13:00:05 +0000

Introduction

Configuration management is a critical aspect of any enterprise Angular application. Whether you're working with environment-specific settings, feature flags, or API endpoints, having a robust way to load and access configuration at runtime is essential. In this article, we'll build a properties configuration library specifically designed for Angular applications in Nx workspaces.

The Challenge

Traditional Angular configuration approaches using environment files have limitations:

Configuration is bundled at build time, requiring rebuilds for config changes
Different environments require separate builds
Configuration can't be updated without redeploying the application

We need a solution that:

Loads configuration at runtime from a JSON file
Enforces strict property access (fails fast on missing properties)
Works seamlessly in an Nx monorepo environment
Uses modern Angular patterns (standalone components, functional providers)

Our Solution: A Properties Configuration Library

Let's create a library for loading and accessing configuration from a properties.json file at runtime.

Core Features

Runtime loading of configuration from a JSON file
Strict property access with clear error messages
Support for nested properties using dot notation
Application initialization integration
TypeScript type safety

The Implementation

1. The Properties Service

The heart of our solution is the PropertiesService that handles loading and accessing configuration:

// File: libs/properties/src/lib/properties.service.ts

import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { firstValueFrom } from 'rxjs';

export interface Properties {
  [key: string]: any;
}

export class PropertyNotFoundError extends Error {
  constructor(key: string) {
    super(`Property '${key}' not found in configuration`);
    this.name = 'PropertyNotFoundError';
  }
}

@Injectable({
  providedIn: 'root'
})
export class PropertiesService {
  private http = inject(HttpClient);
  private properties: Properties = {};
  private propertiesLoaded = false;
  private defaultPath = 'assets/properties.json';

  async loadProperties(path?: string): Promise<Properties> {
    if (this.propertiesLoaded) {
      return this.properties;
    }

    const filePath = path || this.defaultPath;

    try {
      this.properties = await firstValueFrom(this.http.get<Properties>(filePath));
      this.propertiesLoaded = true;
      return this.properties;
    } catch (error) {
      console.error('Failed to load properties file', error);
      throw new Error(`Failed to load properties file from ${filePath}`);
    }
  }

  getProperty<T>(key: string): T {
    if (!this.propertiesLoaded) {
      throw new Error('Properties not loaded. Initialize the service first');
    }

    const value = this.getNestedProperty(this.properties, key);

    if (value === undefined) {
      throw new PropertyNotFoundError(key);
    }

    return value as T;
  }

  hasProperty(key: string): boolean {
    if (!this.propertiesLoaded) {
      throw new Error('Properties not loaded. Initialize the service first');
    }

    const value = this.getNestedProperty(this.properties, key);
    return value !== undefined;
  }

  isInitialized(): boolean {
    return this.propertiesLoaded;
  }

  getAllProperties(): Properties {
    if (!this.propertiesLoaded) {
      throw new Error('Properties not loaded. Initialize the service first');
    }

    return JSON.parse(JSON.stringify(this.properties));
  }

  private getNestedProperty(obj: any, path: string): any {
    if (!path) return undefined;

    const properties = path.split('.');
    let current = obj;

    for (const prop of properties) {
      if (current === null || current === undefined) {
        return undefined;
      }
      current = current[prop];
    }

    return current;
  }
}

2. Application Initialization Provider

To ensure properties are loaded before the application starts, we'll use Angular's provideAppInitializer (available in Angular 16+):

// File: libs/properties/src/lib/properties.provider.ts

import { EnvironmentProviders, makeEnvironmentProviders, inject } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { provideAppInitializer } from '@angular/core/appinit';
import { PropertiesService } from './properties.service';

export interface PropertiesConfig {
  path?: string;
}

export function provideProperties(config?: PropertiesConfig): EnvironmentProviders {
  return makeEnvironmentProviders([
    provideHttpClient(),
    PropertiesService,
    provideAppInitializer(() => {
      const propertiesService = inject(PropertiesService);
      return propertiesService.loadProperties(config?.path);
    })
  ]);
}

3. Library Exports

We'll keep our public API clean:

// File: libs/properties/src/index.ts

export * from './lib/properties.service';
export * from './lib/properties.provider';

How to Use the Library

1. Create a Properties JSON File

Place a properties.json file in your application's assets folder:

{
  "apiUrl": "https://api.example.com",
  "environment": "production",
  "features": {
    "enableFeatureA": true,
    "enableFeatureB": false
  },
  "logging": {
    "level": "error"
  }
}

2. Configure Your Application

In your application configuration, provide the properties service:

// app.config.ts

import { ApplicationConfig } from '@angular/core';
import { provideProperties } from '@myorg/properties';

export const appConfig: ApplicationConfig = {
  providers: [
    provideProperties({
      path: 'assets/properties.json'
    })
  ]
};

3. Use Properties in Components

Now you can use the properties in your components:

import { Component, inject, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { PropertiesService, PropertyNotFoundError } from '@myorg/properties';

@Component({
  selector: 'app-example',
  standalone: true,
  imports: [CommonModule],
  template: `
    <div>API URL: {{ apiUrl }}</div>
    <div>Log level: {{ logLevel }}</div>
    <div>Feature A enabled: {{ featureAEnabled }}</div>
  `
})
export class ExampleComponent implements OnInit {
  private propertiesService = inject(PropertiesService);

  apiUrl!: string;
  logLevel!: string;
  featureAEnabled!: boolean;

  ngOnInit() {
    try {
      this.apiUrl = this.propertiesService.getProperty<string>('apiUrl');
      this.logLevel = this.propertiesService.getProperty<string>('logging.level');
      this.featureAEnabled = this.propertiesService.getProperty<boolean>('features.enableFeatureA');
    } catch (error) {
      if (error instanceof PropertyNotFoundError) {
        console.error('Missing required property:', error.message);
      } else {
        console.error('Error accessing properties:', error);
      }
    }
  }
}

Key Design Decisions

1. Strict Property Access

Our library is designed to fail fast if a required property is missing. Instead of returning undefined or using default values that might mask configuration issues, we throw a specific PropertyNotFoundError. This helps catch configuration problems early in development or deployment.

2. Support for Nested Properties

Configuration often has a hierarchical structure. Our library supports dot notation for accessing nested properties:

// Access nested properties with dot notation
const logLevel = propertiesService.getProperty<string>('logging.level');
const featureEnabled = propertiesService.getProperty<boolean>('features.enableFeatureA');

3. Application Initialization

We use provideAppInitializer to ensure that properties are loaded before the application starts. This prevents components from accessing configuration before it's available.

4. TypeScript Type Safety

The library leverages TypeScript generics to provide type safety when accessing properties:

// Type-safe property access
const apiUrl = propertiesService.getProperty<string>('apiUrl');
const maxRetries = propertiesService.getProperty<number>('api.maxRetries');
const featureEnabled = propertiesService.getProperty<boolean>('features.newFeature');

Advanced Usage

Checking If a Property Exists

Sometimes you need to check if an optional property exists before using it:

if (propertiesService.hasProperty('features.experimentalFeature')) {
  // Use the experimental feature
  const experimentalConfig = propertiesService.getProperty<object>('features.experimentalFeature');
}

Getting All Properties

You might need to access all properties at once:

const allConfig = propertiesService.getAllProperties();
console.log('Current configuration:', allConfig);

Deployment Considerations

With this library, you can deploy the same build to different environments and simply change the properties.json file. This simplifies your CI/CD pipeline and reduces the number of builds required.

For cloud deployments, you could:

Include environment-specific properties.json files in your Docker images
Mount configuration files from environment-specific ConfigMaps in Kubernetes
Use environment-specific S3 buckets or Azure Blob Storage to host configuration files

Conclusion

Our Properties Configuration Library provides a robust solution for runtime configuration management in Angular applications within Nx workspaces. By loading configuration at runtime, enforcing strict property access, and leveraging modern Angular patterns, we've created a flexible and maintainable approach to configuration management.

This library allows for:

Changing configuration without rebuilding applications
Catching missing configuration early
Accessing nested properties with ease
Type-safe property access
Clean integration with Angular's initialization process

These features make it an excellent choice for enterprise Angular applications in Nx workspaces where configuration management is critical.

Spring Boot with Spotless and Git Pre-commit Hooks

khalil la — Fri, 25 Apr 2025 07:45:13 +0000

This guide walks you through setting up automated code formatting and pre-commit checks in a Spring Boot Maven project, ensuring consistent code style across your team.

Introduction
Prerequisites
Step 1: Set Up a Spring Boot Project
Step 2: Configure Spotless Maven Plugin
Step 3: Install Git Hooks with Maven
Step 4: Adding Git Commit ID Plugin
Step 5: Full POM Example
Step 6: Using the Configuration
Step 7: Customization Options
Troubleshooting

Introduction

Having consistent code style across a project improves readability and maintainability. This guide combines three powerful tools:

Spotless: A code formatter that enforces style rules
Git Pre-commit Hooks: Automatically checks or formats code before commits
Maven: Integrates these tools into your build process

Prerequisites

Java 8 or higher
Maven 3.6.0 or higher
Git installed and initialized in your project
A Spring Boot project (or willingness to create one)

Step 1: Set Up a Spring Boot Project

If you don't already have a Spring Boot project, create one using Spring Initializr or with the following Maven command:

mvn archetype:generate -DgroupId=com.example -DartifactId=demo -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

Make sure to initialize Git in your project directory:

git init

Step 2: Configure Spotless Maven Plugin

Add the Spotless Maven plugin to your pom.xml file in the <build><plugins> section:

<plugin>
    <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <version>2.40.0</version>
    <configuration>
        <java>
            <includes>
                <include>src/main/java/**/*.java</include>
                <include>src/test/java/**/*.java</include>
            </includes>
            <googleJavaFormat>
                <version>1.16.0</version>
                <style>GOOGLE</style>
            </googleJavaFormat>
            <removeUnusedImports />
            <importOrder>
                <order>java,javax,org,com,</order>
            </importOrder>
        </java>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
            <phase>compile</phase>
        </execution>
    </executions>
</plugin>

This configuration:

Uses Google's Java code style
Removes unused imports
Organizes imports in a specific order
Checks formatting during compilation

Step 3: Install Git Hooks with Maven

Add the Git Build Hook Maven plugin to manage Git hooks:

<plugin>
    <groupId>com.rudikershaw.gitbuildhook</groupId>
    <artifactId>git-build-hook-maven-plugin</artifactId>
    <version>3.4.1</version>
    <configuration>
        <preCommit>mvn spotless:apply</preCommit>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>install</goal>
            </goals>
            <phase>initialize</phase>
        </execution>
    </executions>
</plugin>

This plugin:

Installs Git hooks during the initialize phase
Sets up a pre-commit hook that runs mvn spotless:apply before each commit

Step 4: Adding Git Commit ID Plugin

Add the Git Commit ID plugin to include Git information in your build:

<plugin>
    <groupId>io.github.git-commit-id</groupId>
    <artifactId>git-commit-id-maven-plugin</artifactId>
    <version>6.0.0</version>
    <executions>
        <execution>
            <id>get-the-git-infos</id>
            <goals>
                <goal>revision</goal>
            </goals>
            <phase>initialize</phase>
        </execution>
    </executions>
    <configuration>
        <generateGitPropertiesFile>true</generateGitPropertiesFile>
        <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
        <includeOnlyProperties>
            <includeOnlyProperty>^git.branch$</includeOnlyProperty>
            <includeOnlyProperty>^git.commit.id$</includeOnlyProperty>
            <includeOnlyProperty>^git.commit.time$</includeOnlyProperty>
        </includeOnlyProperties>
    </configuration>
</plugin>

This adds Git metadata to your build, which can be useful for tracking versions and build information.

Step 5: Full POM Example

Here's a complete pom.xml example for a Spring Boot project with all these configurations:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.3</version>
        <relativePath/>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>demo</name>
    <description>Demo Spring Boot project with Spotless and Git hooks</description>

    <properties>
        <java.version>17</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>

            <!-- Spotless Plugin -->
            <plugin>
                <groupId>com.diffplug.spotless</groupId>
                <artifactId>spotless-maven-plugin</artifactId>
                <version>2.40.0</version>
                <configuration>
                    <java>
                        <includes>
                            <include>src/main/java/**/*.java</include>
                            <include>src/test/java/**/*.java</include>
                        </includes>
                        <googleJavaFormat>
                            <version>1.16.0</version>
                            <style>GOOGLE</style>
                        </googleJavaFormat>
                        <removeUnusedImports />
                        <importOrder>
                            <order>java,javax,org,com,</order>
                        </importOrder>
                    </java>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>check</goal>
                        </goals>
                        <phase>compile</phase>
                    </execution>
                </executions>
            </plugin>

            <!-- Git Commit ID Plugin -->
            <plugin>
                <groupId>io.github.git-commit-id</groupId>
                <artifactId>git-commit-id-maven-plugin</artifactId>
                <version>6.0.0</version>
                <executions>
                    <execution>
                        <id>get-the-git-infos</id>
                        <goals>
                            <goal>revision</goal>
                        </goals>
                        <phase>initialize</phase>
                    </execution>
                </executions>
                <configuration>
                    <generateGitPropertiesFile>true</generateGitPropertiesFile>
                    <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
                    <includeOnlyProperties>
                        <includeOnlyProperty>^git.branch$</includeOnlyProperty>
                        <includeOnlyProperty>^git.commit.id$</includeOnlyProperty>
                        <includeOnlyProperty>^git.commit.time$</includeOnlyProperty>
                    </includeOnlyProperties>
                </configuration>
            </plugin>

            <!-- Git Hook Plugin -->
            <plugin>
                <groupId>com.rudikershaw.gitbuildhook</groupId>
                <artifactId>git-build-hook-maven-plugin</artifactId>
                <version>3.4.1</version>
                <configuration>
                    <preCommit>mvn spotless:apply</preCommit>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>install</goal>
                        </goals>
                        <phase>initialize</phase>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Step 6: Using the Configuration

After adding these configurations to your pom.xml:

Install the Git hooks:

mvn initialize

Verify the pre-commit hook is installed:

cat .git/hooks/pre-commit

You should see something that includes the command mvn spotless:apply.

Now when you try to commit code:
- The pre-commit hook will automatically run mvn spotless:apply
- This will format your code according to the configured style
- Then the commit will proceed
Manual Spotless commands:
- Check for formatting issues without changing files: mvn spotless:check
- Apply formatting to all files: mvn spotless:apply

Step 7: Customization Options

Alternative Formatting Styles

If you prefer the Eclipse formatter instead of Google's style:

<java>
    <eclipse>
        <file>${project.basedir}/eclipse-formatter.xml</file>
    </eclipse>
</java>

You'll need to provide an Eclipse formatter configuration file.

Formatting Other File Types

Add formatters for additional file types:

<configuration>
    <java>
        <!-- Java configuration as before -->
    </java>
    <xml>
        <includes>
            <include>src/main/**/*.xml</include>
            <include>pom.xml</include>
        </includes>
    </xml>
    <yaml>
        <includes>
            <include>src/main/resources/**/*.yml</include>
            <include>src/main/resources/**/*.yaml</include>
        </includes>
    </yaml>
</configuration>

Custom Import Order

Customize the import order to match your team's preferences:

<importOrder>
    <order>com.yourcompany,com,org,javax,java,\#</order>
</importOrder>

Different Pre-commit Actions

To run both formatting check and tests in pre-commit:

<configuration>
    <preCommit>mvn spotless:apply test</preCommit>
</configuration>

Troubleshooting

Pre-commit Hook Not Running

If the pre-commit hook doesn't run automatically:

Check that the hook file has execution permissions:

   chmod +x .git/hooks/pre-commit

Verify Git hooks are not being ignored:

   git config core.hooksPath

It should return .git/hooks or be empty.

Spotless Fails to Apply Formatting

If Spotless fails with formatting errors:

Run mvn spotless:apply manually to see detailed error messages
Check if your code has syntax errors that prevent formatting
Ensure you're using a compatible Java version for the configured formatter

Git Commit ID Plugin Fails

If the Git Commit ID plugin fails:

Ensure your project is a Git repository (git init)
Make at least one initial commit before running the plugin
Check if Git is properly installed and accessible

For more advanced options and configurations, refer to the official documentation:

DEV Community: khalil la

Meet Semantic Components — A Modern Angular UI Library

Why Semantic Components?

Core Design Principles

Semantic

Declarative

Composable

Tailwind + CVA for Variants

Built on Solid Foundations

Tradeoffs

What's in the Box

@semantic-components/ui — Core Library

Icons: @semantic-icons/lucide-icons

Getting Started

Links

JVM-Level vs Spring Boot-Level SSL Configuration

1. Introduction

2. JVM-Level SSL (Global to the Process)

What it controls

Configuration example

3. Spring Boot-Level SSL (Embedded Server)

What it controls

Configuration example

4. Key Differences

5. When You Need Both

6. How to Combine JVM-Level and Spring Boot-Level SSL

Combined Use Case

Combined configuration example

JVM-level (outbound)

Spring Boot-level (inbound)

When to keep them separate

When they can be merged

7. Advanced Considerations

HTTP Client Libraries

8. Summary

Announcing `tw-prose`: A CSS-Only Typography Plugin for Tailwind CSS v4

Why tw-prose?

Install & Go

Perfect For

Get Started

🚀 Ng New Command Generator

Deploy Angular App to Cloudflare Pages using GitHub Actions

What You'll Build

Prerequisites

Step 1: Create New Angular Application

1.1 Install Angular CLI

1.2 Create New Angular App

1.3 Test Your App Locally

Step 2: Setup Cloudflare Account & API Token

2.1 Create Cloudflare Account

2.2 Create API Token

2.3 Get Account ID

Step 3: Create Cloudflare Pages Project

Step 4: Initialize Git and Setup Repository

4.1 Initialize Git Repository

4.2 Create GitHub Repository

4.3 Connect Local Repository to GitHub

Step 5: Setup GitHub Secrets

Step 6: Create GitHub Action Workflow

6.1 Create Deployment Workflow

6.2 Commit and Push Workflow

Step 7: Deploy Your App

7.1 Monitor Deployment

7.2 Access Your Live App

Step 8: Example Implementation

No more PEM files in Spring Boot – Load SSL certs straight from Vault

PEM vs. JKS: Why Modern Spring Boot Apps Are Ditching KeyStores

🔍 What’s the Difference?

✅ Why PEM is the Better Choice

🔄 But What About JKS?

🚀 How to Use PEM in Spring Boot

Final Thoughts

Install Hadoop on Fedora

Prerequisites

Download and Install Hadoop

Basic Configuration (Pseudo-distributed mode)

Set up SSH (required for Hadoop)

Initialize and Start Hadoop

Test Hadoop

Stop Hadoop

`@semantic-components/ui` — Core Library

Icons: `@semantic-icons/lucide-icons`

Why `tw-prose`?

3.4.1.2.3. Incrementing the `next` Version: