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 <stephen.alan.conno...@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.conno...@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 <ja...@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.)
