Skip to content

Fix Adobe XMP imports in 'Samples' - #714

Merged
drewnoakes merged 2 commits into
drewnoakes:mainfrom
imagingbook:fix-xmp-imports
Feb 17, 2026
Merged

Fix Adobe XMP imports in 'Samples'#714
drewnoakes merged 2 commits into
drewnoakes:mainfrom
imagingbook:fix-xmp-imports

Conversation

@imagingbook

Copy link
Copy Markdown
Contributor

Fixes issue #713:

  • Updated Adobe XMP imports in XmpSample.java.
  • Modified POM to add Samples as an additional test source directory using build-helper-maven-plugin. This causes code in Samples to be compiled during Maven's test-compile phase (as a validity check) but does not include it in the distribution.

Other suggestions:

  • The current artifact version (2.19.0) is the same as the last release version - perhaps change to something like 2.20.0-SNAPSHOT?
  • In the long run it may help to restructure the project to Maven's standard layout.

@drewnoakes

Copy link
Copy Markdown
Owner

Thanks very much for this.

The current artifact version (2.19.0) is the same as the last release version - perhaps change to something like 2.20.0-SNAPSHOT?

Historically I've just bumped it when pushing an actual package update. I can see that for folks creating their own releases that this could be problematic, but I haven't tackled the maintenance burden of this. Do you know of any way to do this simply and automatically?

In the long run it may help to restructure the project to Maven's standard layout.

I'm not very familiar with Maven (as you can probably tell) so I'd be interested to hear more about why this would help.

@drewnoakes
drewnoakes merged commit 7074598 into drewnoakes:main Feb 17, 2026
4 checks passed
@imagingbook

Copy link
Copy Markdown
Contributor Author

Historically I've just bumped it when pushing an actual package update. I can see that for folks creating their own releases that this could be problematic, but I haven't tackled the maintenance burden of this. Do you know of any way to do this simply and automatically?

No great Maven expert here either ;-)
Keeping the release version is indeed a problem since running mvn install during development will overwrite the artefact's release files in the local (.m2) repository. It is actually quite simple to fix by running Maven's versions plugin from the command line, e.g.,

> mvn versions:set -DgenerateBackupPoms=false -DnewVersion=2.20.0-SNAPSHOT

Then, just before deploying a new release, run

> mvn versions:set -DgenerateBackupPoms=false -DnewVersion=2.20.0

No need to manually edit POM files, though for a simple project like this (with no child modules) one could do just as well. Maven by default treats -SNAPSHOT versions special at deployment.

@imagingbook

Copy link
Copy Markdown
Contributor Author

Restructuring the project...

I'm not very familiar with Maven (as you can probably tell) so I'd be interested to hear more about why this would help.

Maven's canonical directory layout for Java projects is this:

my-app/
├── pom.xml
└── src/
    ├── main/
    │   ├── java/
    │   └── resources/
    └── test/
        ├── java/
        └── resources/

It is what plugins and IDEs assume by default and requires a minimal POM setup. Another advantage is that resources used only for testing are clearly separated and are excluded from the deployed artifact. However, the current layout of your project is probably just as good as long as the project stays as simple as it is.

Actual reason for my comment was that the cleanest way to distribute the files in Samples/ would be as a separate Maven artefact (module), such that they get built and tested as part of the standard workflow. This would be much easier with the standard layout.

If you are interested I can try a quick refactoring attempt, perhaps also add module-info and package-info files on the way ...

@drewnoakes

Copy link
Copy Markdown
Owner

Actual reason for my comment was that the cleanest way to distribute the files in Samples/ would be as a separate Maven artefact (module), such that they get built and tested as part of the standard workflow.

Ah, I see. That makes sense. I'm reluctant to change much about the layout here as I generally don't use Maven. If there were regular contributors here who wanted to use Maven then I wouldn't have an issue, but as it's likely a few years down the line that I need to update something and Maven has changed, then I will find it simpler to keep it simple and familiar. I don't think that building samples is enough of a reason to warrant the change here. We can easily add a shell script that builds the samples too. Possibly just shell scripting some of the release process (i.e. handling -SNAPSHOT) would be enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants