Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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();
IteratorProfile pIter =
project.getModel().getProfiles().iterator(); // parent pom profiles
ignored for now
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 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
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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();
IteratorProfile 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
--
Re: Creating a pseudon-mixins plug-in problem (or how to alter the project set-up in memory)
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();
IteratorProfile 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
