vermilingua

• Folders can be declared in build.properties dir.components, dir.woresources and dir.webserverResources in build.properties now specify the locations of sources packaged. These keys are also read by applications in development through wonder-slim's ERProjectLayout so development and the packaged application agree on where resources are located. Configuring resource locations in pom.xml still works like before and if present, overrides values specified in build.properties, emitting a warning if the values conflict.

Also: dependency update (slf4j).

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.10...v1.1.11

• Fixed: frameworks without resources failed to build A framework consisting of java code only (no woresources, components or webserver-resources) failed to package with NoSuchFileException: /Resources. The framework's Info.plist is written to Resources/ inside the jar, and that folder only existed as a side effect of copying resources into it — so a framework with nothing to copy never got one.

• Fixed: frameworks failed to build without clean Building a framework a second time without clean failed with FileAlreadyExistsException on the first resource written to the jar. maven-jar-plugin leaves an up-to-date jar in place, and resources already present in it from the previous build could not be overwritten. Frameworks now build fine over an existing jar, and changed resources are updated in it.

Both were mistakes in how folders inside the jar were created. Builds with clean of frameworks that have resources were never affected, and produce byte-identical jars to 1.1.9. Application builds are unaffected.

Also: failures writing into the framework jar now say what was being written and where, and the test suite now packages frameworks (previously only application packaging was tested).

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.9...v1.1.10

• Fixed: classic Project Wonder applications failed at startup with vermilingua-built frameworks CFBundleExecutable is again written to the generated Info.plist. The Info.plist minimization in 1.1.6 removed it, but classic Project Wonder's ERXApplication.Loader scans classpath jars and reads exactly this key as the bundle's name in its "all frameworks loaded" bookkeeping. With the key missing, every vermilingua-built framework on the classpath was registered as null — an entry that never gets checked off — and the application died at startup with ERXExtensions have not been initialized ... Remaining frameworks: [null]. This affected frameworks built with vermilingua 1.1.6 through 1.1.8 and running in classic Project Wonder applications; if you hit it, rebuilding the frameworks with 1.1.9 resolves it. (wonder-slim is unaffected — it has no classpath-scanning loader.) The fix has been verified against a production Wonder application: frameworks rebuilt with 1.1.6+ reproduce the failure, the same frameworks rebuilt with 1.1.9 start cleanly. Project Wonder's source has now been scanned for further Info.plist key reads: CFBundleExecutable and Has_WOComponents (restored in 1.1.7) are the only keys classic Wonder reads of those removed in 1.1.6, so this should close the chapter on the minimization's fallout.

Also: maven-plugin-plugin / maven-plugin-annotations updated to 3.16.0.

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.8...v1.1.9

• New (experimental) goal: vermilingua:run Runs the packaged application by executing the launch script inside the built .woa — the artifact runs exactly as it would when deployed (launch script, config.txt, classpath.txt, resources resolved from the bundle rather than from source folders). The goal forks the build lifecycle through package first, so running an application is a single command: mvn vermilingua:run The application's output streams to the Maven console and Ctrl-C stops both. Arguments are passed with run.args and reach the application — or the launch script's own -launch.* handling: mvn vermilingua:run -Drun.args="-WOPort 1200" Like vermilingua:deploy, this goal should be considered experimental for now.

• Improvements to the (still experimental) vermilingua:deploy goal deploy.monitorHost now also accepts a full http(s):// base URL, for deploying through a front end proxying JavaMonitor (e.g. https://javamonitor.example.com) — so JavaMonitor's own port never needs opening to the build machine. And in a reactor build, the goal now quietly skips modules that aren't woapplications instead of failing.

Also: dependency and build-plugin updates (slf4j, surefire/failsafe).

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.7...v1.1.8

• New (experimental) goal: vermilingua:deploy Deploys the packaged application through JavaMonitor: creates a tar.gz of the built .woa and POSTs it to JavaMonitor's deploy endpoint, which hands it to wotaskd on every host the application runs on. Configured via deploy.appName, deploy.monitorHost and deploy.password — in build.properties or as -D overrides, with the same layering as the launch.* parameters. Usage: mvn package vermilingua:deploy -Ddeploy.password=... The goal is functional and has seen real use, but should be considered experimental for now — details may change in coming releases.

• Launch script is now executable for everyone The execute bit on the generated launch script is now set for owner, group and others (chmod a+x), not just the owner. A deployed bundle is often owned by whoever copied it to the server (typically root) while the app runs as an unprivileged user — with an owner-only execute bit, that combination fails with EACCES at launch (status=203/EXEC under systemd).

Also: Has_WOComponents is again included in the generated framework Info.plist, marking the framework for inclusion in the component definition search, preventing potential problems when running a vermilingua-built .woa on Windows.

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.6...v1.1.7

• Minimal Info.plist generation The generated Info.plist now contains only the keys actually read by WebObjects: NSExecutable, CFBundlePackageType, NSPrincipalClass (for frameworks that declare one) and the version keys CFBundleShortVersionString/CFBundleVersion. The removed keys (NSJavaPath, NSJavaRoot, NSJavaClientRoot, NSJavaPathClient, NSJavaNeeded, Java/JVMVersion, Has_WOComponents, CFBundleIconFile, CFBundleIdentifier, CFBundleName, CFBundleSignature, CFBundleDevelopmentRegion, CFBundleGetInfoString, CFBundleInfoDictionaryVersion) are relics from the NeXT/early-macOS era — to our knowledge, no code in WebObjects 5.4.x or Wonder reads them.

Also: dependency updates (junit, central-publishing-maven-plugin).

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.5...v1.1.6

• Resources are now overwritten when building over a previous build When building without clean, files in an already-existing .woa are now overwritten instead of being skipped. Previously the existing destination files were left in place (and logged with a warning per file), which could leave stale resources in the bundle on a non-clean rebuild — and produced a wall of warnings for projects with many resources. The build now reflects the current source on every run.

Also: dependency and build-plugin updates (maven-core, slf4j, junit, surefire/failsafe).

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.4...v1.1.5

• Configurable paths for WebObjects resource folders (https://github.com/undur/vermilingua-maven-plugin/issues/44) The three WebObjects resource folders (woresources, components, webserver-resources) can now be configured individually via the woresourcesPath, componentsPath, and webserverResourcesPath plugin parameters. Defaults are unchanged. This makes it possible to build projects using WebObjects' "Fluffy Bunny" layout — see the README for details. The woresourcesFolderName parameter has been removed.

• Empty directories from source folders are no longer reproduced in the built bundle (https://github.com/undur/vermilingua-maven-plugin/issues/45) Directory structure is recreated on demand when files are copied, so only directories that actually contain content end up in the output.

Also: substantial internal refactoring of the build process to reduce coupling between the packaging logic and Maven's internals, paving the way for potentially driving the build from other systems in the future. No user-facing effect.

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.3...v1.1.4

Maintenance release for fixing a bug in 1.1.2 where .lproj folders inside .lproj folders could result in an error

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.2...v1.1.3

• Component flattening now respects .lproj localization folders (https://github.com/undur/vermilingua-maven-plugin/issues/37) Directories ending with .lproj under src/main/components/ are now preserved, their contents get flattened into them rather than the root /Resources folder.

• Component flattening in framework builds (https://github.com/undur/vermilingua-maven-plugin/issues/33) Framework builds (JAR packaging) now flatten components the same way application builds do.

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.1...v1.1.2

Removes specific jdb debugger support from the build, configuration and launch script.

This means jdb and jdbOptions configuration keys are no longer present/supported in config.txt, build.properties, and -launch.* runtime arguments, and we no longer switch to launching the app using jdb when -NSPBDebug or -NSJavaDebugging YES are set.

jdb is rarely used these days, modern Java deployment debugging usually happening through other methods like JDWP remote debugging (-agentlib:jdwp=...) with an IDE. If you still need to use jdb you can pass in the launch argument -launch.jvm=/path/to/your/jdb

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.1.0...v1.1.1

Some major improvements including changes to the generated .woa bundle structure, buildtime/runtime modification of bundle configuration (jvm, jvmOpts etc). Details in CHANGES.md.

New bundle structure (.woa)

• Removed all platform-specific directories, files and scripts (Contents/MacOS/, Contents/UNIX/, Contents/Windows/, MacOSClassPath.txt, UNIXClassPath.txt, MacOSXServerClassPath.txt, CLSSPATH.TXT, SUBPATHS.TXT)
• Removed Windows .cmd launch script
• Replaced the platform-specific classpath files with two simple files at the WOA root: config.txt and classpath.txt

Configurable Launch script

• jvm, jvmOptions, jdb, and jdbOptions are configurable in build.properties as they are in wolifecycle.
• In addition to build.properties these can now also be set as properties at different times, prefixed with launch.
  • At build time: mvn package -Dlaunch.jvm=/my/java, changes the value written to config.txt
  • At app launch time (CLI or JavaMonitor arguments): ./MyApp.woa/MyApp -launch.jvm=/my/java
  • Finally, you can use "environment specific" build.properties files to override properties. For example, if you have a build.properties.prod file, you can invoke maven with mvn package -Dbuild.env=prod and any values present in build.properties.prod will then override any values from build.properties.
  • So, who wins? Properties end up being looked up in this order — first with a value wins:
    • runtime args
    • buildtime args
    • build.properties.{environment}
    • build.properties
    • defaults

Maven integration

• New <createArchives> option creates tar.gz archives from the build products and attaches them as Maven artifacts for use with mvn install and mvn deploy (closes #7)

Housekeeping

• Renamed ng package to vermilingua (closes #35)
• Removed pinned plugin versions from lifecycle mappings — Maven resolves versions from its own defaults
• Various code cleanups and internal refactoring

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.0.6...v1.1.0

New launch script for applications. Some minor internal maintenance/cleanup

• Simplified and modernized launch script for apps. Changes are detailed in CHANGES.md
• Cleanup in internal utility logic
• Update dependencies

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.0.5...v1.0.6

Mostly a maintenance release to prepare for Maven v4.

• Small fix to launch script when application is run without NEXT_ROOT set
• Update dependencies/plugins to most recent Maven 3 versions
• Require Maven >= 3.9.0
• Require JDK >= 21

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.0.4...v1.0.5

What's Changed

• Launch script: Apps can now be run without NEXT_ROOT being set. If not set, it will get set to /tmp/nextroot by default.
• Launch script: --add-opens java.base/java.util=ALL-UNNAMED now added to the default java launch arguments
• Updated versions of maven plugins we use/depend on. Mostly done to get the most recent version of the maven compiler plugin, allowing Eclipse to properly recognize a JDK version set using the property maven.compiler.release.

Full Changelog: https://github.com/undur/vermilingua-maven-plugin/compare/v1.0.3...v1.0.4

Properly overwrite existing resources on app build

Fix framework builds to work on Windows

Published to Maven central