You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@sonatype.com> on 2010/04/01 15:13:10 UTC
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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 <mi...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Creating a pseudon-mixins plug-in problem (or how to alter the
project set-up in memory)
Posted by Mirko Jahn <mi...@gmail.com>.
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 <ra...@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 <mi...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <mi...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org