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
