Practices and patterns for maven, using and distributing jars that have click-through license requirements?

First, a not-so-brief backgrounder (...my apologies in advance for the LONG question... skip to paragraph #6 to get to the actual question :-) ...Long-time maven users know the pains of the old (missing) "sun jars" issue. Worked-arounds included locally installing (.m2/repo) or running a repo like nexus, artifactory, et al.... all just to work-around this issue of not having all our artifacts available in public repositories due to the need to click "agree" to a license.

The sun jars issue is largely a thing of the past, but the problem might get worse in the not-so-distant future, as corporations begin to both embrace the use of open-source, while at the same allow free downloads of their software (try-before-you-buy; free to use, but with restrictions). All their jars will require you to "agree" to the license before downloading. If you're maintaining your own internal repo, you have to write pom's that declare the dependencies of these commercial jars... because the vendor didn't. It might not even be obvious that the commercial jars are using open-source jars (nor which version they are using) when the vendor re-jars all the classes into one big uber-jar (bad), which you then have to manually repackage to avoid having duplicate implementations of spring, log4j, apache camel, jdbc drivers, (etc) in your application.

I'm hoping that this old anti-pattern will soon come to an end: manually downloading jars, manually re-packaging & uploading to a local repo; or -- worse -- manually inst开发者_Python百科alling in {user}/.m2/repository (each developer's environment is potentially different; I have to set up / debug each QA person's build environment...).

It's also a problem for my end-users who use the (commercial) software I write, as distributed by my owner (er, my company): my corp won't publish pom's or jars to a public maven repository due to the absence of any click-through license agreement. (Any company could & should publish pom's w/ the dependencies declared (but still require the jars to be manually downloaded from the corp website), but this would take a lot of teaching/explaining to middle management. Not many understand pom's or dependency management (or software development))...

Long story short, it's not a software problem; it's not a maven problem. It is/was a lawyer-made problem, as of yet with no programmer-made solution (that I'm aware of). And I'm curious to know what the status quo is after all these years...

...So, my question, then, is this:

Does anyone know of usage patterns or even solutions to the issue of building maven (or ivy) projects with "free" jars that require you to click "I agree" to a license? This is something that would have to be implemented in the maven client as well as the maven repo. (Maybe this exists today?)

Building should be as simple as running "mvn install" once, agree to a license, and then all builds work locally just fine until you delete your local ~/.m2/repository or upgrade your dependency version. And therefore this would also work on your CI server: after one, initial build, where you hypothetically could click-through via the hudson/jenkins user-interface.

(...If there's a one-line / one-link answer to this overly verbose question (e.g., "just install the maven-world-peace-plugin"), well, my sincerest apologies for the long-winded "question"...!)