Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Classifiers and workspace resolution during maven launch 


On 2014-07-26, 18:27, László Váradi wrote:

Hi Igor,

You've said that PluginExecutionFilter and corresponding xml format used
in lifecycle mapping file is probably a good way to implement this. What
do you mean by that?


There is already a way to configure association between maven plugin
execution and actions inside m2e. Since the new extension needs
something very similar, the same configuration format and corresponding
implementation should be used by the new extension implementation too.



Another way can be, if the new extension point classes have  a
"supports" method, and ask with each mojo execution in the package
phase, whether this mojo execution defines classified outputs or not.
And this can be used from both WorkspaceStateWriter and from jdt launch
classpath provider.


This would require activation of the bundles that provides the
extension. For example, if m2e-wtp provides the new extension, m2e-wtp
and wtp would be pretty much activated any time m2e needs to write
WorkspaceStateWriter.

Another benefit of metadata driven extension-to-plugin-execution
mapping, the metadata can be used to implement discovery of required
extension points, the same way m2e currently discovers project
configurators.



However, I can see that this information is rather static, or at least,
bound to the pom.xml state. That's why I think it should be good to
store it somewhere close to MavenProject or IMavenProjectFacade, and can
be calculated at project configuration time, so it would be good to have
this in a project configurator. It configures the project for workspace
artifact resolution... Why is it a bad idea?


We are optimizing for different things, it seems. My goal is to minimize
impact on m2e codebase, to have this feature spread through fewer
classes, so changes to this feature are not affected by changes
elsewhere and vise versa. I do not believe recalculating
artifact-to-location mapping on each java application launch or each
time workspace state file is written will have measurable performance
impact and, more generally, I prefer to optimize for performance only
when I see performance problems.

--
Regards,
Igor



Best regards,

-- Vazul



2014-07-26 9:12 GMT+02:00 Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>:

    I don't like this idea. I think the new extension should only be called
    from workspace state writer and from m2e.jdt classpath provider. I don't
    believe there is a good reason to expose classified-artifact/location
    mapping over IMavenProjectFacade or anywhere else.

    --
    Regards,
    Igor


    On 2014-07-25, 17:59, László Váradi wrote:

        Hi Igor,

        then it is just a simple project configurator implementation.
        The only
        thing that is a little bit frustrating, that we talk about
        plugins bound
        to the package phase, which is not interesting. Anyway, it is
        working,
        and if I change the configuration of such plugin (e.g. a jar plugin
        execution), then m2e will mark the project that it should be updated
        (because the plugin has a configurator associated now). So far,
        its ok.

        My question is how to store the classifier/location map to a
        project? I
        think about to introduce a new method in IMavenProjectFacade to
        register
        a mapping, and the implementation may store it via
        IProject.__setPersistentProperty(). And a getter method, which
        can be used
        in WorkspaceStateWriter, and during java launch.
        What do you think?

        Regarding the IClassifierClasspathProvider, it can fall back to
        the map
        registered in IMavenProjectFacade, if there is no concrete provider
        registered. Maybe, it can be deprecated, but...
        @Fred: BlankClassifierClasspathProvid__er is used to support the
        current
        project. So if a class from test sources are invovled in the launch,
        both test and main classes are populated to the classpath. So
        this is a
        special case. In other cases only one location is mapped.
        Is it ok then, to map one location for a classifier?

        Best regards,

        -- Vazul


        2014-07-23 19:30 GMT+02:00 Igor Fedorenko <igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>
        <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>:


             If the new extension depends on the plugins, then associate
        it with
             plugins. PluginExecutionFilter and corresponding xml format
        used in
             lifecycle mapping file is probably a good way to implement
        this.

             --
             Regards,
             Igor



             On 2014-07-23, 19:04, László Váradi wrote:

                 Hi Igor, Fred,

                 Sorry for the late answer...

                 So if it accepted, I'll create an issue in bugzilla and
        try to
                 create a
                 patch.

                 Before doing so, I have one question:
                 @Igor said that this new extension point should be
        registered for
                 specific packaging types. It is necessary? It depends
        on the
                 plugins, I
                 think, not the packaging. An extension may handle a
        specific plugin.
                 E.g. an extension can handle the jar plugin, another
        the war plugin,
                 another one should be responsible for the ear plugin.
        And I can
                 imagine
                 that a project with ejb packaging has a jar execution
        with a
                 classifier...

                 If we introduce this new extension, than it is not
        necessary to
                 move the
                 workspace state properties file creation.

                 Best regards,

                 -- Vazul




                 2014-07-21 13:57 GMT+02:00 Fred Bricon
        <fbricon@xxxxxxxxx <mailto:fbricon@xxxxxxxxx>
                 <mailto:fbricon@xxxxxxxxx <mailto:fbricon@xxxxxxxxx>>
                 <mailto:fbricon@xxxxxxxxx <mailto:fbricon@xxxxxxxxx>
        <mailto:fbricon@xxxxxxxxx <mailto:fbricon@xxxxxxxxx>>>>:



                      Sorry, I'm in the middle of non-coding activities
        these
                 days (on
                      PTO) that eat most of my brain cycles.

                      Overall, yeah I think a new extension point will
        have to be
                 added,
                      while maintaining the existing
        iclasspathclassifier. I'm not
                      familiar with WorkspaceStateWriter, If the new
        class can
                 completely
                      replace the old one, then we can think about
        deprecating it
                 in 1.6
                      and removing it in m2e 2.0 (no ETA on that).

                      Not sure we can change
                 AbstractClassifierClasspathPro____vider hierarchy

                      to inherit from the new class from core.
        Composition will
                 probably
                      be preferable.


                      On Sun, Jul 20, 2014 at 9:34 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:

                          I really wish Fred would comment here, but
        from my somewhat
                          uneducated
                          point of view classified dependency resolution
        during
                 java app/test
                          launch should be the same as when launching maven
                 build. In both
                          cases
                          classified dependencies should be resolved to
        a filesystem
                          location (or
                          locations).

                          Here is what I would do

                          Introduce new extension point that takes workspace
                 project and
                          returns
                          artifactKey->location(s) map. The extensions
        will be
                 registered for
                          specific packaging types. The default
        implementation will
                          implement the
                          same logic as WorkspaceStateWriter.

                          The new extension will need to be defined in
        m2e.core
                 because it
                          will be
                          used in both in m2e.jdt and m2e.launch.

                          Deprecated existing IClassifierClasspathProvider
                 extension point but
                          still support it.

                          If an artifact is resolved to multiple
        locations, as I
                          understand is the
                          case for some wtp-specific cases, such
        artifact should
                 not be
                          written to
                          workspacestate.properties file. This is
        actually a missing
                          feature in
                          Maven core, but to support it properly would
        need some
                 major
                          changes. I
                          don't think it's worth it, or at least this
        should be
                 handled as a
                          separate enhancement request.

                          I don't mind moving workspacestate.properties
        generation to
                          per-maven
                          launch. It will likely be little faster
        overall, but I
                 don't
                          think the
                          difference will be all that much. I believe
        content of all
                          workspacestate.properties files should be
        exactly the
                 same for
                          the same
                          workspace.

                          --
                          Regards,
                          Igor


                          On 2014-07-18, 11:23, László Váradi wrote:

                              Hi Igor,

                              I just thinking about it again.
                              Yes, I agree, it would be a little bit
        confusing to
                 have two
                              extension
                              points to something similar. But what if
                              MavenRuntimeLaunchSupport
                              generates a temporary properties file for the
                 actual launch?
                              It should
                              use then the already existing extension
        point to
                 gather the
                              list of
                              referenced workspace resolvable
        dependencies, and
                 pass this
                              file instead
                              of the workspaceState.properties file. It
        would
                 work only if
                              the launch
                              is about a workspace artifact, so it won't
        work (I
                 think)
                              for launches
                              initiated from pom.xml files outside of a
        workspace
                 project
                              (I mean,
                              pom.xml not related to a workspace
        project). And
                 another
                              problem is the
                              resolving of plugins in workspace.

                              Another issue is that the
        classifierClasspathProvider
                              extension point is
                              defined in m2e.jdt plugin, not in
        m2e.core, which
                 contains the
                              WorkspaceStateWriter. And it is created with a
                 different
                              view in mind:
                              to support the classpath generation from Maven
                 Dependencies
                              classpath
                              container for a normal java class launch.

                              Maybe it would be better to solve this
        issue from
                 another
                              direction, and
                              give an extension point to get the list of
                 classifiers and
                              output
                              locations for a project, and use this
        information
                 during
                              java launch as
                              well, because it can support maven launch
        at the
                 same time.
                              Or have
                              both, and use this as fallback, if there is no
                              classifierClasspathProvider.
                              My problem with the
        classifierClasspathProvider is
                 that i
                              have to create
                              separate extension for different
        classifiers. In
                 our case,
                              when there
                              are a few classifiers generated with jar
        plugin, it
                 would be
                              enough to
                              have one extension which can analyze jar
        plugin
                 executions,
                              so if
                              somebody defines a new execution with a new
                 classifier, it
                              could work
                              without having to create a new eclipse plugin.

                              The advantage of
        classifierClaspathProvider is that
                 it can
                              register
                              multiple locations for one classifier (as
                              BlankClassifierClasspathProvid______er does).


                              So I think, both extensions are required...

                              However, if you see
        EjbClientClasspathProvider, the
                 main
                              logic can be
                              used to generate entries into workspace
        state file.
                 Or the
                              same for
                              WarClassesClassifierProvider. Both check
        some plugin
                              configuration for
                              the decision, but when a launch is about
        to execute
                 and for
                              a dependent
                              project, and not at project import/update
        time.
                              My suggestion is just to put this logic
        somewhere
                 where the
                              workspace
                              state properties file is generated, to support
                 maven launch,
                              too.

                              Best regards,

                              -- Vazul



                              2014-07-17 15:04 GMT+02:00 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>>>
                              <mailto:igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>
                 <mailto:igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>> <mailto:igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>
                 <mailto:igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>>>>__>__:




                                   I am okay with this idea but I am not
        sure how
                 the new
                              proposed
                                   extension point will align with existing
                              classifierClasspathProviders.
                                   @Fred what do you think?

                                   --
                                   Regards,
                                   Igor



                                   On 2014-07-17, 13:54, László Váradi
        wrote:

                                       Hi Igor, hi all

                                       I just wonder if m2e would
        support this
                 (resolve
                              "classified"
                                       workspace
                                       dependencies during maven launch)
        with a new
                              extension point
                                       definition.
                                       An extension point may got
                 IMavenProjectFacade, and
                              would return
                                       a list
                                       of classifiers and locations, and
                              WorkspaceStateWriter could use
                                       this
                                       list to generate the workspace state
                 properties
                              file. The special
                                       "tests" classifier could be
        handled also
                 by such a
                              class.

                                       In our case, the project has
        multiple jar
                 plugin
                              executions, with
                                       different classifiers. The different
                 executions
                              just differs from
                                       different include and exclude
        patterns.

                                       So we could create our extension
        point to
                 handle
                              this configuration.
                                       Maybe somebody could write an
        extension
                 point for
                              ejb plugin, which
                                       would support the generateClient
        attribute, to
                              setup the ejb-client
                                       classifier for that project, etc...

                                       If this is acceptable, then I
        would be
                 happy to
                              provide a patch.

                                       Best regards,

                                       -- Vazul



                   _______________________________________________________


                                       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>>>
                              <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 <mailto:m2e-dev@xxxxxxxxxxx>>>>


                                       To change your delivery options,
        retrieve your
                              password, or
                                       unsubscribe from this list, visit
        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>>


                 <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>>>


        <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>>

          <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>>>
                              <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 <mailto:m2e-dev@xxxxxxxxxxx>>>>


                                   To change your delivery options,
        retrieve your
                 password, or
                                   unsubscribe from this list, visit
        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>>

                 <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>>>




        <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>>

          <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>>>>




                              --
                              "Tőled tudják, hogy testvérek vagyunk?"
        http://www.youtube.com/watch?______feature=player_detailpage&__v=____qw1R794sutQ#t=2765s
        <http://www.youtube.com/watch?____feature=player_detailpage&v=____qw1R794sutQ#t=2765s>

        <http://www.youtube.com/watch?____feature=player_detailpage&v=____qw1R794sutQ#t=2765s
        <http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s>>


        <http://www.youtube.com/watch?____feature=player_detailpage&v=____qw1R794sutQ#t=2765s
        <http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s>

        <http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s
        <http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s>>>






          _____________________________________________________
                              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>>>
                              To change your delivery options, retrieve your
                 password, or
                              unsubscribe from this list, visit
        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>>

          <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>>>
                          To change your delivery options, retrieve your
        password, or
                          unsubscribe from this list, visit
        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>>

          <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>>>




                      --
                      "Have you tried turning it off and on again" - The
        IT Crowd

                      ___________________________________________________
                      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>>>
                      To change your delivery options, retrieve your
        password, or
                      unsubscribe from this list, visit
        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>>
                 To change your delivery options, retrieve your password, or
                 unsubscribe from this list, visit
        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>>
             To change your delivery options, retrieve your password, or
             unsubscribe from this list, visit
        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>
        To change your delivery options, retrieve your password, or
        unsubscribe from this list, visit
        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>
    To change your delivery options, retrieve your password, or
    unsubscribe from this list, visit
    https://dev.eclipse.org/__mailman/listinfo/m2e-dev
    <https://dev.eclipse.org/mailman/listinfo/m2e-dev>






_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev

Back to the top