Hello! I followed your suggestion to use archetype.
It worked with the standard maven structure src/main/*! Seems that maven is able to cope with any project structure and woapplication may be built from maven. WOLips is a different case ant I managed to run the project only by using standard maven structure! Thank you very much for your help! On Tue, Oct 9, 2012 at 10:47 PM, G Brown <[email protected]> wrote: > 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> > > G Brown > [email protected] > > > 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 > > > -- Best Regards, Gintautas Sulskus
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
