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 <rfscho...@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 <mkle...@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 >>> <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 > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- the course of true love never did run smooth ... -- Shakespeare
