Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Maven build with resolve worspace artifacts possible bug

"packaging" does not apply to attached artifacts, as far as I know, but
this is a minor terminology point.

Eclipse does not have a concept similar to "attached artifacts" and each
project is treated as single classpath entry. So when project A depends
of project B, project A's classpath includes all exported class output
folders of project B, including B's test-classes folder. This is likely
the reason why your projects compile inside workspace.

When workspace resolution is enabled for command-line build, m2e
resolves attached artifacts with classifier=tests to target project's
test-classes folder, which is not perfect but works in vast majority of
cases. For other classifiers m2e simply has no way to know contents of
their corresponding attached artifacts.


On 12-05-07 4:03 AM, Stepan Vavra wrote:
Igor thank you for your response!

I'm still not satisfied with the reasoning you wrote because the
resolution works correctly when requested by Eclipse build (in contrary
to your statement that it's not supported at all).
And therefore I'd just like to be clear if the problem I was referring
to was fully understood. You also referred to classifiers but my concern
are different packaging/types.

[When the resolution is ok]
m2e resolves the dependency to attached secondary artifact (with
different packaging) correctly when it is executed by Eclipse as a
normal build (e.g. "Build automatically" is enabled) of the project (I
mean it works when Eclipse itself wants to build the project with such a


[When the resolution is NOT ok]
if i run the the maven script of the project with such a dependency as
Maven build (e.g. from Run as dialog) then m2e resolves the dependency
to attached secondary artifact (with different packaging) incorrectly.
(assuming "Resolve workspace artifacts" option is enabled)

And since it's half working I think it's a bug.
My point is that m2e should resolve the dependency to attached artifacts
(which are different packaging types than the main artifact) in the same
way whether executed as Maven build or by Eclipse itself.

Best regards,

On Sun, May 6, 2012 at 10:20 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    This is expected. Maven project model does not provide enough
    information for m2e to be able to determine contents of project attached
    artifacts in a generic way. We have some hardcoded logic to support
    classifier=tests but can't support other classifiers.


    On 12-05-06 3:08 PM, Stepan Vavra wrote:


        I've found possible bug in the way how m2e resolves workspace
        when running as maven build from run as dialog in Eclipse. And
        I'd like to discuss here if it is really a bug.

        The problem is that if a project A produces secondary artifact
        that is a
        different type (packaging) than the main artifact... then
        project B with
        dependency on the secondary artifact from project A doesn't get the
        dependency resolved into the workspace project but into the local
        This happens when running maven script from Run as Maven build
        with workspace artifact resolution enabled.
        On the other hand it is ok when the build is executed by the Eclipse
        maven builder as a part of Eclipse build.

        To be more verbose:
        1. project A produces 2 artifacts of different types (e.g. war
        as main
        and jar as secondary)
        2. project B has a dependency on secondary artifact from project
        A (e.g.
        on jar artifact from project A)
        3. both projects are imported in Eclipse workspace
        4. open Maven build dialog from Run as dialog of project B
        5. enable the dependency workspace resolution
        6. run any phase (initialize is enough)
        7. when running maven build of project B the secondary artifact of
        project A is not resolved to workspace but into to local repository

        However if the initialize phase of project B is executed by maven
        builder itself (i.e. during the compilation of the workspace) the
        secondary artifact is resolved correctly.

        How to reproduce the problem (each number refers to one step
        from above):
        a) create simple war project A as archetype
        b) add creation of secondary artifact that is different type
        than the
        main one. The easiest way is to enable attach artifact option in war
        plugin which produces jar artifact.


        a) create simple war project B as archetype
        d) add dependency which refers to the 'attach classes' artifact of
        project A (the important part is that the type is jar and not war)
        </dependency> are hopefully clear enough

        a) To get information how dependencies are resolved I used maven
        dependency plugin (to store dependencies paths in properties)
        and gmaven
        plugin (to print those paths on the screen)
        b) to configure the dependency plugin:
        c) to configure the gmaven plugin:
                                         project.dependencies.each() {
                                         identifier =
                                         identifier += it.classifier ==
        null ?
        "" : ":${it.classifier}"
                                         println "${it} resolves to: " +[identifier]

        When such configuration is run as Maven build we can see that the
        dependency points to the local repo instead to the 'target/classes'
        directory of project A
        If I run eclipse with allocated console (e.g. as java) (It is not
        visible in Maven console in Eclipse (the same issue as with
        antrun)) I
        can see in stdout of Eclipse that gmaven outputs correctly resolved
        dependencies to the workspace during the normal build of the
        project B.

        I'm sorry that the formatting of the xml fragments I included is
        probably not nicely indented.

        Thanks for your support!

        Stepan Vavra

        m2e-users mailing list
        m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>

    m2e-users mailing list
    m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>

Stepan Vavra

m2e-users mailing list

Back to the top