[EMAIL PROTECTED] wrote:
+[ ] 4. Change plugin inheritance to be enabled, cumulatively
+
+ -> Alternately, we could inherit all plugins, but only APPLY/EXECUTE the
+ ones where inherit=true...that would keep the phases of the build
+ process essentially unchanged, but could result in quite a bit of
+ useless overhead as we calculate/inject plugin configurations which
+ will not be inherited/used. The problem here is knowing which ones
+ actually were inherited and should have the inherit=true test
+ applied, and which ones are supplying inherit=true|false but were
+ specified at this level.
I think this is the solution. The model inheritence should do what they
do without interference, the lifecycle executor determine what to execute.
The way this could be applied is by having an "applied" flag behind the
scenes. When the model inheritence is assembled, if
<inherit>false</inherit> was given, then it is not inherited at all to
the children. Therefore, its existence in the child indicates that it
was directly given, inherit was true, or inherit was not given. In the
first two cases, during assembly, applied can be set to "true", in the
last case, applied can be set to "false".
When it comes to the lifecycle executor, the test it does is:
if ( mojoDescriptor.isInhertByDefault() || mojo.isApplied() ) {
// bind to the lifecycle
}
Does this make sense?
+
+[ ] 5. Add profiles, defined in POM, ${basedir}/profiles.xml, and settings.xml
+
+ -> Different validation rules for allowed elements in each, to maintain
+ portability.
Not sure what you mean here? The things used in here should be a base
class of Model. ie maven.mdo should have SharedProfileModel
(settings.xml) -> ProfileModel (profiles.xml) -> Model (pom.xml) as the
extends order. I wonder, can maven-settings import part of an mdo, or
will it need to be reproduced? For now, I think the latter, because of
the need to be able to generate the docs, etc properly, but try and
enable it later.
+
+ -> Info in profiles will be applied AFTER all assembly, but BEFORE cli
+ values (what cli values are we using??)
Yes, this is actually done that way anyway. The profiles are like
another inheritence step (I think it happens before interpolation too).
The CLI only comes into affect when resolving expressions, which is done
at runtime.
+
+ -> Profiles can be ordered
+
+ * settings.xml:
+ <activeProfiles><profileId/><profileId/></activeProfiles>
+
+ * profiles.xml:
+ <profiles><profile><id/>..</profile><profile/></profiles>
+
+ * pom.xml: {see profiles.xml}
Yep, lists should suffice, I think the ordering of assembly will make
sure they go in the right order...
+
+[ ] 6. Add --show-profiles execution mode for maven, storage of
+ profiles-in-effect in MavenSession for later access?
I listed this as a nice to have, so unless it costs nothing to do, you
can leave it out for now.
Thanks for this.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
