Maven and Ivy both do something similar but in the end you still end up with jars added to the lib folder of your application.
Also you would loose control over the versions of your jars your application will use runtime. If an update to your distribution changes these jars your application could fail from changing API signature. Deploying on computers other than your own could also pose problems to locate these jars. Lastly if your application uses many jars you could have problem creating a classpath reaching the limits of what can be stored in an environment variable.
I do not know if there are such systems available for jars as building a lib folder is the approach most used, simple, safe with the light disadvantage to duplicate jars for each applications. This said disk space is cheap and jars rarely peak higher than 1 meg so it is minor.
This being said you could create an extention to Ivy for example that would make your system a repository, then the build process would copy the jars from the different locations in your system to the lib folder of your project thereby bypassing the classpath limits. The plugin could learn the location of the jars by using the package manager's database if available, you could discover versions as well fro the same source. This way you would support customized locations so long as the manager was used to install the jars.
That would be my first avenue of investigation to solve this if I had time and energy.
This being said I still wonder if the investment would yield sufficient return rather than just copy the jars. You are better judge than me to evaluate this for your own needs.