[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [m2e-users] dependencies in m2e.core
|
Hi Igor,
After corresponding with Pascal R, he requested that I open a bug for
this dependency issue, so I did so:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=363190
Thanks (and inadvance) for addressing this.
Scott
On 10/28/2011 1:51 PM, Scott Lewis wrote:
Hi Igor,
Thanks for the response...see inline below.
On 10/28/2011 11:54 AM, Igor Fedorenko wrote:
see inline
--
Regards,
Igor
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
org.eclipse.search, 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
org.eclipse.search be removed?...and/or isolated in a m2e.core.ui
plugin?
What would be required to get this to happen? Bug/enhancement request,
etc?
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)...in 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 code...as 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.sonatype.plexus.build.incremental.BuildContext;
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.sonatype.plexus.build.incremental.BuildContext;
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:
<extension
point="org.eclipse.m2e.core.projectConfigurators">
<extension
point="org.eclipse.m2e.core.lifecycleMappingMetadataSource">
</extension>
As you can see...no 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,
Scott
_______________________________________________
m2e-users mailing list
m2e-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-users