Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Project build is not triggered after refresh
Putting existing Maven builder at the first position is out of question, that would be to dangerous. But I think the problem is not just this peculiarity with refresh. We have a big project with a lot of files generated. When Java builder compiles the sources for the first time, it generates many thousands of errors. After that, when sources are generated, it has to rebuild many classes, which were already built in the first step. Not very effective.

Is it possible to have two Maven builders - one before the Java builder and one after - and let connectors decide, where they want to run? Two questions here:
1. Is this idea viable at all?
2. I know that you are busy, how difficult would it be to implement another builder for someone without deep knowledge of m2e?

Another idea, which should be easier to implement: make it possible to configure the position of Maven builder, for example in org.eclipse.m2e:lifecycle-mapping plugin. Developers may then try putting Maven builder first and see if it works for them.



On Mon, Dec 2, 2013 at 3:48 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
I don't remember why m2e adds maven builder last. I don't want to change
the order to workaround what appears to be a bug in eclipse platform.

Maven build on command line usually involved two java compiler
invocations, one for main and another for test classes. It is not
possible to represent this inside workspace without changes to jdt, so
we have to rely on correct incremental build behaviour to do multiple
build rounds to get everything built.

--
Regards,
Igor




On 12/1/2013, 12:54, Aliaksei Lahachou wrote:
As a workaround, I now schedule a job after a full build, which does an
incremental build. It looks good on smaller test projects, I'm going to
test it on bigger projects.

I also tried scheduling a job, which refreshes generated resources. It
works, but does not look as nice as doing an incremental build: even on
small test projects there is a moment, where error markers appear and
disappear, as the sources are recompiled.

Why is Maven builder configured after the Java builder? Isn't it more
logical (at least for code generation cases) to have it before the Java
builder? Are there cases where Maven builder must run after the Java
builder?




On Sun, Dec 1, 2013 at 4:14 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    The list of configurators you have is quite intimidating, so I haven't
    dared to check your test project ;-)

    The problem with antlr test project appears to be a bug in (or my
    misunderstand of) IFolder#refresh. When underlying directory and its
    contents are deleted and recreated directly on filesystem, subsequent
    workspace refresh of the folder does not trigger a build, so jdt builder
    does not know it needs to rebuild the generated sources. You should be
    able to reproduce the problem without m2e, but I have not tried. I
    believe this the sequence of events that lead to the problem

    1 "mvn clean" removes generated sources and class files, the workspace
       is out of sync with filesystem but doesn't know about this yet.
    2 project/clean invokes java builder, which compiles non-generated
       sources and creates error markers about missing generated sources
    3 project/clean invokes m2e builder, which generates sources on
       filesystem and calls IFolder#refresh.

    This should trigger another incremental but does not.

    --
    Regards,
    Igor


    On 12/1/2013, 8:02, Aliaksei Lahachou wrote:

        Hello everyone!

        I have a bunch of connectors [1]. Since some time ago, they are
        used by
        a big team, and I started receiving complaints. I reproduced the
        problem
        with the test project for the cxf-xjc-plugin connector [2]:

        1. Import the project. Everything is fine after import.
        2. Select Project/Clean. At this point, connector deletes generated
        files, refreshes the target folders, generates new files, and
        refreshes
        the target folders again. The generated Java files are correctly
        refreshed and visible in Eclipse, but the incremental build is not
        triggered and the files are not compiled. The DependsOnGenerated
        class,
        which depends on generated Java classes, displays errors like "class
        cannot be resolved to a type" and "import cannot be resolved".
        On rare
        occasions the generated files are recompiled, but in most cases the
        problem is reproducible.
        3. Refresh the project manually. The generated files are
        compiled and
        all errors go away.

        I played a bit with the antlr-maven-plugin connector and one of
        its test
        projects [3]. The problem is not so visible, because it does not
        delete
        generated files on clean. But it's still possible to reproduce:

        1. Do mvn clean in command line.
        2. Do Project/Clean - the files are generated and refreshed, but the
        Sample class has errors.
        3. Refresh the project - errors are gone.

        Tested with Eclipse Kepler and Kepler SR1. Complaints came from
        the team
        working on STS based on Eclipse 3.8. The problem is not
        reproducible if
        Maven Project Builder is configured before the Java Builder, but
        when
        Maven project configuration is updated, Java Builder is put
        again at the
        top.

        I found a bug which may be related [4]. Is this a known problem? Is
        there a workaround for it?

        [1] https://github.com/htfv/m2e-__connectors
        <https://github.com/htfv/m2e-connectors>
        [2]
        https://github.com/htfv/m2e-__connectors/tree/develop/cxf-__xjc/com.github.htfv.m2e.__connectors.cxfxjc.tests/test-__projects/xsdtojava
        <https://github.com/htfv/m2e-connectors/tree/develop/cxf-xjc/com.github.htfv.m2e.connectors.cxfxjc.tests/test-projects/xsdtojava>
        [3]
        https://github.com/tesla/__m2eclipse-antlr/tree/master/__org.sonatype.m2e.antlr.tests/__projects/antlr/antlr-p001
        <https://github.com/tesla/m2eclipse-antlr/tree/master/org.sonatype.m2e.antlr.tests/projects/antlr/antlr-p001>
        [4] https://bugs.eclipse.org/bugs/__show_bug.cgi?id=58649

        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=58649>

        Regards,
        htfv (Aliaksei Lahachou)


        _________________________________________________
        m2e-dev mailing list
        m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
        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>
    https://dev.eclipse.org/__mailman/listinfo/m2e-dev

    <https://dev.eclipse.org/mailman/listinfo/m2e-dev>




_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev

_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev

Back to the top