[
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