Well, that sounds promising! I'll give that a try and see how that can help us managing our dependencies. Thanks a lot for the valuable feedback!
Cheers, Mirko On Thu, Apr 1, 2010 at 3:55 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Yes, import scope can help with this. > > We have a pom that declares the version of any dependency we MIGHT need. > That pom gets imported to control the versions. The actual project poms then > reference the dependencies they need to compile and run. When maven is > building the artifact that is deployable, such as a war, it should run > through all the transitive dependencies and make sure they are included using > the versions specified in the dependency management of the imported pom. > > Mix-ins have been discussed several times and we agree that they are a better > way to do this. > > Ralph > > On Apr 1, 2010, at 6:13 AM, Jason van Zyl wrote: > >> 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 >> ---------------------------------------------------------- >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
