Putting the non-main repo addresses into env variables is OK. But does this mean that users need to quote parameters when compiling?
Ling Miao 陈明雨 <morning...@163.com> 于2020年10月27日周二 上午11:24写道： > Maintaining the jar ourselves may not be sustainable. > I think we can solve the problem case by case. > For example, we are currently encountering the problem of cloudera repo > address changes. > Can we consider turning all non-main repo addresses(such as Oracle, > Cloudera repo) into environment variables? > In this way, if the address changes, we can adapt by setting environment > variables without modifying the code. > > > > > -- > > 此致！Best Regards > 陈明雨 Mingyu Chen > > Email: > chenmin...@apache.org > > > > > > At 2020-10-26 19:38:29, "ling miao" <lingm...@apache.org> wrote: > >Hi, > > > >Currently, some fe dependencies that we rely on are not in the maven repo. > >For example, cup-maven-plugin and java-cup are located at the Cloudera > >3rd-P. > >This will lead to the risk that our code will not be compiled when the > >third-party repo changes. > > > >I have also tried whether it is possible to replace these dependencies > with > >other packages or versions, but unfortunately the only thing we can use at > >the moment is this. > > > >So I propose whether we can maintain these jar packages in our own repo to > >ensure that they can be found every time we compile? > > > >Or do you have any better solutions? > > > >Ling Miao >
