Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] dependencies in m2e.core

Hi Igor,

Thanks for the response...see inline below.

On 10/28/2011 11:54 AM, Igor Fedorenko wrote:
see inline


On 11-10-28 1:17 PM, slewis@xxxxxxxxxxxxx wrote:
Hi m2eclipsers,

We're trying to use m2e core (a couple of extension points and some
classes) in a command-line application, and have discovered that at least
in an older version that m2e.core bundle has a dependency on, which has a number of dependencies on UI code
(org.eclipse.ui, swt, jface I think, etc).  For our command-line
application, we don't want all this UI code (for size, load time, etc).

First question:  Is there any way that the m2e.core dependency on be removed?...and/or isolated in a m2e.core.ui plugin?
What would be required to get this to happen?  Bug/enhancement request,

We have not looked at running m2e in headless mode and I am curious to
understand the use case behind this requirement (m2e is about
integration with maven, which is a headless command line tool...)

Sure. The use case is this...we have some tooling (built on Eclipse RCP...but also wanting to run in a command-line mode), that builds our application...using maven. So far, we have been using m2eclipse in our gui RCP app...and now we would like to run the same custom app building operations (which use maven underneath) in a headless command line RCP client. It's possible that we could do without m2eclipse totally on our headless client...if that's the best course then that's what we'll do...but it would be nice for us to be able to reuse our plugins (which currently depend upon m2e non-ui classes and extension points...see below for details about this) both the gui and headless environments, and currently the m2e.core dependency is problematic for the headless client.

Regardless of the use case, I think it is generally a good idea to make
m2e.core independent of eclipse ui and will be willing to review and
apply a patch.

I'm not sure if we have enough knowledge of m2e to do a non-client-breaking refactoring of m2e.core and m2e.runtime on our own...and resources might be an issue as well...but perhaps we could work with you on that.

If download size your main concern, I think it would make sense to
decompose m2e.core even further, in particular, integration with nexus
indexer and archetyper can probably move into their own bundles.

Download size is a concern, and so we would welcome this, but since the Eclipse UI code is so much larger, removing this dependency is our main concern now.

So here are some details on the m2e and maven classes we are importing...along with info about extension points used:

Imported classes:

import org.eclipse.m2e.core.MavenPlugin;
import org.eclipse.m2e.core.embedder.IMavenConfiguration;
import org.eclipse.m2e.core.internal.IMavenConstants;
(IMavenConstants can/should/will be removed from our it's obviously internal).
import org.eclipse.m2e.core.project.IMavenProjectFacade;
import org.eclipse.m2e.core.project.IMavenProjectRegistry;
import org.eclipse.m2e.core.project.IProjectConfigurationManager;
import org.eclipse.m2e.core.project.MavenUpdateRequest;

import org.codehaus.plexus.util.ExceptionUtils;

import org.eclipse.m2e.core.lifecyclemapping.model.IPluginExecutionMetadata;
import org.eclipse.m2e.core.project.configurator.AbstractBuildParticipant;
import org.eclipse.m2e.core.project.configurator.AbstractProjectConfigurator; import org.eclipse.m2e.core.project.configurator.ProjectConfigurationRequest;

import org.eclipse.m2e.core.embedder.IMaven;
import org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant;

import org.apache.maven.plugin.MojoExecution;
import org.codehaus.plexus.util.Scanner;
import org.codehaus.plexus.util.xml.Xpp3Dom;

Extension points

We are currently using these m2e core extension points:



As you can direct references to any *.ui code (mostly core.project, core.project.configurator, core.project.embedder along with some plexus and some maven classes). Some of these can/could also be removed.

Please let us know what you think. For example...if you think it would be easier to simply remove all references to m2e extension points and classes, pointers to appropriate parts of m2e (e.g. the extension point handling code in m2e.core) would be most appreciated.

Thanks again,


Back to the top