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 > <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.) > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
