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
