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
<[email protected]>:
On Sun, Jan 19, 2014 at 9:09 PM, Jason van Zyl <[email protected]> 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
<[email protected]> wrote:
On Sunday, 19 January 2014, Jason van Zyl <[email protected]> wrote:
On Jan 19, 2014, at 2:13 PM, Stephen Connolly <
[email protected] <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
<[email protected]<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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
