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

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


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

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




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




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

    _______________________________________________
    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




--
"Tőled tudják, hogy testvérek vagyunk?"
http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s



_______________________________________________
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