We have seen the same, so lovely coined as "jar-hell", in many forums. We almost choose to add the REST-server and talk with that to avoid the dependencies. We never got to that, so I don't know if there is a thin model available for REST? If not, that could be a solution for some. Moving the model into one module, wouldn't that still make you dependent of real implementation and all the dependencies there is now - assuming you would want to go with an API which connects directly to LDAP?
2016-02-15 19:44 GMT+01:00 Chris Pike <[email protected]>: > Yes, it would require moving the model source files into it's own > directory, the rest into another directory, and configuring / adding extra > pom files. We are going to add exclusions for now, but may want to revisit > the maven project layout at some point. > > > > > ----- Original Message ----- > From: "Shawn McKinney" <[email protected]> > To: [email protected] > Sent: Monday, February 15, 2016 10:56:33 AM > Subject: Re: Directory Fortress Core Dependencies > > > On Feb 15, 2016, at 9:05 AM, Chris Pike <[email protected]> wrote: > > > > We are using the fortress model classes in our projects, but including > the directory-fortress-core dependencies in our pom brings along a lot of > extra dependencies, some of which are causing issues in some of our > projects. Would you be amenable to some changes in the > directory-fortress-core maven pom? > > > > We could change it into a multi module project and move the model > classes into it's own module (this would allow it to be included without > all the other classes/dependencies). It would still all be in one git > project, the maven build process would just produce multiple artifacts > (i.e. fortress-core and fortress-core-models). > > Chris assuming this requires splitting the source code into separate > trees, e.g. model and the rest? What are the alternatives? Could you > place declarations in pom(s) to exclude extraneous dependencies from your > projects? > > This is a big change. I’ve chosen not to, break/restructure, up to now > due to increased complexity. Not saying, ‘no', but want to make sure we’ve > considered the pros/cons of various options first. > > Shawn >
