You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Alexander Kriegisch <al...@kriegisch.name> on 2014/04/01 10:42:48 UTC
Mixins as an aspect-oriented DRY tool
Dear developers,
I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable.
Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority.
With kind regards
--
Alexander Kriegisch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins as an aspect-oriented DRY tool
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 1 avril 2014 13:25:49 Jason van Zyl a écrit :
> No problem, I will write up a little description of the approach in the
> README.md file.
>
> As a user you are familiar with the pom.xml and internally what we use to
> parse that is called the ModelBuilder. It handles inheritance, profile
> application, property interpolation, dependency management and those sorts
> of things. What it gives to you at the end is the fully fleshed out model
> or what we call a MavenProject.
see http://maven.apache.org/ref/3-LATEST/maven-model-builder/ for some more
detailed info with pointers to related code
> A lifecycle participant has the ability to
> inspect and potentially mutate MavenProject instances before a build is
> executed. A number of systems utilize this to change dependency information
> before the build is executed like Tycho. But at this point I surmise it may
> be too late.
>
> Really as a user you probably have a better perspective how the system
> should work. The hard part is defining how a mixin would be defined, what
> the rules would be for applying the mixin and validating them. At the very
> least you should be able to prototype with the hacked up lifecycle
> participant and you can see if it's too limiting. I'll try to clean up the
> repo tonight and push it to Github so you can take a look.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins as an aspect-oriented DRY tool
Posted by Jason van Zyl <ja...@takari.io>.
No problem, I will write up a little description of the approach in the README.md file.
As a user you are familiar with the pom.xml and internally what we use to parse that is called the ModelBuilder. It handles inheritance, profile application, property interpolation, dependency management and those sorts of things. What it gives to you at the end is the fully fleshed out model or what we call a MavenProject. A lifecycle participant has the ability to inspect and potentially mutate MavenProject instances before a build is executed. A number of systems utilize this to change dependency information before the build is executed like Tycho. But at this point I surmise it may be too late.
Really as a user you probably have a better perspective how the system should work. The hard part is defining how a mixin would be defined, what the rules would be for applying the mixin and validating them. At the very least you should be able to prototype with the hacked up lifecycle participant and you can see if it's too limiting. I'll try to clean up the repo tonight and push it to Github so you can take a look.
On Apr 1, 2014, at 11:31 AM, Alexander Kriegisch <Al...@Kriegisch.name> wrote:
> Jason,
>
> I guess I am going to accept your generous offer even though as a fairly average Maven user I have not understood half of what you explained about the limitations and implications of your current prototype and a projected final solution.
>
> Feel free to send me private messages whenever you are ready or just stay here on the list. I will follow your path and am hoping to at least provide some valuable feedback in addition to creating extra work on your side.
> --
> Alexander Kriegisch
>
>
>> Am 01.04.2014 um 16:57 schrieb Jason van Zyl <ja...@takari.io>:
>> I have a repository with a prototype if you want to take a look. I just need to remove some crap and you're welcome to run with it if you want to do something with it. The method employed works by mutating the model once it has been read with a lifecycle participant. You can get pretty far using this method but ultimately I think that the DefaultModelBuilder will need to be changed. There are some limitations in having to deal with the fully populated model where you can't do things like inject new properties and have them be used because the ProjectBuilder has already interpolated them. We probably could add some extensions points that would allow this post processing to work but in the end I think it would be more efficient and a better design to just change the ModelBuilder.
>>
>>> On Apr 1, 2014, at 4:42 AM, Alexander Kriegisch <Al...@Kriegisch.name> wrote:
>>> I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable.
>>>
>>> Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority.
>
> ---------------------------------------------------------------------
> 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
http://twitter.com/takari_io
---------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: Mixins as an aspect-oriented DRY tool
Posted by Alexander Kriegisch <Al...@Kriegisch.name>.
Jason,
I guess I am going to accept your generous offer even though as a fairly average Maven user I have not understood half of what you explained about the limitations and implications of your current prototype and a projected final solution.
Feel free to send me private messages whenever you are ready or just stay here on the list. I will follow your path and am hoping to at least provide some valuable feedback in addition to creating extra work on your side.
--
Alexander Kriegisch
> Am 01.04.2014 um 16:57 schrieb Jason van Zyl <ja...@takari.io>:
> I have a repository with a prototype if you want to take a look. I just need to remove some crap and you're welcome to run with it if you want to do something with it. The method employed works by mutating the model once it has been read with a lifecycle participant. You can get pretty far using this method but ultimately I think that the DefaultModelBuilder will need to be changed. There are some limitations in having to deal with the fully populated model where you can't do things like inject new properties and have them be used because the ProjectBuilder has already interpolated them. We probably could add some extensions points that would allow this post processing to work but in the end I think it would be more efficient and a better design to just change the ModelBuilder.
>
>> On Apr 1, 2014, at 4:42 AM, Alexander Kriegisch <Al...@Kriegisch.name> wrote:
>> I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable.
>>
>> Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins as an aspect-oriented DRY tool
Posted by Jason van Zyl <ja...@takari.io>.
Alexander,
I have a repository with a prototype if you want to take a look. I just need to remove some crap and you're welcome to run with it if you want to do something with it. The method employed works by mutating the model once it has been read with a lifecycle participant. You can get pretty far using this method but ultimately I think that the DefaultModelBuilder will need to be changed. There are some limitations in having to deal with the fully populated model where you can't do things like inject new properties and have them be used because the ProjectBuilder has already interpolated them. We probably could add some extensions points that would allow this post processing to work but in the end I think it would be more efficient and a better design to just change the ModelBuilder.
On Apr 1, 2014, at 4:42 AM, Alexander Kriegisch <Al...@Kriegisch.name> wrote:
> Dear developers,
>
> I guess at least since 2008 Jason had the idea to implement Maven mixins, i.e. a kind of include mechanism in order for users to be able to encapsulate sets of dependencies (not just their version numbers as with import-scoped BoMs) and re-use them throughout modules or even across projects. This is something I (and probably many others) have been waiting for desperately because via inheritance you can only have one aspect covered, but not multiple ones. Comparing to single inheritance in OOP, in order to cleanly encapsulate secondary (even cross-cutting) concerns there are powerful concepts like AOP (I love to use AspectJ for that matter) or simpler ones like mixins. I think mixins would suffice for Maven and massively support DRY (don't repeat yourself), thus making it much easier to keep Maven configurations cleaner and more maintainable.
>
> Having said that, I know it is always easier to ask for something than to just implement it by myself (which I am uncapable of because I have never touched or even seen the Maven code base). So, humbly and with all due respect to you as a newbie on this list, I am asking if mixins are still on the development agenda and if the feature has a rather low or high priority.
>
> With kind regards
> --
> Alexander Kriegisch
>
>
> ---------------------------------------------------------------------
> 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
http://twitter.com/takari_io
---------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Mixins as an aspect-oriented DRY tool
Posted by Alexander Kriegisch <al...@kriegisch.name>.
Yes, I found that via Google (maybe someone can fix the wiki anyway), but there is a technical issue (sorry to bother this list with it):
I just wanted to comment on the corresponding ticket https://jira.codehaus.org/browse/MNG-5102, but I do not have a user account for the wiki yet. Direct sign-up is not poassible, the page tells me to use https://xircles.codehaus.org/signup. When trying to sign up there, xircles telle me that my e-mail address does not match my Confluence account (which I do not have). A vicious circle? How can I sign up and participate on discussions on the relevant ticket?
--
Alexander Kriegisch
Tamás Cservenák schrieb am 01.04.2014 11:55:
> Re MNG issue links... they are in codehaus Jira. Just prepend the "
> http://jira.codehaus.org/browse" to them.
>
> Like
> http://jira.codehaus.org/browse/MNG-5102
>
>
> On Tue, Apr 1, 2014 at 11:51 AM, Alexander Kriegisch <
> alexander@kriegisch.name> wrote:
>
>> Thanks Anders,
>>
>> so part of my question is answered: prio is major (like most other tickets
>> on that target version) and there is a ticket for it. I have a few
>> remaining issues though:
>> - All links to related tickets are broken, they just point back
>> to the wiki page itself.
>> - There is no release schedule (e.g. a rough date estimate
>> for version 4). Should I assume that it's done when it's done?
>> - Is v4 being worked on already or is in the conceptual stage?
>> - If I want to offer help testing mixin prototypes/betas, how
>> do I learn when/how to contribute?
>>
>> Regards
>> --
>> Alexander Kriegisch
>>
>>
>> Anders Hammar schrieb am 01.04.2014 10:53:
>>
>> > Here's the wiki page covering Maven 4:
>> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0
>> >
>> > /Anders
>> >
>> >
>> > On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch <
>> > alexander@kriegisch.name> wrote:
>> >
>> >> Dear developers,
>> >>
>> >> I guess at least since 2008 Jason had the idea to implement Maven
>> mixins,
>> >> i.e. a kind of include mechanism in order for users to be able to
>> >> encapsulate sets of dependencies (not just their version numbers as with
>> >> import-scoped BoMs) and re-use them throughout modules or even across
>> >> projects. This is something I (and probably many others) have been
>> waiting
>> >> for desperately because via inheritance you can only have one aspect
>> >> covered, but not multiple ones. Comparing to single inheritance in OOP,
>> in
>> >> order to cleanly encapsulate secondary (even cross-cutting) concerns
>> there
>> >> are powerful concepts like AOP (I love to use AspectJ for that matter)
>> or
>> >> simpler ones like mixins. I think mixins would suffice for Maven and
>> >> massively support DRY (don't repeat yourself), thus making it much
>> easier
>> >> to keep Maven configurations cleaner and more maintainable.
>> >>
>> >> Having said that, I know it is always easier to ask for something than
>> to
>> >> just implement it by myself (which I am uncapable of because I have
>> never
>> >> touched or even seen the Maven code base). So, humbly and with all due
>> >> respect to you as a newbie on this list, I am asking if mixins are
>> still on
>> >> the development agenda and if the feature has a rather low or high
>> priority.
>> >>
>> >> With kind regards
>> >> --
>> >> Alexander Kriegisch
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mixins as an aspect-oriented DRY tool
Posted by Tamás Cservenák <ta...@cservenak.net>.
Re MNG issue links... they are in codehaus Jira. Just prepend the "
http://jira.codehaus.org/browse" to them.
Like
http://jira.codehaus.org/browse/MNG-5102
On Tue, Apr 1, 2014 at 11:51 AM, Alexander Kriegisch <
alexander@kriegisch.name> wrote:
> Thanks Anders,
>
> so part of my question is answered: prio is major (like most other tickets
> on that target version) and there is a ticket for it. I have a few
> remaining issues though:
> - All links to related tickets are broken, they just point back
> to the wiki page itself.
> - There is no release schedule (e.g. a rough date estimate
> for version 4). Should I assume that it's done when it's done?
> - Is v4 being worked on already or is in the conceptual stage?
> - If I want to offer help testing mixin prototypes/betas, how
> do I learn when/how to contribute?
>
> Regards
> --
> Alexander Kriegisch
>
>
> Anders Hammar schrieb am 01.04.2014 10:53:
>
> > Here's the wiki page covering Maven 4:
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0
> >
> > /Anders
> >
> >
> > On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch <
> > alexander@kriegisch.name> wrote:
> >
> >> Dear developers,
> >>
> >> I guess at least since 2008 Jason had the idea to implement Maven
> mixins,
> >> i.e. a kind of include mechanism in order for users to be able to
> >> encapsulate sets of dependencies (not just their version numbers as with
> >> import-scoped BoMs) and re-use them throughout modules or even across
> >> projects. This is something I (and probably many others) have been
> waiting
> >> for desperately because via inheritance you can only have one aspect
> >> covered, but not multiple ones. Comparing to single inheritance in OOP,
> in
> >> order to cleanly encapsulate secondary (even cross-cutting) concerns
> there
> >> are powerful concepts like AOP (I love to use AspectJ for that matter)
> or
> >> simpler ones like mixins. I think mixins would suffice for Maven and
> >> massively support DRY (don't repeat yourself), thus making it much
> easier
> >> to keep Maven configurations cleaner and more maintainable.
> >>
> >> Having said that, I know it is always easier to ask for something than
> to
> >> just implement it by myself (which I am uncapable of because I have
> never
> >> touched or even seen the Maven code base). So, humbly and with all due
> >> respect to you as a newbie on this list, I am asking if mixins are
> still on
> >> the development agenda and if the feature has a rather low or high
> priority.
> >>
> >> With kind regards
> >> --
> >> Alexander Kriegisch
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Mixins as an aspect-oriented DRY tool
Posted by Anders Hammar <an...@hammar.net>.
It's discussion right now and I don't think there has been any actaul work
(other than possibly some private PoC). And it will be done when it's done.
:-)
/Anders
On Tue, Apr 1, 2014 at 11:51 AM, Alexander Kriegisch <
alexander@kriegisch.name> wrote:
> Thanks Anders,
>
> so part of my question is answered: prio is major (like most other tickets
> on that target version) and there is a ticket for it. I have a few
> remaining issues though:
> - All links to related tickets are broken, they just point back
> to the wiki page itself.
> - There is no release schedule (e.g. a rough date estimate
> for version 4). Should I assume that it's done when it's done?
> - Is v4 being worked on already or is in the conceptual stage?
> - If I want to offer help testing mixin prototypes/betas, how
> do I learn when/how to contribute?
>
> Regards
> --
> Alexander Kriegisch
>
>
> Anders Hammar schrieb am 01.04.2014 10:53:
>
> > Here's the wiki page covering Maven 4:
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0
> >
> > /Anders
> >
> >
> > On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch <
> > alexander@kriegisch.name> wrote:
> >
> >> Dear developers,
> >>
> >> I guess at least since 2008 Jason had the idea to implement Maven
> mixins,
> >> i.e. a kind of include mechanism in order for users to be able to
> >> encapsulate sets of dependencies (not just their version numbers as with
> >> import-scoped BoMs) and re-use them throughout modules or even across
> >> projects. This is something I (and probably many others) have been
> waiting
> >> for desperately because via inheritance you can only have one aspect
> >> covered, but not multiple ones. Comparing to single inheritance in OOP,
> in
> >> order to cleanly encapsulate secondary (even cross-cutting) concerns
> there
> >> are powerful concepts like AOP (I love to use AspectJ for that matter)
> or
> >> simpler ones like mixins. I think mixins would suffice for Maven and
> >> massively support DRY (don't repeat yourself), thus making it much
> easier
> >> to keep Maven configurations cleaner and more maintainable.
> >>
> >> Having said that, I know it is always easier to ask for something than
> to
> >> just implement it by myself (which I am uncapable of because I have
> never
> >> touched or even seen the Maven code base). So, humbly and with all due
> >> respect to you as a newbie on this list, I am asking if mixins are
> still on
> >> the development agenda and if the feature has a rather low or high
> priority.
> >>
> >> With kind regards
> >> --
> >> Alexander Kriegisch
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Mixins as an aspect-oriented DRY tool
Posted by Alexander Kriegisch <al...@kriegisch.name>.
Thanks Anders,
so part of my question is answered: prio is major (like most other tickets on that target version) and there is a ticket for it. I have a few remaining issues though:
- All links to related tickets are broken, they just point back
to the wiki page itself.
- There is no release schedule (e.g. a rough date estimate
for version 4). Should I assume that it's done when it's done?
- Is v4 being worked on already or is in the conceptual stage?
- If I want to offer help testing mixin prototypes/betas, how
do I learn when/how to contribute?
Regards
--
Alexander Kriegisch
Anders Hammar schrieb am 01.04.2014 10:53:
> Here's the wiki page covering Maven 4:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0
>
> /Anders
>
>
> On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch <
> alexander@kriegisch.name> wrote:
>
>> Dear developers,
>>
>> I guess at least since 2008 Jason had the idea to implement Maven mixins,
>> i.e. a kind of include mechanism in order for users to be able to
>> encapsulate sets of dependencies (not just their version numbers as with
>> import-scoped BoMs) and re-use them throughout modules or even across
>> projects. This is something I (and probably many others) have been waiting
>> for desperately because via inheritance you can only have one aspect
>> covered, but not multiple ones. Comparing to single inheritance in OOP, in
>> order to cleanly encapsulate secondary (even cross-cutting) concerns there
>> are powerful concepts like AOP (I love to use AspectJ for that matter) or
>> simpler ones like mixins. I think mixins would suffice for Maven and
>> massively support DRY (don't repeat yourself), thus making it much easier
>> to keep Maven configurations cleaner and more maintainable.
>>
>> Having said that, I know it is always easier to ask for something than to
>> just implement it by myself (which I am uncapable of because I have never
>> touched or even seen the Maven code base). So, humbly and with all due
>> respect to you as a newbie on this list, I am asking if mixins are still on
>> the development agenda and if the feature has a rather low or high priority.
>>
>> With kind regards
>> --
>> Alexander Kriegisch
>>
>>
>> ---------------------------------------------------------------------
>> 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: Mixins as an aspect-oriented DRY tool
Posted by Anders Hammar <an...@hammar.net>.
Here's the wiki page covering Maven 4:
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0
/Anders
On Tue, Apr 1, 2014 at 10:42 AM, Alexander Kriegisch <
alexander@kriegisch.name> wrote:
> Dear developers,
>
> I guess at least since 2008 Jason had the idea to implement Maven mixins,
> i.e. a kind of include mechanism in order for users to be able to
> encapsulate sets of dependencies (not just their version numbers as with
> import-scoped BoMs) and re-use them throughout modules or even across
> projects. This is something I (and probably many others) have been waiting
> for desperately because via inheritance you can only have one aspect
> covered, but not multiple ones. Comparing to single inheritance in OOP, in
> order to cleanly encapsulate secondary (even cross-cutting) concerns there
> are powerful concepts like AOP (I love to use AspectJ for that matter) or
> simpler ones like mixins. I think mixins would suffice for Maven and
> massively support DRY (don't repeat yourself), thus making it much easier
> to keep Maven configurations cleaner and more maintainable.
>
> Having said that, I know it is always easier to ask for something than to
> just implement it by myself (which I am uncapable of because I have never
> touched or even seen the Maven code base). So, humbly and with all due
> respect to you as a newbie on this list, I am asking if mixins are still on
> the development agenda and if the feature has a rather low or high priority.
>
> With kind regards
> --
> Alexander Kriegisch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>