Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iam-dev] Question on the behavior of the builder

Abel Muiño wrote:
I thoght DiffUtils was agnostic regarding the pom structure and it just looked at whatever path you feed it.
Yes it is. I believe DiffUtils.comparePath would check if any of the array of EStructuralFeatures in the second argument can be resolved in the first argument through EObjetct.eGet method.

I also noticed EObject.eGet method works only if you are looking for EReference like Build, testResource but it won't work for EAttribute like Filters. It would throw NPE if you look for EAttribute from EObject.

Since we are just comparing if the second arguments is w/in the first argument, i suggest to use ECoreUtil.isAncestor|(EObject <http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/EObject.html> ancestorEObject, EObject <http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/ecore/EObject.html> eObject). I'm not that sure if it would work. It might work for NPE but I'm not sure what's the other impact if we change some of mike's implementation for DiffUtils.
|



Anyway... do we have a test case and a fix already? (in that order, please... we should make an attempt to fix things just once :D)

On Tue, Mar 10, 2009 at 9:30 AM, Allan Ramirez <agramirez@xxxxxxxxx <mailto:agramirez@xxxxxxxxx>> wrote:

    Hi guys,

    I took a deep look on this problem and found out the cause of NPE.
    When adding a dependency, line 80 (  Object o = obj.eGet( path[i]
    ) ) of DiffUtils is trying to get build and filters from
    dependencies and we all know that dependencies is under build and
    not the other way around.




    Abel Muiño wrote:

        By taking a look at the DiffUtils code, it is checking the
        path given in the second argument.

        In the quoted example, it should be checking if any of the
        modified elements are inside <build><resources>. The path-baed
        search also should make sure that it is not matching a
        dependency exclussion, even when the literal has the same
        value, the parent is not the same.

        This, in theory :)

        I would recommend setting up a few test cases for the
        DiffUtils reproducing the problem (a change in dependencies
        makes the check for changed resources succeed) and continue
        exploring from there.

        Sounds good?

        2009/3/5 Korina Cordero <kcordero@xxxxxxxxx
        <mailto:kcordero@xxxxxxxxx> <mailto:kcordero@xxxxxxxxx
        <mailto:kcordero@xxxxxxxxx>>>


           I have a few questions about the builder, especially in
           ResourceBuilderDelegate.

           In investigating Bug 266034 - NPE in EMF when adding a new
           dependency to the pom, I found out that builder is being called
           once it detected changes in the POM.

           In the method handlePomChange, there is some checking being
        done
           to see if Build Resources, Build Test Resources and Build
        Filters
           were modified.

           If a dependency is added, runTest is set to true, by this
        snippet:

                   if ( DiffUtils.isPathModified( diff.getOwnedElements(),
           new EStructuralFeature[] {
                       PomPackage.Literals.MODEL__BUILD,
           PomPackage.Literals.BUILD__RESOURCES } ) )
                   {
                       runResc = true;
                   }

           This is because the feature ID for BUILD__RESOURCES happens
        to be
           the same as that of DEPENDENCY__EXCLUSIONS.

           Same thing with BUILD__TEST__RESOURCES and
        DEPENDENCY__OPTIONAL.

           But when BUILD__FILTERS is being checked, that's when the NPE
           occurs since BUILD__FILTERS has a feature ID of 13 which is
           non-existent in a Dependency object.

           My question on the builder is:  Is it supposed to compare a
           Dependency or some other modified POM object to a Build
        Resource
           or a Build Test Resource? Maybe it would be better if we
        add some
           checking first if the modified POM object is indeed a Build
           Resource/Build Test Resource/Build Filter before it gets to the
           checking being done in handlePomChange?

           thanks,
           Korina

           _______________________________________________
           iam-dev mailing list
           iam-dev@xxxxxxxxxxx <mailto:iam-dev@xxxxxxxxxxx>
        <mailto:iam-dev@xxxxxxxxxxx <mailto:iam-dev@xxxxxxxxxxx>>

           https://dev.eclipse.org/mailman/listinfo/iam-dev




-- Abel Muiño - http://ramblingabout.wordpress.com/
        ------------------------------------------------------------------------



        _______________________________________________
        iam-dev mailing list
        iam-dev@xxxxxxxxxxx <mailto:iam-dev@xxxxxxxxxxx>
        https://dev.eclipse.org/mailman/listinfo/iam-dev

    _______________________________________________
    iam-dev mailing list
    iam-dev@xxxxxxxxxxx <mailto:iam-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/mailman/listinfo/iam-dev




--
Abel Muiño - http://ramblingabout.wordpress.com/
------------------------------------------------------------------------

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



Back to the top