I believe moving off the thirdparty repository is something that we still want to do,
even though my first try was a failure.
It wasnt properly validated/tested before it was committed.
At least I think it helped to flush out some issues that might have otherwise taken more time to figure out. So the plan going forward is to fix the out of sync dependencies, and add exclusions to the dependencies where we don't want certain transitive deps included.
Then of course do additional testing to make sure that the testsuite runs. I'll plan to post daily updates here, and then send a notification to the dev-list when I'm ready for the 2nd try at this.
Don't get my critisms on the dev-list wrong. The old thirdparty mechanism
has similar issues to Maven. In fact, in some instances it is worse
(e.g. not detecting changes to snapshots or stale artifacts in thirdparty)
It's just that we are used it (so we know how to make it work)
and its configuration has the advantage of having the correct dependencies. ;-)
I created a new feature on the maven-bm-thirdparty-plugin that reads a component-info.xml and deploys all the artifacts to maven repo. This will help me copy things into the maven repo a little faster, and should take away some of the guesswork (choosing groupIds, artifactId, etc) for other people that want to deploy stuff into the maven repo.
Now I'm using/testing it while fixing the remaining out of sync dependencies. I'll post some documenation on how to use this once I'm done.
I copied most of the remaining dependencies to the maven repository yesterday. So today I will updated the new shared parent pom with dependencies that match build-thirdparty.
One thing that will be different is upgrading javacc from 3.2 to 4.0. This is due to what the javacc-maven-plugin uses. I don't believe this is a problem, because I think javacc is only used at build time and not at run time, and the javacc sources do build correctly. If this could be a problem, please let me know.