Running "clean package" only builds the jars/archives inside the respective target dirs in the build tree. The component classes/poms of the current maven reactor build are visible within that running build for tests etc, but are not visible outwith it to any others builds, as the seperate/former builds target dirs isnt somewhere it would look for required dependencies (first looking in its own reactor build for stuff it is currently itself building, then the local repo for stuff previously remotely-retrieved or locally-installed by another build, and finally remote repositories currently known to the build from the poms or settings file). You typically need to run the "install" goal to put built things in the maven local repo "~/.m2/repository" for a totally distinct local build to see any stuff another has locally built.
I guess one exception to that might be if you strategically overlap the two distinct builds in a nested way such that the [source] parent pom was actually in the direct parent dir of the extracted examples pom looking for it as its parent, since "../pom.xml" is the default parent relative path and so the needed pom could be found that way if it happened to be sitting there (it logs a warning if something else is there). Either way it then still wouldnt find the clients jars or classes it needed to build/run the example unless they are also being built in its current reactor build, and as they are not and wont be found in the local or remote repos it knows of, it then simply doesnt know about them and will fail accordingly. I'm not away of any change in this area, all the builds are the same in this regard, and its more about maven than them. An analogous case might be e.g building proton-c and qpidd or dispatch. Supposing their source trees were being built in two distinct runs/places, the server build simply will not find the built proton, unless its build output was previously installed where they look, or other steps taken to make protons not-installed build output usable by the later build. The more expected route for trying things out is: 1. Add the staging repo details to the examples pom.xml or mavens settings.xml so the staged client can be found. 2. Run the examples build from the -bin package per the readme, which will find the staged client in the staging repo and use it. Completely independent of that you run the "clean package" goals on the separate extracted source tree, either before or after running the example as above, to build the client and run the tests without any interference between the two builds. If you run the whole source build it will just work even without the staging repo as it is currently building everything relating to the client, or you could also run the example alone from the source (changing to their subdir before running, same as with the -bin) without building the actual client, but you would need to have first added the staging repo or have done something else to make the needed client bits end up in the local repo (e.g using the "install" goal on the whole build first). Robbie On Thu, 26 May 2022 at 18:09, Gordon Sim <g...@redhat.com> wrote: > > I built from source using `mvn clean package`, then I untar the > tarball in the target directory. That contains th examples with the > pom file, but maven complained about not finding a parent. This may be > the wrong approach but is essentially how I tested the previous > version and also the original protonj client. It ran fine when I just > included the jar file built in the source tree. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org