> Wayne Fay wrote: > > The real use case for import scope IMO is where a company > does not want to use a single shared corporate parent pom, > but they do want to enforce versions on all projects. So you > manage versions in the imported pom (one place), force all > your projects to import it (can be any pom in the repo), and > poof they all get version maintenance for free. >
Hi Wayne, Hmmm, if that's true I did misunderstand the intent. I thought it was to handle the 'dependency aggregator pattern' as a scope instead of perhaps mis-using transitive dependencies. I'm using the term 'dependency aggregator', others on the ML's have called it different things. (inheritance pom or meta pom have been used I think) So in our case we are trying to manage the Websphere runtime classpath as a single set of dependencies. The case for doing this is pretty strong and we've been using it to aggregate the container library into a single dependency in our projects for while. I was hoping the import scope would make this a first class pattern and relieve my future proofing concern with it. What you say would explain..it didn't make sense to me that it went into dependencyManagement. Best regards -TR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
