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

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


    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>

        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>




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

_______________________________________________
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



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

Back to the top