Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [iam-dev] Allow the user to control which dependencies can be resolved from the workspace

Hi!

Comments inlined.

On Wed, Nov 26, 2008 at 10:23 AM, Allan G. Ramirez <agramirez@xxxxxxxxx> wrote:
Hello,

I stumble on this issue http://code.google.com/p/q4e/issues/detail?id=169 and found out that this will improve the performance of iam. This is a candidate for removing permspace error when importing huge project like archiva.

Can you explain why this change could solve the problems with permgen? I can't see it.
AFAIK, permgen errors are caused by running out of "permanent" memory, where things like class definitions go.
Since we are already loading new class definitions (not from the workspace, but from the jars in the repository), I can't see a benefit.

Maybe we are talking about different things and calling them "resolving from the workspace"? I can see 2 different things at least:
  1. Placing dependencies on JDT classpath (what I've been asumed so far)
  2. Packaging and placing dependencies on maven "classpath".

(btw: a good reference about reducing -not solving- the number of permgen errors is here: http://my.opera.com/karmazilla/blog/2007/03/13/good-riddance-permgen-outofmemoryerror)
 
Candidate because we need to document also that before importing a multi-module project, that project should be installed first in the users repo using the maven cli version of the embedder used in IAM.
Because, I noticed that if you install a project using maven-2.0.9 then you install the same project using maven-2.1-SNAPSHOT, it will still download artifacts.

it would be interesting to have some details as well. I suspect this is caused by maven plug-ins which require a maven version higher than 2.0.9 being downloaded by 2.1-SNAPSHOT.

I have not looked specifically at the problem you describe, but I mix command line 2.0.x and embedded 2.1.x at work and have noticied no problems so far. Will pay more atention now!
 
Which makes me think that if you install ProjectA using maven-2.0.9 and then in eclipse, you import ProjectB that has ProjectA dependency, there is a possibility that ProjectB would error due to missing dependencies in ProjectA since in maven 2.0.8 (i'm not sure if it's 2.0.8 or 2.0.9), plugin versions used are locked down unless specified in pom.

I can't get this paragraph :-). Why would a project fail to resolve a dependency? Has the repository format changed between maven versions? (I don't think so). Also,  the explanation mixes projects and plug-ins, so I might have not undestood it fully.

I also would like to vote to disable workspace dependency by default. In contrast to Abel's last comment in http://groups.google.com/group/q4e-users/browse_thread/thread/935e65e06ee8b848#, q4e would automatically resolve installed artifacts if you add a dependency in pom. So IAM has still big added value :D.

I disagree about disbling it by default, but don't have a strong opinion (the reasons given on the link above still apply). Once it is possible to have it one way or the other, we can ask the user community about the default value for it.

About the added value... maybe it is just my workflow. I don't like to run "mvn install" every time I need to know if some -SNAPSHOT project works with the my changes to a -SNAPSHOT dependency, but I'm perfectly happy with being able to turn it on on my eclipse preferences.

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

Back to the top