Thanks Igor. If I have any more questions I'll raise them there.
On Wed, Feb 5, 2014 at 2:08 PM, Igor Fedorenko <[email protected]> wrote: > There are two aspects of workspace project configuration. There is > static configuration, things like enabled natures, java compiler > settings and the like. Then there is dynamic behaviour, what happens > during workspace build essentially. > > AbstractProjectConfigurator #configure is the place to perform static > configuration, while #getBuildParticipant is for build behaviour. > > AbstractProjectConfigurator is pretty generic and does not directly > provide support for java projects. To participate in java project > configuration a configurator must implement IJavaProjectConfigurator > interface either directly or by subclassing > AbstractSourcesGenerationProjectConfigurator. IJavaProjectConfigurator > is able to participate java project build classpath configuration via > #configureRawClasspath method and Maven Dependencies classpath container > configuration via #configureClasspath method. > > There are actually three ways to participate in workspace java project > configuration. > > The easiest by far, is to let m2e do it all. This only works for maven > plugins that use BuildContext API [1], but if you are in the position to > modify the maven plugin, this is what I generally recommend. > > AbstractSourcesGenerationProjectConfigurator helps "wrap" source code > generation mojos, like ANTLR and JAXB, and make them participate in > Eclipse workspace build. This is relatively low-effort approach and in > most cases subclasses need to provide location of generated sources and > check if sources (re)generation is necessary. > > Direct implementation of IJavaProjectConfigurator is the most involved > and flexible way to configure workspace java projects but I will need to > know your usecase better before I can tell if this is something you > should try to do. > > Also, we try to keep m2e-users for m2e user discussions. Please use > m2e-dev if you have any further questions about m2e extension development. > > [1] https://wiki.eclipse.org/M2E_compatible_maven_plugins > > -- > Regards, > Igor > > > On 2/5/2014, 12:45, Thomas Golden wrote: > >> Norman, thanks for the tips. >> >> So in addition to simply running the Maven plugin goals (i.e. generating >> sources from the relevant Android XML resources) do I also have access >> to other aspects of the Eclipse workspace? For example, I need the >> generated sources output folder to be marked as a source folder in the >> workspace -- I assume there must be some way to do so, since connectors >> like Antlr and JAXB do it, but it's not 100% clear to me which class is >> responsible for that. >> >> >> On Wed, Feb 5, 2014 at 11:57 AM, Norman Cohen <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thomas, >> >> As one who has recently struggled with the (lack of) m2e >> documentation to write my own connector, I feel your pain. >> >> As I understand it, a "connector" is simply a class >> extending org.eclipse.m2e.core.project.configurator. >> MojoExecutionBuildParticipant, >> which you write and hook into the m2e framework as follows: >> >> * You write a class >> >> extending org.eclipse.m2e.core.project.configurator. >> AbstractProjectConfigurator >> and override its getBuildParticipant method to return an >> instance of your build-participant class. >> * In plugin.xml, you use >> >> the org.eclipse.m2e.core.projectConfigurators extension point to >> declare your class as a project configurator and to assign a >> configurator ID to it. >> * In lifecycle-mapping-metadata.xml, you use the configurator ID >> >> to associate the configurator to a particular Maven goal. >> >> The m2e Eclipse plugin registers its class >> org.eclipse.m2e.core.internal.builder.MavenBuilder at the >> org.eclipse.m2e.core.internal.builder.MavenBuilder at this extension >> point, so that MavenBuilder.build() is invoked upon Eclipse >> resource-change events. >> The MavenBuilder.build() method examines the lifecycle mapping to >> determine which build participants should be invoked, and in which >> order. It then iterates over these build participants and, for those >> participants that are “applicable” to the delta of the resource >> change and the kind of build (full or incremental), invokes the >> build method of the build participant. (All participants are >> applicable to a full build. A participant is applicable to an >> incremental build if the resource delta is non-null or the >> participant’s callOnEmptyDelta() method returns true.) >> >> That's just the tip of the iceberg, but perhaps it can get you >> started. >> >> -- >> Norman Cohen >> Cloud Platform developer tools >> Google NYC >> >> >> _______________________________________________ >> m2e-users mailing list >> [email protected] <mailto:[email protected]> >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> >> >> >> >> >> _______________________________________________ >> m2e-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/m2e-users >> >> _______________________________________________ > m2e-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/m2e-users >
_______________________________________________ m2e-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/m2e-users
