Re: [iam-dev] Inquiry regarding project error behaviors and some other

[Abel Muiño <amuino@xxxxxxxxx>]

Ahh, now I see :D

I think the logic we want is: if the project fails to build, don't try to build again until the user does something to fix it.

I see the benefit of this for big multimodule imports (which is the same logic except for step 1). For single module project creation or import, it would be a "minor anoyance".

However, I thought that Carlos had implemented something already (or maybe I've read too fast?).

All in all.. go ahead with flagging projects as "can't build", but don't do anything specific to project import.

BTW: Related  to "error flag" removal, I've thought of 2 more cases where we want to remove it:
  - User changes settings.xml through our editor (specially if adds/removes mirrors or repositories)
  - Full build (the user might have configured another repository in Archiva and wants the project to rebuild so it picks the dependencies that were previously missing).

2009/3/4 Erle Mantos <emantos@xxxxxxxxx>

2009/3/4 Abel Muiño <amuino@xxxxxxxxx>

I would like to take a step back... I feel I'm lacking context for a meaningful answer :-)

Why do we need to change the current behavior?

I'll give a simple example to be clear. Just let me know if you need any more clarifications.

When you execute our project creation wizard, and create, for example, an appfuse-core
project. These are the usual calls we do on the embedder:

(1) The archetype goal is executed to create the maven project
(2) A goal ( validate ) is executed to get the sorted projects for Import.
(3) MavenJdtNatureDelegate invokes getMavenProject() of MavenProjectManager, which in turn calls the embedder. ResolveTransitively is set to true in this call.
(4) ResourceBuilderDelegate invokes getMavenProject() of MavenProjectManager again, but this time, with resolveTransitively set to false.
(5) If Step 4 is successful, ResourceBuilderDelegate calls a goal ( process-resources and process-test-resources )
(6) MavenClasspathContainer.newClasspath() calls getMavenProject() of MavenProjectManager again.

Now, for the situation, what if Step 3 throws an exception, a missing dependency exception ( It does on mine, with the appfuse-core archetype ),
do we still have to go through Step 4 and Step 5 for that same maven project ? Right now, we still go through all those steps.

From what I observed ( based only on the project creation wizard execution of appfuse-core ), if Step 3 throws an exception, Step 5 also fails. I'm
not sure if this happens always that's why I'm asking. Maybe somebody reading the iam-dev list might have an idea :D

If Step 5 always fail if Step 3 fails, then maybe we could stop at Step 3 when it fails, and not proceed with Step 4, 5 and 6. The way to do that is to
add an error flag in the MavenProjectManager. The performance we can gain might not be very noticeable if we only have a single maven project in the workspace, but imagine if we have many.

I guess what I'm driving at is to not waste anymore embedder calls and their corresponding exception handler execution if we have already detected that the
project has already errors in the first embedder call.

I guess now its time to sleep :D

I'll answer the rest of your questions tomorrow ;)

- Show quoted text -

--
Cheers,

Erle Czar Mantos
Software Engineer | Exist Global | 412-1155 | Skype: emantos | www.exist.com | Innovation Delivered

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

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