Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Project refreshes and rebuilds/autobuilds

What about version ranges? I don't think Maven resolver provides enough
information to be able to distinguish between "depend on this specific
version" vs "depend on these version ranges".

--
Regards,
Igor

On 2014-05-01, 6:15, Anton Tanasenko wrote:
Ok, there is a code at the end of ProjectRegistryManager.refreshPhase2()
which triggers update of all projects that depend on _versionless_ artifact:

     // if our dependencies changed, recalculate everyone who depends on us
     // this is needed to deal with transitive dependency resolution in
maven
     if(oldCapabilities != null && hasDiff(oldRequirements, requirements)) {
       for(Capability capability : oldCapabilities) {

context.forcePomFiles(newState.getDependents(*capability.getVersionlessKey()*,
true));
       }
     }

Can it be safely changed to getDependents(capability, true), which does
an additional version check? I'm concerned about the 'transitive
dependency' part of comment: dependent artifacts might potentially have
the current project's version in omitted/excluded state somewhere in
dependency tree. Do they still need to be refreshed in such case?


On Thu, May 1, 2014 at 12:46 PM, Anton Tanasenko
<atg.sleepless@xxxxxxxxx <mailto:atg.sleepless@xxxxxxxxx>> wrote:


    On Thu, May 1, 2014 at 2:14 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
    <mailto:igor@xxxxxxxxxxxxxx>> wrote:



        On 2014-04-30, 12:49, Anton Tanasenko wrote:

            Hi,

            I'll pop a separate thread on this topic.

            It seems to me that m2e, when it sees a change in project A,
            tries to
            build any project that has A as a dependency irregardless of
            version of
            project A.
            So if I have 10 projects that have A:1.0 as a dependency and
            I make a
            change in project A:1.1-SNAPSHOT, all those projects get
            rebuild.
            Is that an intended behaviour?


        No, this is not expected. Please open a bug with example
        projects and
        exact steps to reproduce the problem. Patch to fix the problem
        is also
        welcome ;-)


    I'll try to debug into details and see what causes that.




            I also observed that, if workspace autobuild is enabled,
            project A
            refresh happens as MavenBuilder tries to obtain
            MavenProjectFacade, and
            if autobuild is disabled, it is refreshed
            as ProjectRegistryRefreshJob.__resourceChange() gets notified.

            I went as far as to add a dirty if clause, which excludes
            pom.xml from
            the list of meta_data files to which
            ProjectRegistryRefreshJob reacts,
            and it effectively did what I really wanted: project gets
            rebuilt as
            soon as autobuild gets enabled (or any other event which
            will try to
            refresh maven project). But I don't know of any side-effects
            this might
            cause.


        As I mentioned in another thread, there are two cases that are not
        covered by builder

        * closed and removed projects. Say you have projects A and B, A
        depends
        on B. Workspace autobuild is off and B is removed from workspace.
        Project A needs to be rebuild next time autobuild is enabled.

        * Project->Build_Project action when autobuild is off. Say you have
        projects A and B, A depends on B. Workspace autobuild is off.
        User makes
        change to B/pom.xml then calls Project->Build_Project for B.
        This will
        build B, resolve B/pom.xml and invalidate any A's project registry
        entries. Project A needs to be rebuild next time autobuild is
        enabled.

    This hack didn't affect PRE_CLOSE and POST_DELETE events, so those
    still do trigger dependency updates when autobuild is off.
    I'll install this in my eclipse and see if it brings any problems
    with it.
    Inline patch:

    diff --git
    a/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
    b/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
    index faa0704..0a2b121 100644
    ---
    a/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
    +++
    b/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
    @@ -31,2 +31,3 @@
      import org.eclipse.core.runtime.OperationCanceledException;
    +import org.eclipse.core.runtime.Path;
      import org.eclipse.core.runtime.Status;
    @@ -195,2 +196,4 @@
          for(IPath path : ProjectRegistryManager.METADATA_PATH) {
    +      if(path.equals(new Path("pom.xml")))
    +        continue;
            IResourceDelta delta = projectDelta.findMember(path);

        --
        Regards,
        Igor



            On Wed, Apr 30, 2014 at 2:28 PM, Igor Fedorenko
            <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
            <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>
            wrote:

                 If dependency resolution performance in m2e is slower
            compared to
                 command line build, this is a bug. Please open a bug
            report and provide
                 example project and steps to reproduce the problem.

                 I think you are looking to introduce a preference to
            honour workspace
                 autobuild state. When enabled, which I think should be
            the new default,
                 m2e will only perform dependency resolution workspace
            build. Current
                 behaviour is implemented in ProjectRegistryManager and
                 ProjectRegistryRefreshJob and the idea is to always
            keep project
                 registry in sync with pom.xml files. The proper
            implementation of the
                 new resolution mode should allow temporary
            inconsistencies in the
                 project registry, which are reconciled during the next
            build. This is
                 actually pretty significant change to m2e, but I don't
            know how much
                 code will have to change without trying.

                 Couple of interesting scenarios to consider. Project is
            closed or
                 deleted from the workspace. Projects that depend on the
            closed/removed
                 projects will need to be re-resolved during the next
            build. Another
                 interesting scenario is when the user builds individual
            projects when
                 autobuild is off. Projects that depend on the projects
            being built may
                 need to be re-resolved when their are built the next time.

                 --
                 Regards,
                 Igor


                 On 2014-04-30, 4:34, Anton Tanasenko wrote:

                     Hi,
                     I'm not sure if it's on the same topic, but at
            least it definitely
                     affects performance part. So here goes:
                     Another great feature would be (and I think it was
            mentioned on
                     m2e-dev
                     or m2e-users a couple of times) is to temporarily
            disable dependency
                     updates on pom modifications.
                     We have a lot of smaller dependency artifacts, and
            when changing
                     version
                     of one of them, I have to wait a considerable
            amount of time
                     before I
                     can do anything to other files in the workspace, be
            it switching
                     branches, or updating poms.
                     Disabling Project -> Build automatically doesn't
            disable dependency
                     updates. It's a huge paint to switch releases of
            5-6 projects.
                     Better
                     way would be disabling m2e doing anything, make any
            workspace
                     modifications, optionally check something using
            faster cmd-line
                     builds
                     and turing m2e back on, triggering single rebuilt
            of all changed
                     projects.
                     I would gladly help with implementing such thing,
            given it doesn't
                     require huge changes to core m2e, and I'd
            definitely need
                     directions.


                     On Wed, Apr 30, 2014 at 4:01 AM, Daniel Johnson
            (danijoh2)
                     <danijoh2@xxxxxxxxx <mailto:danijoh2@xxxxxxxxx>
                     <mailto:danijoh2@xxxxxxxxx
            <mailto:danijoh2@xxxxxxxxx>> <mailto:danijoh2@xxxxxxxxx
            <mailto:danijoh2@xxxxxxxxx>

                     <mailto:danijoh2@xxxxxxxxx
            <mailto:danijoh2@xxxxxxxxx>>>> wrote:

                          Yep. To be honest I haven’t spent much time to
            figure out
                     what is
                          offered
                          by build lifecycle integration, but in our
            current state we
                     do not
                          use it.

                          Thanks,
                          Daniel

                          On 4/29/14, 4:05 PM, "Igor Fedorenko"
            <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
                     <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx>>
                          <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx>>>>

                     wrote:

                           >So, in other words, you only use m2e dependency
                     management and are not
                           >interested in build lifecycle integration,
            did I get this
                     right?
                           >
                           >--
                           >Regards,
                           >Igor
                           >
                           >On 2014-04-29, 18:04, Daniel Johnson
            (danijoh2) wrote:
                           >> Hey Igor,
                           >>
                           >> Sorry, I guess the class path is rebuilt
            automatically.
                     For some
                          reason
                           >>I
                           >> thought this is what updating the project
            configuration
                     was for.
                          I will
                           >> have to watch carefully to see what
            changes cause the
                     project
                           >> configuration out of date error, stay tuned.
                           >>
                           >> As for plugins I ignore, I ignore any that
            cause an
                     error on the
                           >>project!
                           >> However, I always add it to my Eclipse
            preferences
                     instead of to the
                           >> project POM. We have hundreds of
            components that point
                     to a common
                           >>parent
                           >> but are not part of a multi-module build.
            If we add the
                     rules to the
                           >> parent we have to go through and update
            all projects to
                     use the new
                           >>parent
                           >> version, this is certainly something we
            will consider
                     doing.
                          That said,
                           >>I
                           >> agree with you that a user should be
            warned, hence why
                     I support
                           >>changing
                           >> it from an error to a warning.
                           >>
                           >> As for the list of plugins, pretty much
            all the tycho
                     plugins,
                           >> maven-dependency-plugin, maven-help-plugin,
                     maven-enforcer-plugin,
                           >> codehaus's exec-maven-plugin,
            docbkx-maven-plugin,
                          maven-antrun-plugin,
                           >> maven-clean-plugin, many more.
                           >>
                           >> Cheers,
                           >> Daniel
                           >>
                           >> On 4/29/14, 12:50 PM, "Igor Fedorenko"
                     <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
            <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
                          <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx>>>>

                     wrote:
                           >>
                           >>> See inline
                           >>>
                           >>> --
                           >>> Regards,
                           >>> Igor
                           >>>
                           >>> On 2014-04-29, 14:06, Daniel Johnson
            (danijoh2) wrote:
                           >>>> Hello Igor, Max,
                           >>>>
                           >>>> I agree it will be nice to have these
            markers
                     configurable.
                           >>>>
                           >>>> Igor, as for the examples you are
            looking for:
                           >>>>
                           >>>> 1. In my experience it is nice to have
            the project
                     marked in error
                           >>>>when
                           >>>> the POM configuration changes and the
            class path
                     needs to be
                          re-built,
                           >>>> better yet would be an option in
            preferences to
                     automatically
                          update
                           >>>> project configuration when the POM
            configuration
                     changes. I
                          don¹t have
                           >>>> any
                           >>>> example where I don¹t want this flagged
            in error, so
                     maybe
                          others can
                           >>>> speak up here. I certainly don¹t want to
            commit a POM
                     change
                          without
                           >>>> being
                           >>>> sure the code still compiles, and I also
            don¹t want
                     to have to
                          do a
                           >>>> command line build to confirm it.
                           >>>>
                           >>>
                           >>> Can you elaborate on "the class path
            needs to be re-built"
                          part? m2e is
                           >>> supposed to update project classpath
            automatically. If
                     you have
                          to run
                           >>> project configuration update to get
            classpath in sync
                     with pom.xml
                           >>> changes, this may indicate a bug and I'd
            like to
                     understand
                          better when
                           >>> this happens.
                           >>>
                           >>>
                           >>>> 2. As for plugins that are ³not
            covered², this has
                     been an ongoing
                           >>>>issue
                           >>>> for me. I manage our Eclipse install for
            200+
                     developers as
                          well as
                           >>>> being
                           >>>> a developer myself. I would like to see
            that at the
                     very least
                          when a
                           >>>> plugin execution is not covered that we
            have the
                     option to
                          flag it as
                           >>>>a
                           >>>> Œwarning¹, or better yet a preference to
                     automatically ignore ³not
                           >>>> covered² plugins. Several developers are
            not Maven
                     savvy, so
                          when they
                           >>>> check out a project and it immediately
            goes in error
                     because
                          some of
                           >>>>the
                           >>>> plugins are not covered they worry that
            the project
                     is in an
                          unstable
                           >>>> state and they get confused when the
            command line
                     build works
                          fine but
                           >>>> Eclipse shows errors.
                           >>>
                           >>>
                           >>> This is counter-intuitive. I can
            understand how
                     experienced
                          Maven user
                           >>> can decide that some plugins are not
            relevant inside m2e
                          workspace, but
                           >>> I always assumed that it is better to
            warn novice
                     users about any
                           >>> potential problems.
                           >>>
                           >>> Can you give examples of maven plugins
            that you
                     commonly need to
                           >>>ignore?
                           >>>
                           >>> Any reason you don't have these plugins
            ignored in
                     parent pom.xml?
                           >>>
                           >>>
                           >>>
                           >>>> I hope some of this will be helpful to you.
                           >>>>
                           >>>> Regards,
                           >>>> Daniel
                           >>>>
                           >>>>
                           >>>> On 4/29/14, 10:46 AM, "Igor Fedorenko"
                     <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
            <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
                          <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
            <mailto:igor@xxxxxxxxxxxxxx>>>>

                     wrote:
                           >>>>
                           >>>>> Unfortunately, performance improvement
            in m2e 1.5 do
                     not get
                          Eclipse
                           >>>>> IDE
                           >>>>> anywhere close to performance parity
            with command
                     line build,
                           >>>>> especially
                           >>>>> if you consider modern multi-core
            hardware and
                     multi-threaded
                           >>>>>builds. I
                           >>>>> believe fundamental changes to m2e and
            eclipse in
                     general will be
                           >>>>> required to close the performance gap.
                           >>>>>
                           >>>>> I am fine making m2e markers levels
            configurable. We'll
                          probably need
                           >>>>> to
                           >>>>> provide ability to export/import
            workspace-level
                     preferences, but
                           >>>>>lets
                           >>>>> wait for somebody to ask for this first.
                           >>>>>
                           >>>>> Can you give a couple of examples when
            it is safe and
                          desirable to
                           >>>>> ignore out-of-date project configuration?
                           >>>>>
                           >>>>> Can you give a couple of examples when
            it is safe and
                          desirable to
                           >>>>> ignore "not covered" maven plugins?
                           >>>>>
                           >>>>> --
                           >>>>> Regards,
                           >>>>> Igor
                           >>>>>
                           >>>>>
                           >>>>>
                           >>>>>
                           >>>>> On 2014-04-29, 13:11, Max Rydahl
            Andersen wrote:
                           >>>>>> Hey,
                           >>>>>>
                           >>>>>> Over the last few years of maven in
            eclipse I've
                     noticed two
                           >>>>>>repeating
                           >>>>>> complaints being raised.
                           >>>>>>
                           >>>>>> Those two boils down to:
                           >>>>>>
                           >>>>>> 1) maven in eclipse is slow
                           >>>>>>
                           >>>>>> 2) when I import into eclipse my
            project has
                     errors, that
                          does not
                           >>>>>> happen in "name your favourite IDE"
                           >>>>>>
                           >>>>>> #1 the memory fixes in m2e 1.5 and
            some of the
                     wizard workflow
                           >>>>>>changes
                           >>>>>> have helped greatly on - we still can do
                           >>>>>> better there but that is for a
            separate thread.
                           >>>>>>
                           >>>>>> #2 is where I would like to suggest
            that we:
                           >>>>>>
                           >>>>>> A) Makes the level of markers in m2e
            configurable
                     (Error,
                          Warning,
                           >>>>>> Ignore)
                           >>>>>>
                           >>>>>> B) Consider the default level of the
            markers.
                           >>>>>>
                           >>>>>>        - "Project Configuration is not
            uptodate"
                     should IMO be a
                           >>>>>> Warning
                           >>>>>> since it is really often that a change
            in POM actually
                          requires a
                           >>>>>>full
                           >>>>>> project update.
                           >>>>>>        - "Plugin execution not covered by
                     lifecycle" I think
                          should
                           >>>>>>be
                           >>>>>> a
                           >>>>>> Warning too since again most often you
            will not
                     need to do much.
                           >>>>>>
                           >>>>>> We (or rather Fred :) already started
            some of this
                     work on
                           >>>>>>
            https://bugs.eclipse.org/bugs/____show_bug.cgi?id=433776
            <https://bugs.eclipse.org/bugs/__show_bug.cgi?id=433776>


            <https://bugs.eclipse.org/__bugs/show_bug.cgi?id=433776
            <https://bugs.eclipse.org/bugs/show_bug.cgi?id=433776>> - where
                          he also
                           >>>>>> made the handling of the existing
            warning/errors more
                          aligned with
                           >>>>>> standard eclipse warning/error handling.
                           >>>>>>
                           >>>>>> For now this one just deals with A
            from above.
                           >>>>>>
                           >>>>>> What do you think about that ?
                           >>>>>>
                           >>>>>> and is some combination of B something
            you like or just
                          completely
                           >>>>>> opposed ?
                           >>>>>>
                           >>>>>> /max
                           >>>>>> http://about.me/maxandersen
                           >>>>>>
            ___________________________________________________
                           >>>>>> m2e-dev mailing list
                           >>>>>> m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

                           >>>>>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
                           >>>>>>
                           >>>>>
            ___________________________________________________
                           >>>>> m2e-dev mailing list
                           >>>>> m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

                           >>>>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
                           >>>>
                           >>>>
            ___________________________________________________
                           >>>> m2e-dev mailing list
                           >>>> m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

                           >>>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
                           >>>>
                           >>>
            ___________________________________________________
                           >>> m2e-dev mailing list
                           >>> m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

                           >>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
                           >>
                           >>
            ___________________________________________________
                           >> m2e-dev mailing list
                           >> m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

                           >>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
                           >>

             >___________________________________________________
                           >m2e-dev mailing list
                           >m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>


             >https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>


              ___________________________________________________
                          m2e-dev mailing list
            m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>> <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>
                     <mailto:m2e-dev@xxxxxxxxxxx
            <mailto:m2e-dev@xxxxxxxxxxx>>>

            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>




                     ___________________________________________________

                     m2e-dev mailing list
            m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
            <mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
                     <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>

                 ___________________________________________________

                 m2e-dev mailing list
            m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
            <mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
            https://dev.eclipse.org/____mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>

                 <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>



            _________________________________________________
            m2e-dev mailing list
            m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
            https://dev.eclipse.org/__mailman/listinfo/m2e-dev
            <https://dev.eclipse.org/mailman/listinfo/m2e-dev>

        _________________________________________________
        m2e-dev mailing list
        m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
        https://dev.eclipse.org/__mailman/listinfo/m2e-dev
        <https://dev.eclipse.org/mailman/listinfo/m2e-dev>





_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev



Back to the top