| You have a totally different project layout than I do. The maven archetype creates a different directory structure.
mvn archetype:generate -DarchetypeCatalog=local
will create that for you.
Theoretically maven should work with any directory structure, but .....I don't know if there are glitches. Also I am using the eclipse 'official' m2e stuff, which keeps getting updated. So if your .project build is specifying org.eclipse.m2e.core.maven2Builder and your classpath is using org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER you have problems. It should be using "org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER.
You could delete the eclipse project, then rename your .classpath, then import a maven project
and the .classpath should be recreated.
Another thing you could do, use
mvn archetype:generate -DarchetypeCatalog=local
to generate a project, and copy your sources, resources, etc to the correct places, then import the maven project into eclipse.
On Oct 9, 2012, at 2:53 PM, Gintautas Sulskus wrote: Thanks for reply, G :)
My .project is identical to yours.
.classpath looks like this: <classpath> <classpathentry kind="src" output="bin" path="Sources"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>
<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> <classpathentry kind="output" path="bin"/>
</classpath>
Where MAVEN2_CLASSPATH_CONTAINER contains all references to the lib in the form of absolute path: /Users/User/.m2/repository/...
Comparing both log files I see on a maven project:
1. Many entries of: - Can't get path when run as jar: ERCoolComponents - Properties - Can't get path when run as jar: ERCoolComponents - Properties.dev - Can't get path when run as jar: ERCoolComponents - Properties.ginga
This is something like ERXFileUtilities which can't work with jars. Check over the properties in those frameworks and put any needed ones in your main property file. It could be a feature, in that it is good to review some of those properties anyway.
2. <com.webobjects.foundation.NSBundle> warning: There is already a unique instance for Bundle named 'JavaWebObjects' at the path + '/Users/User/.m2/repository/com/webobjects/JavaWebObjects/5.4.3/JavaWebObjects-5.4.3.jar'. Skipping the version located at '/System/Library/Frameworks/JavaWebObjects.framework'.
You have it on the classpath twice. You can right click on your project > Maven> disable workspace resolution and now for that project maven will control the classpath. Wolips sort of ignores your classpath, and puts things on it, which are not part of the .classpath. Closing projects will take things out of your classpath usually. Also do this for frameworks.
I am not altogether happy that Wolips takes over without a way to turn that feature off.
My classpath: <classpath> <classpathentry kind="src" output="target/classes" path="src/main/java"> <attributes> <attribute name="optional" value="true"/> <attribute name="maven.pomderived" value="true"/> </attributes> </classpathentry> <classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources"> <attributes> <attribute name="maven.pomderived" value="true"/> </attributes> </classpathentry> <classpathentry kind="src" output="target/test-classes" path="src/test/java"> <attributes> <attribute name="optional" value="true"/> <attribute name="maven.pomderived" value="true"/> </attributes> </classpathentry> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"> <attributes> <attribute name="maven.pomderived" value="true"/> </attributes> </classpathentry> <classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"> <attributes> <attribute name="maven.pomderived" value="true"/> </attributes> </classpathentry> <classpathentry kind="output" path="target/classes"/> </classpath>
Hey,
I used golips 2 weeks ago, it almost worked. I got something called a Null Pointer Exception; whew....never heard of one of those things.. ;>)
After I ripped out the m2e stuff and then updated the m2e stuff then it worked. Some of the parts of eclipse have moved on from February 2012. Eclipse needs to update their release.
Also, even with the project closed, the eomodler complains about the closed ERXExtensions project, so I guess one has to not introduce ANY dependent projects at all.
On Mar 4, 2012, at 11:13 AM, G Brown wrote: HI,
I have a question about the wolips build path. It seems to have some pathology, or I am mis-understanding something.
If I have a project, a projectA and everhthing compiles correctly, then when I bring in a different project to the workspace, e.g. ERXExtensions, now all of a sudden projectA has compile problems. It can't find the classes on the java build path. Somehow it knows about the ERXExtensions project, and it seems it wants to use it, even though the java build path is telling wolips where to find the correct version of ERXExtensions. It doesn't look where the java build path is telling wolips to look. Instead, wolips or the java compiler, can't find ERXExtensions and compilation fails, the java sources are all marked with problems. Now if I close the ERXExtensions project, all of a sudden wolips can find what is on projectA's build path, and all is well.
Of couse projectA depends on a version of ERXExtensions, but why doesn't wolips look at the build path? Is there some parameter to set to get it to use the build path? Is it some automatic feature that if wolips recognizes some classes as being in the workspace, it automatically overrides what is on the build path?
How to stop this?
It does this with a: <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
I have not tried other types of classpathentry.
Thanks,
G Brown
Also, even with the project closed, the eomodler complains about the closed ERXExtensions project, so I guess one has to not introduce ANY dependent projects at all.
On Mar 4, 2012, at 11:13 AM, G Brown wrote: HI,
I have a question about the wolips build path. It seems to have some pathology, or I am mis-understanding something.
If I have a project, a projectA and everhthing compiles correctly, then when I bring in a different project to the workspace, e.g. ERXExtensions, now all of a sudden projectA has compile problems. It can't find the classes on the java build path. Somehow it knows about the ERXExtensions project, and it seems it wants to use it, even though the java build path is telling wolips where to find the correct version of ERXExtensions. It doesn't look where the java build path is telling wolips to look. Instead, wolips or the java compiler, can't find ERXExtensions and compilation fails, the java sources are all marked with problems. Now if I close the ERXExtensions project, all of a sudden wolips can find what is on projectA's build path, and all is well.
Of couse projectA depends on a version of ERXExtensions, but why doesn't wolips look at the build path? Is there some parameter to set to get it to use the build path? Is it some automatic feature that if wolips recognizes some classes as being in the workspace, it automatically overrides what is on the build path?
How to stop this?
It does this with a: <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
I have not tried other types of classpathentry.
Thanks,
G Brown
|