Deploy whole installation via `ant maven-install` by jtulach · Pull Request #9779 · apache/netbeans

jtulach · 2026-11-03T06:04:27Z

Goals

make the Maven repository integration approachable to regular NetBeans developers
provide simple Ant command - e.g. ant maven-install to perform all the necessary work
let the main netbeans git repository contain references to all necessary components to perform (snapshot) release
verify the behavior during CI runs

Related Work

this is a single PR from a sequence of pull requests spread across multiple repositories
- it builds on the Cannonical way to install NBM to Maven Repository #9773 investigation
the release process shall use this new ant maven-install
- done by Using ant maven-install to deploy the Maven artifacts netbeans-jenkins-lib#161
I started all the work to be able to improve the Maven plugin in Attach auto update catalog to each cluster artifact netbeans-mavenutils-nbm-maven-plugin#375

neilcsmith-net

Generally good step. Couple of minor suggestions.

Should also consider whether we need mvnw as the target executable.

Removed reserved label. Release process is special-cased label for specific PRs.

jtulach · 2026-11-04T05:08:06Z

+                    <action>
+                        <label>Maven Install</label>
+                        <target>maven-install</target>
+                    </action>


to promote the "Maven Install" capability more

let's expose the action in the popup menu of nbbuild project

jtulach · 2026-11-10T06:05:19Z

Generally good step. Couple of minor suggestions.

Minor suggestions implemented. Please review again, @neilcsmith-net.

Should also consider whether we need mvnw as the target executable.

I don't think there is a need for making this more "bullet proof" (that's what mvnw executable would do, right?)
- certainly it can wait for another PR/effort
the primary need is to have a standard way to populate the repository
- e.g. properly pass the right arguments to the Maven plugin
- needed for Attach auto update catalog to each cluster artifact netbeans-mavenutils-nbm-maven-plugin#375
- or Cannonical way to install NBM to Maven Repository #9773
since 5e51e25 we are using the same technique as the per-module maven-install target and it guarantees the right Maven installation is used

…lForAll

eppleton

Tried this locally on 278e2b8 with a built tree. The new top-level target looks good, but the changes to nbbuild/templates/projectized.xml break the existing per-module ant maven-install:

${repopluginversion} is undefined. The hardcoded 14.5 was replaced with a property that isn't defined anywhere. The new one is nbm.plugin.version. Running ant maven-install in platform/openide.awt:
```
[exec] [ERROR] Plugin org.apache.netbeans.utilities:nb-repository-plugin:${repopluginversion} or one of its dependencies could not be resolved
[exec] [INFO] BUILD FAILURE
```
base.nbm.target.dir is now always set. It moved into default-properties.xml, which every module imports via default.xml. As a result, the <not><isset property="base.nbm.target.dir"/></not> condition in projectized.xml never applies anymore. A plain ant nbm in platform/openide.awt now writes platform/openide.awt/nbms/platform/org-openide-awt.nbm, a new untracked directory inside the module, instead of build/. It also breaks per-module maven-install: the antcall nbm with build.dir=${maven.tmp.nbms} no longer puts the NBM there, so build/mvn/nbms has no .nbm and build/mvn/install stays empty. Maybe keep the default in nbbuild/build.xml, or define it only when basedir is nbbuild.
The mavenVersion default (dev-SNAPSHOT) was removed, but -DforcedVersion=${mavenVersion} is still used. Without -DmavenVersion=…, Maven gets the literal ${mavenVersion}. Should this be nbm.install.version as in build.xml?
mavenArgs is defined and echoed, but never passed to <exec>. The echo claims arguments that weren't actually used.

Minor points:

The new target in build.xml calls plain mvn, which won't run on Windows without .cmd. projectized.xml uses the bundled ${maven.embedder.dir}/maven/bin/mvn${.cmd}. Using the same here would also cover the Maven 4 / mvnw concern without adding a wrapper.
Removing the apisupport action from nbbuild/nbproject/project.xml seems unrelated.
The closing </target> indentation in projectized.xml is off.

jtulach · 2026-11-12T07:18:05Z

Thanks for a detailed review, @eppleton!

${repopluginversion} is undefined.

Oh, my god! Thanks for catching this.
Let's use the new nbm.plugin.version in 1904bd0
running netbeans$ grep -r repopluginversion * now yields empty result

mavenArgs is defined and echoed, but never passed to

Fixed in dd509a1

mavenVersion

per @neilcsmith-net request the mavenVersion has been replaced
since 4a08e7a we are now using nbm.install.version consistently in both maven-install targets

base.nbm.target.dir is now always set.

Reverted in 4a08e7a - now we should be much closer to the original behavior before this PR was created. Toni, please check again. As far as I can say:

netbeans$ ant build-nbms

produces all NBMs in nbbuild/nbms directory (as it used to) and leaves no traces around. Installing to the local Maven repository then works:

netbeans$ ant maven-install -Dnbm.install.version=99-SNAPSHOT

properly populates the repository with 99-SNAPSHOT versions. Then:

netbeans$ rm -rf ~/.m2/repository/org/netbeans/api/org-openide-awt
netbeans$ ant -f platform/openide.awt/ maven-install -Dnbm.install.version=99-SNAPSHOT

succeeds and install new bits properly. I hope the @eppleton review will now find less mistakes. However it is true, given the set of regressions, we should have some tests. I'll think of creating some.

…to install

The changes were implemented

neilcsmith-net · 2026-11-12T09:39:36Z

The new target in build.xml calls plain mvn, which won't run on Windows without .cmd. projectized.xml uses the bundled ${maven.embedder.dir}/maven/bin/mvn${.cmd}. Using the same here would also cover the Maven 4 / mvnw concern without adding a wrapper.

Actually I should have said Maven 3.10 or 4 concerns. At least one of our Maven plugins has issues with 3.10. If locked to the embedded version, this should probably wait, rebase and test on top of #9642 ? Can that property be overridden without breaking other things when invoking this? Or use a separate property that defaults to value of maven.embedder.dir?

jtulach · 2026-11-12T09:44:53Z


+      - name: Maven Install
+        run: |
+          # install all NBMs


the huge list of issues reported by @eppleton deserves an action

not only we shall fix them (done already)

but we should prevent them to appear again

here is a CI change that attempts to do it

there already is "Build NBMs" check in the CI file...

...hence adding few seconds ant maven-install shall be acceptable

it will give us basic confidence the tasks work

This makes me think we need support for deployUrl, and to use somewhere isolated from the cache if you want to test this in CI.

cc/ @mbien thoughts?

there already is "Build NBMs" check in the CI file...

...hence adding few seconds ant maven-install shall be acceptable

it will give us basic confidence the tasks work

both ant maven-install and ant -f platform/openide.awt maven-install succeeds

and the pom.xml file is generated by the CI run

So, checking CI caching we don't currently cache .m2, which would have made this test a no-go. However, given we might want to enable that in future, it's probably still a good idea to test this against an isolated pristine folder IMO.

... given we might want to enable that in future ...

I don't understand why worry now? When someone needs, one can fix the test

the test is fine right now and moreover it uses "obscure" 99-SNAPSHOT

it would take next 15 years before (an unlikely) clash would really appear...

I don't understand why worry now? When someone needs, one can fix the test .. it would take next 15 years before (an unlikely) clash would really appear...

That's not the issue. My concern is cache sizes, which we hit limits on, and potentially caching unnecessary things. As @mbien says, we discussed and verified Maven repo isn't currently cached. I'd mis-remembered and thought the setup-java default was true.

only took a quick look at the CI file changes. Location is good - right job IMO.

Right job, wrong location, I think. This should probably go after the NBM build but before the Javadoc tests? They change the test environment dependent on the setting of the Javadoc label.

Right job, wrong location, I think. This should probably go after the NBM build but before the Javadoc tests

the ant maven-install suggests to run three other jobs before being invoked

two of them (ant build-javadoc included) are optional

e.g. the ant maven-install should be executed after the "Javadoc tests"

They change the test environment dependent on the setting of the Javadoc label.

setting the Javadoc label then changes the behavior, but ...

... it shall not change the result as having Javadoc is optional for ant maven-install

Which changes both the test and the JDK it's running on, thus behaving differently between pull requests and merges.

Which changes both the test and the JDK it's running on, thus behaving differently between pull requests and merges.

good catch. overlooked that. +1 It should be moved above conditional tests which change the env.

Is the testing of ant maven-install in CI the only remaining concern?

Then let it not stay in the way!

Moved the check in 82f6287

Right now it runs just after ant build-nbms (which is the only necessary per-requisite)

shall this continue to be a blocker, then let's remove the CI test from this PR altogether!

@mbien wrote:

this should be a unit test instead and install exactly one representative module.

I'd like to test this more through-fully and in a more standard way than in a GitHub Actions yaml file

I agree, writing it in .java would be better

either as a JUnit test somewhere (maybe some apisupport* module)?

or directly from GitHub Actions: run: java .github/scripts/CheckMavenInstall.java

but let's leave this for some other PR and move on with core changes

jtulach · 2026-11-12T17:45:21Z

  </target>
+
+  <target name="maven-install" depends="init,-init-sources-zip" description="Finishes installation of artifacts into Maven repository">
+      <echo message="=== Run only after ===${line.separator} ant build-source-zips${line.separator} ant build-nbms${line.separator} ant build-javadoc${line.separator}=== Only then maven-install ===${line.separator}"/>


Suggests to run:

ant build-source-zips ant build-nbms ant build-javadoc

but it doesn't run them to make the ant maven-install fast by itself.

With the most recent state of this PR the ant build-source-zips and ant build-javadoc are optional.

…RL scheme

jtulach · 2026-11-12T18:12:47Z

        <condition property="nbm.distribution" value="${dist.base}/${nbm}"> <!-- compatibility -->
            <isset property="dist.base"/>
        </condition>
-        <property name="dist.base.structured" value="http://deadlock.netbeans.org/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms"/>


referencing http://deadlock.netbeans.org is clearly wrong

the server no longer works the way it used to

it doesn't host the nbms-and-javadoc job anymore

based on this idea from Attach auto update catalog to each cluster artifact netbeans-mavenutils-nbm-maven-plugin#375

If so, can we use the m2 URL protocol in all places that might want to consume this?

I decided to use m2:/ protocol

it might not be perfect

but it is certainly better than the deadlock.netbeans.org URL

btw. with this m2:/ protocol and latest version of Attach auto update catalog to each cluster artifact netbeans-mavenutils-nbm-maven-plugin#375 I managed to install "JavaFX Support" into an IDE without javafx cluster

e.g. the whole idea seems to be valid

eppleton · 2026-11-15T10:47:52Z

        </condition>
-        <property name="dist.base.structured" value="http://deadlock.netbeans.org/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms"/>
-        <property name="nbm.distribution" value="${dist.base.structured}/${cluster.dir}/${nbm}"/>
+        <property name="nbm.distribution" value="m2:/org.netbeans.modules:${code.name.base.dashes}:${nbm.install.version}:nbm"/>


The groupId is hardcoded to org.netbeans.modules, but nb-repository-plugin:populate puts modules with public packages under org.netbeans.api. E.g. after ant -f platform/openide.awt maven-install my local repo has only org/netbeans/api/org-openide-awt/dev-SNAPSHOT/, and there is no org/netbeans/modules/org-openide-awt. So m2:/org.netbeans.modules:org-openide-awt:dev-SNAPSHOT:nbm won't resolve for API modules. The JavaFX modules probably worked because they have no public packages.

Not a regression, since the deadlock URL didn't work either, but maybe the groupId should follow the same rule the plugin uses.

Deploy whole installation via ant maven-install

f98a0c5

jtulach requested a review from ebarboni November 3, 2026 06:04

jtulach self-assigned this Nov 3, 2026

jtulach added Platform [ci] enable platform tests (platform/*) Ant [ci] enable "build tools" tests Release process PRs (eg. versions, sync) that are part of the release process and can be ignored in release notes. labels Nov 3, 2026

Provide additional arguments via mavenArgs property

768a4a8

jtulach mentioned this pull request Nov 3, 2026

Using ant maven-install to deploy the Maven artifacts apache/netbeans-jenkins-lib#161

Open

Fail the build Ant build on Maven error

809f263

neilcsmith-net removed the Release process PRs (eg. versions, sync) that are part of the release process and can be ignored in release notes. label Nov 3, 2026

neilcsmith-net previously requested changes Nov 3, 2026

View reviewed changes

Comment thread nbbuild/build.xml Resolved

Comment thread nbbuild/default-properties.xml Resolved

Expose Maven Install in the UI

53efb65

jtulach commented Nov 4, 2026

View reviewed changes

Prefixing the properties with nbm.

adf8ca0

jtulach requested a review from neilcsmith-net November 4, 2026 05:21

jtulach mentioned this pull request Nov 4, 2026

Attach auto update catalog to each cluster artifact apache/netbeans-mavenutils-nbm-maven-plugin#375

Draft

jtulach added 2 commits November 11, 2026 06:20

Merge remote-tracking branch 'origin/master' into jtulach/MavenInstal…

f333ac8

…lForAll

More explicit warning

278e2b8

eppleton reviewed Nov 11, 2026

View reviewed changes

Using nbm.plugin.version consistently

1904bd0

jtulach added 4 commits November 12, 2026 08:38

pass mavenArgs to the executed Maven plugin

dd509a1

Consistently using nbm.install.version to specify version of the NBM …

4a08e7a

…to install

Avoid defining base.nbm.target.dir

64dbfc7

Invoke Maven embedder mvn command

5e51e25

jtulach requested a review from eppleton November 12, 2026 09:26

Verify ant maven-install works on all systems

8676752

jtulach commented Nov 12, 2026

View reviewed changes

jtulach requested a review from mbien November 12, 2026 09:45

jtulach added 3 commits November 12, 2026 11:15

Typo in platform/openide.awt

2e4b6b5

Only install Javadoc and source ZIPs when available

620208e

if:true compares against the evaluated value

b0dc170

jtulach commented Nov 12, 2026

View reviewed changes

Replacing no longer available deadlock server with a ever valid m2: U…

b8ed5b4

…RL scheme

jtulach commented Nov 12, 2026

View reviewed changes

Verify ant maven-install just after building the NBMs

82f6287

eppleton reviewed Nov 15, 2026

View reviewed changes

Conversation

jtulach commented Nov 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Goals

Related Work

Uh oh!

neilcsmith-net left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jtulach commented Nov 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eppleton left a comment

Choose a reason for hiding this comment

Uh oh!

jtulach commented Nov 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

neilcsmith-net commented Nov 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jtulach commented Nov 3, 2026 •

edited

Loading

jtulach commented Nov 10, 2026 •

edited

Loading

jtulach commented Nov 12, 2026 •

edited

Loading