This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
MNG-4224 in M3 introduced AbstractMavenLifecycleParticipant which can be used by build extensions to do various things including affecting the dependency list of a project. While this works for a command-line build via DefaultMaven.doExecute, it seems the IDE's embedder does not run these hooks. Possibly useful for bug #192566.
AFAIK not used by anything else currently other than tycho. IMHO not a defect but enhancement
maven-tiles.zip in https://jira.codehaus.org/browse/MNG-5102 is an example of an interesting use of AMLP which would not be correctly loaded by the IDE today.
I can only imagine this being optional, explicitly enabled by user. we might have no idea whatsoever what being done while loading the project
If the presence of an AMLP among the project's build extensions can be detected - which should be pretty straightforward based on scanning Plexus metadata - load the project without it but show a warning in the GUI. (Status line, and/or badge on project to be included by ProblemReporter.) User should have an easy way to reload the project with the AMLP active, and the option to subsequently "trust" that project, or any project using the same AMLP as identified by class name. (Ideally could run in a sandbox, but that would require various Maven/Aether components such as the repository layer to use AccessController.doPrivileged consistently - so that an AMLP could do things like download a missing artifact to the local repo without having general filesystem write access - and this seems unlikely.)
Created attachment 122686 [details] exceptions thrown by project loading. I've tried to do something along these lines as jesse describes. Detecting the participant is easy and working. Enabling it is a hard nut however. I've tried with tycho, as that's the only commonly used build participant afaik. It appears to be doing something, but doesn't reach far enough. Could be some sort of error on my side, messing with classloaders or maven sessions. the core reason for the failure is in a sense funny: java.lang.RuntimeException: java.lang.IllegalStateException: Nested Equinox instance is not supported. And that's what I feared all along when enabling the build participants, one never knows what code they execute..
http://hg.netbeans.org/core-main/rev/a46360e4889a no execution of external code now happening, experiments with tycho proved it could be disasterous. however at least show that the external participant is there and not executed. At least labels the tycho projects as being problematic
Tycho is probably the pathological worst case; far simpler cases that would load easily might come along, but for now I guess it is rare enough to ignore.
Integrated into 'main-golden', will be available in build *201208040001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a46360e4889a User: Milos Kleint <mkleint@netbeans.org> Log: #204898 figure out if any external build participants are present and show that as a warning.
Any chance this could be re-opened. I am using a simple AbstractMavenLifecycleParticipant that sets the project version and certain dependency versions. Or is there a way to enable it for a certain AMLP
https://netbeans.org/bugzilla/show_bug.cgi?id=269741