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...@takari.io> on 2014/01/19 19:36:04 UTC
MNG-1911 -- Close as won't fix
I don't think there are really any valid use cases for trying to build an extension where it is used in the same reactor. Extensions really need to be present before the reactor starts and trying to do this is a contortion I really don't want to support.
I would like to close this as won't fix. Anyone object?
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
Re: MNG-1911 -- Close as won't fix
Posted by Benson Margulies <bi...@gmail.com>.
How about asking also asking this question: should all the function
currently in packaging need to be extensions? What users want is to
define certain kinds of things as one big build.
On Sun, Jan 19, 2014 at 4:06 PM, Jason van Zyl <ja...@takari.io> wrote:
> Sure, so this issue I think can be closed and another one created to warn people about attempting to build an extension for use in the same build.
>
> On Jan 19, 2014, at 3:48 PM, Robert Scholte <rf...@apache.org> wrote:
>
>> Shouldn't we be able to detect such abuse and warn for it (maybe even fail?).
>> Now it'll only work if the extension-plugin is available in the local repo, which is probably not what users will expect. The plugin will always be one step/execution behind compared to the reactor build.
>>
>> Robert
>>
>> Op Sun, 19 Jan 2014 21:28:03 +0100 schreef Milos Kleint <mk...@gmail.com>:
>>
>>> On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>>>> That extensions are required very early on in the build and too support them being produced in a build where they are additionally used would require contortions in the core and would also make supporting this in the various IDEs also very complicated.
>>>
>>>
>>> Yup, it's been an ongoing problem with the glassfish build for some if
>>> I recall correctly. The IDE needs to evaluate each project separately,
>>> and missing extensions/plugins fail the model loading, with reactor
>>> based plugins/extensions there's no easy "single project"solution, one
>>> needs to build the entire reactor to get the plugin/extension to local
>>> repo.
>>>
>>> milos
>>>
>>>>
>>>> Is what I would say.
>>>>
>>>> On Jan 19, 2014, at 2:48 PM, Stephen Connolly <st...@gmail.com> wrote:
>>>>
>>>>> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>>>>>
>>>>>>
>>>>>> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
>>>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>>
>>>>>>> There are quite a number of users who want this functionality and the
>>>>>>> corresponding ability to build a plugin from the same reactor as it is
>>>>>>> consumed in.
>>>>>>>
>>>>>>
>>>>>> Building a plugin in the same reactor works, building a plugin in a
>>>>>> reactor that provides extensions does not work. Extensions, IMO, need to be
>>>>>> present before the build starts. It's this second use case I don't want to
>>>>>> support.
>>>>>>
>>>>>>
>>>>> I understand the desire... I agree with the desire... It's those pesky
>>>>> users... People want to define a custom packaging *and* then use it in the
>>>>> same reactor.
>>>>>
>>>>> I would love if people would just accept that it's better to do that as a
>>>>> different reactor... But that is not how lazy users think...
>>>>>
>>>>> We should add a good explanation to our rational if we are saying WONTFIX
>>>>>
>>>>>
>>>>>>> Usually this is due to lazyness, ie not wanting to cut a release of a
>>>>>>> plugin/extension just to make the build... Iow the use case were somebody
>>>>>>> "would like to write a one off script, but instead does the maven way and
>>>>>>> writes a one off plugin/extension"
>>>>>>>
>>>>>>> The other use case is eg openejb/tomee who have a plugin tied to their
>>>>>>> release version and don't want to split the build into three release
>>>>>> roots
>>>>>>> (stuff that plugin depends on; the plugin; stuff that needs the plugin)
>>>>>>>
>>>>>>> I think we should allow this kind of thing with certain very strict
>>>>>> bounds,
>>>>>>> but I am happy to push back to a new model version (which would allow
>>>>>>> expressing such stricter bounds) and ok with saying wontfix if we are ok
>>>>>>> potentially alienating the users who feel they need this (could live
>>>>>> with a
>>>>>>> way to provide a workaround though)
>>>>>>>
>>>>>>> On Sunday, 19 January 2014, Jason van Zyl <jason@takari.io<javascript:;>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I don't think there are really any valid use cases for trying to build
>>>>>> an
>>>>>>>> extension where it is used in the same reactor. Extensions really need
>>>>>> to
>>>>>>>> be present before the reactor starts and trying to do this is a
>>>>>> contortion
>>>>>>>> I really don't want to support.
>>>>>>>>
>>>>>>>> I would like to close this as won't fix. Anyone object?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jason
>>>>>>>>
>>>>>>>> ----------------------------------------------------------
>>>>>>>> Jason van Zyl
>>>>>>>> Founder, Apache Maven
>>>>>>>> http://twitter.com/jvanzyl
>>>>>>>> ---------------------------------------------------------
>>>>>>>>
>>>>>>>> We know what we are, but know not what we may be.
>>>>>>>>
>>>>>>>> -- Shakespeare
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sent from my phone
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder, Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>>
>>>>>> You are never dedicated to something you have complete confidence in.
>>>>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>>>>> They know it is going to rise tomorrow. When people are fanatically
>>>>>> dedicated to political or religious faiths or any other kind of
>>>>>> dogmas or goals, it's always because these dogmas or
>>>>>> goals are in doubt.
>>>>>>
>>>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from my phone
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-1911 -- Close as won't fix
Posted by Jason van Zyl <ja...@takari.io>.
Sure, so this issue I think can be closed and another one created to warn people about attempting to build an extension for use in the same build.
On Jan 19, 2014, at 3:48 PM, Robert Scholte <rf...@apache.org> wrote:
> Shouldn't we be able to detect such abuse and warn for it (maybe even fail?).
> Now it'll only work if the extension-plugin is available in the local repo, which is probably not what users will expect. The plugin will always be one step/execution behind compared to the reactor build.
>
> Robert
>
> Op Sun, 19 Jan 2014 21:28:03 +0100 schreef Milos Kleint <mk...@gmail.com>:
>
>> On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>>> That extensions are required very early on in the build and too support them being produced in a build where they are additionally used would require contortions in the core and would also make supporting this in the various IDEs also very complicated.
>>
>>
>> Yup, it's been an ongoing problem with the glassfish build for some if
>> I recall correctly. The IDE needs to evaluate each project separately,
>> and missing extensions/plugins fail the model loading, with reactor
>> based plugins/extensions there's no easy "single project"solution, one
>> needs to build the entire reactor to get the plugin/extension to local
>> repo.
>>
>> milos
>>
>>>
>>> Is what I would say.
>>>
>>> On Jan 19, 2014, at 2:48 PM, Stephen Connolly <st...@gmail.com> wrote:
>>>
>>>> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>>>>
>>>>>
>>>>> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
>>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>>
>>>>>> There are quite a number of users who want this functionality and the
>>>>>> corresponding ability to build a plugin from the same reactor as it is
>>>>>> consumed in.
>>>>>>
>>>>>
>>>>> Building a plugin in the same reactor works, building a plugin in a
>>>>> reactor that provides extensions does not work. Extensions, IMO, need to be
>>>>> present before the build starts. It's this second use case I don't want to
>>>>> support.
>>>>>
>>>>>
>>>> I understand the desire... I agree with the desire... It's those pesky
>>>> users... People want to define a custom packaging *and* then use it in the
>>>> same reactor.
>>>>
>>>> I would love if people would just accept that it's better to do that as a
>>>> different reactor... But that is not how lazy users think...
>>>>
>>>> We should add a good explanation to our rational if we are saying WONTFIX
>>>>
>>>>
>>>>>> Usually this is due to lazyness, ie not wanting to cut a release of a
>>>>>> plugin/extension just to make the build... Iow the use case were somebody
>>>>>> "would like to write a one off script, but instead does the maven way and
>>>>>> writes a one off plugin/extension"
>>>>>>
>>>>>> The other use case is eg openejb/tomee who have a plugin tied to their
>>>>>> release version and don't want to split the build into three release
>>>>> roots
>>>>>> (stuff that plugin depends on; the plugin; stuff that needs the plugin)
>>>>>>
>>>>>> I think we should allow this kind of thing with certain very strict
>>>>> bounds,
>>>>>> but I am happy to push back to a new model version (which would allow
>>>>>> expressing such stricter bounds) and ok with saying wontfix if we are ok
>>>>>> potentially alienating the users who feel they need this (could live
>>>>> with a
>>>>>> way to provide a workaround though)
>>>>>>
>>>>>> On Sunday, 19 January 2014, Jason van Zyl <jason@takari.io<javascript:;>>
>>>>> wrote:
>>>>>>
>>>>>>> I don't think there are really any valid use cases for trying to build
>>>>> an
>>>>>>> extension where it is used in the same reactor. Extensions really need
>>>>> to
>>>>>>> be present before the reactor starts and trying to do this is a
>>>>> contortion
>>>>>>> I really don't want to support.
>>>>>>>
>>>>>>> I would like to close this as won't fix. Anyone object?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> ----------------------------------------------------------
>>>>>>> Jason van Zyl
>>>>>>> Founder, Apache Maven
>>>>>>> http://twitter.com/jvanzyl
>>>>>>> ---------------------------------------------------------
>>>>>>>
>>>>>>> We know what we are, but know not what we may be.
>>>>>>>
>>>>>>> -- Shakespeare
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my phone
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>>
>>>>> You are never dedicated to something you have complete confidence in.
>>>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>>>> They know it is going to rise tomorrow. When people are fanatically
>>>>> dedicated to political or religious faiths or any other kind of
>>>>> dogmas or goals, it's always because these dogmas or
>>>>> goals are in doubt.
>>>>>
>>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
Re: MNG-1911 -- Close as won't fix
Posted by Robert Scholte <rf...@apache.org>.
Shouldn't we be able to detect such abuse and warn for it (maybe even
fail?).
Now it'll only work if the extension-plugin is available in the local
repo, which is probably not what users will expect. The plugin will always
be one step/execution behind compared to the reactor build.
Robert
Op Sun, 19 Jan 2014 21:28:03 +0100 schreef Milos Kleint
<mk...@gmail.com>:
> On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl <ja...@takari.io> wrote:
>> That extensions are required very early on in the build and too support
>> them being produced in a build where they are additionally used would
>> require contortions in the core and would also make supporting this in
>> the various IDEs also very complicated.
>
>
> Yup, it's been an ongoing problem with the glassfish build for some if
> I recall correctly. The IDE needs to evaluate each project separately,
> and missing extensions/plugins fail the model loading, with reactor
> based plugins/extensions there's no easy "single project"solution, one
> needs to build the entire reactor to get the plugin/extension to local
> repo.
>
> milos
>
>>
>> Is what I would say.
>>
>> On Jan 19, 2014, at 2:48 PM, Stephen Connolly
>> <st...@gmail.com> wrote:
>>
>>> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>>>
>>>>
>>>> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
>>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>>
>>>>> There are quite a number of users who want this functionality and the
>>>>> corresponding ability to build a plugin from the same reactor as it
>>>>> is
>>>>> consumed in.
>>>>>
>>>>
>>>> Building a plugin in the same reactor works, building a plugin in a
>>>> reactor that provides extensions does not work. Extensions, IMO, need
>>>> to be
>>>> present before the build starts. It's this second use case I don't
>>>> want to
>>>> support.
>>>>
>>>>
>>> I understand the desire... I agree with the desire... It's those pesky
>>> users... People want to define a custom packaging *and* then use it in
>>> the
>>> same reactor.
>>>
>>> I would love if people would just accept that it's better to do that
>>> as a
>>> different reactor... But that is not how lazy users think...
>>>
>>> We should add a good explanation to our rational if we are saying
>>> WONTFIX
>>>
>>>
>>>>> Usually this is due to lazyness, ie not wanting to cut a release of a
>>>>> plugin/extension just to make the build... Iow the use case were
>>>>> somebody
>>>>> "would like to write a one off script, but instead does the maven
>>>>> way and
>>>>> writes a one off plugin/extension"
>>>>>
>>>>> The other use case is eg openejb/tomee who have a plugin tied to
>>>>> their
>>>>> release version and don't want to split the build into three release
>>>> roots
>>>>> (stuff that plugin depends on; the plugin; stuff that needs the
>>>>> plugin)
>>>>>
>>>>> I think we should allow this kind of thing with certain very strict
>>>> bounds,
>>>>> but I am happy to push back to a new model version (which would allow
>>>>> expressing such stricter bounds) and ok with saying wontfix if we
>>>>> are ok
>>>>> potentially alienating the users who feel they need this (could live
>>>> with a
>>>>> way to provide a workaround though)
>>>>>
>>>>> On Sunday, 19 January 2014, Jason van Zyl
>>>>> <jason@takari.io<javascript:;>>
>>>> wrote:
>>>>>
>>>>>> I don't think there are really any valid use cases for trying to
>>>>>> build
>>>> an
>>>>>> extension where it is used in the same reactor. Extensions really
>>>>>> need
>>>> to
>>>>>> be present before the reactor starts and trying to do this is a
>>>> contortion
>>>>>> I really don't want to support.
>>>>>>
>>>>>> I would like to close this as won't fix. Anyone object?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> Jason van Zyl
>>>>>> Founder, Apache Maven
>>>>>> http://twitter.com/jvanzyl
>>>>>> ---------------------------------------------------------
>>>>>>
>>>>>> We know what we are, but know not what we may be.
>>>>>>
>>>>>> -- Shakespeare
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Sent from my phone
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> You are never dedicated to something you have complete confidence in.
>>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>>> They know it is going to rise tomorrow. When people are fanatically
>>>> dedicated to political or religious faiths or any other kind of
>>>> dogmas or goals, it's always because these dogmas or
>>>> goals are in doubt.
>>>>
>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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: MNG-1911 -- Close as won't fix
Posted by Milos Kleint <mk...@gmail.com>.
On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl <ja...@takari.io> wrote:
> That extensions are required very early on in the build and too support them being produced in a build where they are additionally used would require contortions in the core and would also make supporting this in the various IDEs also very complicated.
Yup, it's been an ongoing problem with the glassfish build for some if
I recall correctly. The IDE needs to evaluate each project separately,
and missing extensions/plugins fail the model loading, with reactor
based plugins/extensions there's no easy "single project"solution, one
needs to build the entire reactor to get the plugin/extension to local
repo.
milos
>
> Is what I would say.
>
> On Jan 19, 2014, at 2:48 PM, Stephen Connolly <st...@gmail.com> wrote:
>
>> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>>
>>>
>>> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>>
>>>> There are quite a number of users who want this functionality and the
>>>> corresponding ability to build a plugin from the same reactor as it is
>>>> consumed in.
>>>>
>>>
>>> Building a plugin in the same reactor works, building a plugin in a
>>> reactor that provides extensions does not work. Extensions, IMO, need to be
>>> present before the build starts. It's this second use case I don't want to
>>> support.
>>>
>>>
>> I understand the desire... I agree with the desire... It's those pesky
>> users... People want to define a custom packaging *and* then use it in the
>> same reactor.
>>
>> I would love if people would just accept that it's better to do that as a
>> different reactor... But that is not how lazy users think...
>>
>> We should add a good explanation to our rational if we are saying WONTFIX
>>
>>
>>>> Usually this is due to lazyness, ie not wanting to cut a release of a
>>>> plugin/extension just to make the build... Iow the use case were somebody
>>>> "would like to write a one off script, but instead does the maven way and
>>>> writes a one off plugin/extension"
>>>>
>>>> The other use case is eg openejb/tomee who have a plugin tied to their
>>>> release version and don't want to split the build into three release
>>> roots
>>>> (stuff that plugin depends on; the plugin; stuff that needs the plugin)
>>>>
>>>> I think we should allow this kind of thing with certain very strict
>>> bounds,
>>>> but I am happy to push back to a new model version (which would allow
>>>> expressing such stricter bounds) and ok with saying wontfix if we are ok
>>>> potentially alienating the users who feel they need this (could live
>>> with a
>>>> way to provide a workaround though)
>>>>
>>>> On Sunday, 19 January 2014, Jason van Zyl <jason@takari.io<javascript:;>>
>>> wrote:
>>>>
>>>>> I don't think there are really any valid use cases for trying to build
>>> an
>>>>> extension where it is used in the same reactor. Extensions really need
>>> to
>>>>> be present before the reactor starts and trying to do this is a
>>> contortion
>>>>> I really don't want to support.
>>>>>
>>>>> I would like to close this as won't fix. Anyone object?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ---------------------------------------------------------
>>>>>
>>>>> We know what we are, but know not what we may be.
>>>>>
>>>>> -- Shakespeare
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ---------------------------------------------------------
>>>
>>> You are never dedicated to something you have complete confidence in.
>>> No one is fanatically shouting that the sun is going to rise tomorrow.
>>> They know it is going to rise tomorrow. When people are fanatically
>>> dedicated to political or religious faiths or any other kind of
>>> dogmas or goals, it's always because these dogmas or
>>> goals are in doubt.
>>>
>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-1911 -- Close as won't fix
Posted by Jason van Zyl <ja...@takari.io>.
That extensions are required very early on in the build and too support them being produced in a build where they are additionally used would require contortions in the core and would also make supporting this in the various IDEs also very complicated.
Is what I would say.
On Jan 19, 2014, at 2:48 PM, Stephen Connolly <st...@gmail.com> wrote:
> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>
>>
>> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>>
>>> There are quite a number of users who want this functionality and the
>>> corresponding ability to build a plugin from the same reactor as it is
>>> consumed in.
>>>
>>
>> Building a plugin in the same reactor works, building a plugin in a
>> reactor that provides extensions does not work. Extensions, IMO, need to be
>> present before the build starts. It's this second use case I don't want to
>> support.
>>
>>
> I understand the desire... I agree with the desire... It's those pesky
> users... People want to define a custom packaging *and* then use it in the
> same reactor.
>
> I would love if people would just accept that it's better to do that as a
> different reactor... But that is not how lazy users think...
>
> We should add a good explanation to our rational if we are saying WONTFIX
>
>
>>> Usually this is due to lazyness, ie not wanting to cut a release of a
>>> plugin/extension just to make the build... Iow the use case were somebody
>>> "would like to write a one off script, but instead does the maven way and
>>> writes a one off plugin/extension"
>>>
>>> The other use case is eg openejb/tomee who have a plugin tied to their
>>> release version and don't want to split the build into three release
>> roots
>>> (stuff that plugin depends on; the plugin; stuff that needs the plugin)
>>>
>>> I think we should allow this kind of thing with certain very strict
>> bounds,
>>> but I am happy to push back to a new model version (which would allow
>>> expressing such stricter bounds) and ok with saying wontfix if we are ok
>>> potentially alienating the users who feel they need this (could live
>> with a
>>> way to provide a workaround though)
>>>
>>> On Sunday, 19 January 2014, Jason van Zyl <jason@takari.io<javascript:;>>
>> wrote:
>>>
>>>> I don't think there are really any valid use cases for trying to build
>> an
>>>> extension where it is used in the same reactor. Extensions really need
>> to
>>>> be present before the reactor starts and trying to do this is a
>> contortion
>>>> I really don't want to support.
>>>>
>>>> I would like to close this as won't fix. Anyone object?
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ---------------------------------------------------------
>>>>
>>>> We know what we are, but know not what we may be.
>>>>
>>>> -- Shakespeare
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Sent from my phone
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> You are never dedicated to something you have complete confidence in.
>> No one is fanatically shouting that the sun is going to rise tomorrow.
>> They know it is going to rise tomorrow. When people are fanatically
>> dedicated to political or religious faiths or any other kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>>
>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Sent from my phone
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: MNG-1911 -- Close as won't fix
Posted by Stephen Connolly <st...@gmail.com>.
On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>
> On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com <javascript:;>> wrote:
>
> > There are quite a number of users who want this functionality and the
> > corresponding ability to build a plugin from the same reactor as it is
> > consumed in.
> >
>
> Building a plugin in the same reactor works, building a plugin in a
> reactor that provides extensions does not work. Extensions, IMO, need to be
> present before the build starts. It's this second use case I don't want to
> support.
>
>
I understand the desire... I agree with the desire... It's those pesky
users... People want to define a custom packaging *and* then use it in the
same reactor.
I would love if people would just accept that it's better to do that as a
different reactor... But that is not how lazy users think...
We should add a good explanation to our rational if we are saying WONTFIX
> > Usually this is due to lazyness, ie not wanting to cut a release of a
> > plugin/extension just to make the build... Iow the use case were somebody
> > "would like to write a one off script, but instead does the maven way and
> > writes a one off plugin/extension"
> >
> > The other use case is eg openejb/tomee who have a plugin tied to their
> > release version and don't want to split the build into three release
> roots
> > (stuff that plugin depends on; the plugin; stuff that needs the plugin)
> >
> > I think we should allow this kind of thing with certain very strict
> bounds,
> > but I am happy to push back to a new model version (which would allow
> > expressing such stricter bounds) and ok with saying wontfix if we are ok
> > potentially alienating the users who feel they need this (could live
> with a
> > way to provide a workaround though)
> >
> > On Sunday, 19 January 2014, Jason van Zyl <jason@takari.io<javascript:;>>
> wrote:
> >
> >> I don't think there are really any valid use cases for trying to build
> an
> >> extension where it is used in the same reactor. Extensions really need
> to
> >> be present before the reactor starts and trying to do this is a
> contortion
> >> I really don't want to support.
> >>
> >> I would like to close this as won't fix. Anyone object?
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> We know what we are, but know not what we may be.
> >>
> >> -- Shakespeare
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
>
>
>
>
>
--
Sent from my phone
Re: MNG-1911 -- Close as won't fix
Posted by Jason van Zyl <ja...@takari.io>.
On Jan 19, 2014, at 2:13 PM, Stephen Connolly <st...@gmail.com> wrote:
> There are quite a number of users who want this functionality and the
> corresponding ability to build a plugin from the same reactor as it is
> consumed in.
>
Building a plugin in the same reactor works, building a plugin in a reactor that provides extensions does not work. Extensions, IMO, need to be present before the build starts. It's this second use case I don't want to support.
> Usually this is due to lazyness, ie not wanting to cut a release of a
> plugin/extension just to make the build... Iow the use case were somebody
> "would like to write a one off script, but instead does the maven way and
> writes a one off plugin/extension"
>
> The other use case is eg openejb/tomee who have a plugin tied to their
> release version and don't want to split the build into three release roots
> (stuff that plugin depends on; the plugin; stuff that needs the plugin)
>
> I think we should allow this kind of thing with certain very strict bounds,
> but I am happy to push back to a new model version (which would allow
> expressing such stricter bounds) and ok with saying wontfix if we are ok
> potentially alienating the users who feel they need this (could live with a
> way to provide a workaround though)
>
> On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
>
>> I don't think there are really any valid use cases for trying to build an
>> extension where it is used in the same reactor. Extensions really need to
>> be present before the reactor starts and trying to do this is a contortion
>> I really don't want to support.
>>
>> I would like to close this as won't fix. Anyone object?
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> We know what we are, but know not what we may be.
>>
>> -- Shakespeare
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Sent from my phone
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: MNG-1911 -- Close as won't fix
Posted by Stephen Connolly <st...@gmail.com>.
There are quite a number of users who want this functionality and the
corresponding ability to build a plugin from the same reactor as it is
consumed in.
Usually this is due to lazyness, ie not wanting to cut a release of a
plugin/extension just to make the build... Iow the use case were somebody
"would like to write a one off script, but instead does the maven way and
writes a one off plugin/extension"
The other use case is eg openejb/tomee who have a plugin tied to their
release version and don't want to split the build into three release roots
(stuff that plugin depends on; the plugin; stuff that needs the plugin)
I think we should allow this kind of thing with certain very strict bounds,
but I am happy to push back to a new model version (which would allow
expressing such stricter bounds) and ok with saying wontfix if we are ok
potentially alienating the users who feel they need this (could live with a
way to provide a workaround though)
On Sunday, 19 January 2014, Jason van Zyl <ja...@takari.io> wrote:
> I don't think there are really any valid use cases for trying to build an
> extension where it is used in the same reactor. Extensions really need to
> be present before the reactor starts and trying to do this is a contortion
> I really don't want to support.
>
> I would like to close this as won't fix. Anyone object?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
> -- Shakespeare
>
>
>
>
>
>
>
>
>
--
Sent from my phone
Re: MNG-1911 -- Close as won't fix
Posted by Milos Kleint <mk...@gmail.com>.
no, quite the opposite, I will applaud the decision :)
Milos
On Sun, Jan 19, 2014 at 7:36 PM, Jason van Zyl <ja...@takari.io> wrote:
> I don't think there are really any valid use cases for trying to build an extension where it is used in the same reactor. Extensions really need to be present before the reactor starts and trying to do this is a contortion I really don't want to support.
>
> I would like to close this as won't fix. Anyone object?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
> -- Shakespeare
>
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org