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

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

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


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



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


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




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




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




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




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



        _________________________________________________
        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