It's not a perfect solution but look at placing dependencies in a separated POM and pulling that POM in as a dependency using scope = import.
This mode is more compositional and mixin-like. On Apr 1, 2010, at 8:56 AM, Mirko Jahn wrote: > Hi together, > > I looked into the problem again and if there is no way of limiting the > dependencies on a more aggregated level, I believe mixins are a really > important feature to look at. In my case, the parent pom with the > dependency management section and configuration already has about 2.5k > lines of xml. The good thing is that the actual components only have a > few dozen right now. Unfortunately, due to the limited scoping of the > dependencies on a more abstract level, when it comes to deployment, I > have a very limited idea of what is really needed in each assembly/ > carve out product. Of course I can look at the dependency graph, but > that doesn't necessarily tell me everything. Some dependencies are > just not used, others are abstracted to API artifacts, not containing > the real implementation. With that many dependencies it gets really > cumbersome to filter out what you really need in a specific > deployment. Maybe I am missing something important, because it is hard > for me to believe that no one else hit this problem before - after all > this shouldn't be rocket science, right? ;-) Anyway any hints on how > to attack such a scenario are greatly appreciated. > > Cheers, > Mirko > > On Mon, Mar 29, 2010 at 5:15 PM, Mirko Jahn <mirkoj...@gmail.com> wrote: >> Hi Jason, >> >> thanks for the fast reply. The requirements are somewhat common I >> guess. We provide a development framework for eHealth applications >> that depending on your module requirement needs various kinds of >> dependencies added to your project pom. >> >> Every user of our framework has to inherit one of our parent poms, >> providing it with the required dependencies. This works great until >> you hit dependencies that do not match into a a hierarchical >> dependency tree. For instance we have all dependencies defined (in a >> management section) in the parent pom. Child poms, defining a simple >> java plug-in enable some of the dependencies. Further down the >> dependency tree, more and more of these dependencies get added. So far >> everything is fine. The problem occurs with cross cutting concerns >> like persistence, web services or auditing that can occur anywhere >> within the pom hierarchy, based on the type of module. Of course, we >> can model each variation or just add all dependencies statically in >> the pom, but this is something we really don't like having (coding >> style and maintenance overhead wise). Based on our MDA/MDD approach of >> creating and managing projects, it would be easy to identify a >> type/feature used within a project and enable a set of dependencies >> defined elsewhere based on a flag in the pom for instance. Basically >> delegating the dependency management to the pom hierarchy. Profiles >> looked very promising to this extend, but failed in the activation >> capabilities on a per module basis. To give you a better understanding >> of the idea, here is a "pseudo" pom hierarchy diagram. >> >> http://yuml.me/3ebcdbc2 >> >> As you can see, the root pom defines profiles and sub-modules. >> >> Do you see another way of adding "dependency groups" on a project type >> basis? What do I miss? Where am I thinking to narrow? I am always >> happy to see alternative approaches! >> >> Many thanks, >> Mirko >> >> On Mon, Mar 29, 2010 at 4:40 PM, Jason van Zyl <ja...@sonatype.com> wrote: >>> Basing profile activation on a plugins is probably not the best idea. Are >>> these not based on the platform? >>> >>> Probably best to state what you require, as people who tend to conflate >>> their solution with what they think is required tend to go down the wrong >>> path. >>> >>> Under what conditions exactly do you need the profile activated. Right now >>> plugin configuration would be too late, but I don't think that would be the >>> right way anyway. Not that we can't change this, but the clear requirements >>> would be a good start :-) >>> >>> On Mar 29, 2010, at 6:24 AM, Mirko Jahn wrote: >>> >>>> Hey there, >>>> >>>> I am currently in the process of defining a pom hierarchy of a hugh >>>> project, which was formally developed using Maven 1. As one of the >>>> benefits we'd like to accomplish a grouping of dependencies / features >>>> and configurations. On a first look profiles seemed promising, but the >>>> lack of runtime evaluation of properties defined in the pom.xml itself >>>> made it impossible to use (we can't use the settings.xml because each >>>> component has a different set of dependencies based on the >>>> capabilities and using the command line would be too much of a hazel >>>> and just plain awkward). >>>> >>>> Anyway, the idea of having a profile as some sort of a mixin stuck to >>>> my head. So, I am currently wondering if it is possible to activate >>>> profiles based on a plug-in. I gave it a very basic try by doing the >>>> following: >>>> >>>> /** >>>> * @parameter default-value="${project}" >>>> * @required >>>> */ >>>> private MavenProject project; >>>> >>>> @Override >>>> public void execute() >>>> throws MojoExecutionException >>>> { >>>> // before check >>>> printActiveProfiles(); >>>> >>>> Iterator<Profile> pIter = >>>> project.getModel().getProfiles().iterator(); // parent pom profiles >>>> ignored for now >>>> ArrayList l = new ArrayList(); >>>> while(pIter.hasNext()){ >>>> Profile p = pIter.next(); >>>> l.add(p); >>>> } >>>> // set profiles active >>>> project.setActiveProfiles(l); >>>> >>>> // after check >>>> printActiveProfiles(); >>>> } >>>> >>>> The code above shows that it does in fact change the project, but the >>>> "activated" profiles don't get used. I assume, I didn't "inject" the >>>> altered project set-up correctly, so I was wondering if someone has a >>>> clue what to do here? >>>> >>>> My ultimate goal is to enable a set of profiles (and later generally >>>> include pom dependencies) based on a plug-in configuration. With this >>>> I would be able to define dependencies and configurations and assemble >>>> them on a "as needed" basis like real mixins for cross cutting >>>> concerns. >>>> >>>> Cheers, >>>> Mirko >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> ---------------------------------------------------------- >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ----------------------------------------------------------
