Hi Jianwu, make sure you're in the ptII-swt directory. that error occurs when you run maven in a directory that doesn't have a pom.xml the os info should be fine for the original pom.
On Tue, Jul 8, 2008 at 5:19 PM, Jianwu Wang <[EMAIL PROTECTED]> wrote: > Hi Tristan, > > Thanks for your great work. I tried to follow your steps, but get the > following error. I changed the pom.xml according to the mvn --version info > (deleting other profile and add os name). But still failed. Any comments? > > D:\Kepler\repository\hydrant>mvn --version > Maven version: 2.0.8 > Java version: 1.5.0_15 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > > D:\Kepler\repository\hydrant>mvn compile exec:exec -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'exec'. > [INFO] > ------------------------------------------------------------------------ > [INFO] Building Maven Default Project > [INFO] task-segment: [compile, exec:exec] > [INFO] > ------------------------------------------------------------------------ > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD ERROR > [INFO] > ------------------------------------------------------------------------ > [INFO] Cannot execute mojo: resources. It requires a project with an > existing po > m.xml, but the build is not using one. > [INFO] > ------------------------------------------------------------------------ > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Cannot execute > mojo: res > ources. It requires a project with an existing pom.xml, but the build is > not usi > ng one. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot execute > mojo: > resources. It requires a project with an existing pom.xml, but the build is > not > using one. > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:373) > > Best wishes > > Sincerely yours > > Jianwu [EMAIL PROTECTED] > > Post-Doctor > Scientific Workflow Automation Technologies (SWAT) Laboratory > San Diego Supercomputer Center > University of California, San Diego > San Diego, U.S.A. > > > > Tristan King wrote: > > Hi All, > > I've modified how my prototype works and built an example extension that > demos how easy it is to build new a new view for actor outputs. > > I now use one generic IOFactory which uses spring to load the output > "devices". the spring config to use is passed in as a system property so it > can be easily changed. > > I have built console output in as the default for which i've built a text > output device and a graph output device, and modified the Display, XYPlotter > and TimedPlotter actors to take advantage of these (note that this required > breaking a lot of other code that depends on the XYPlotter and TimedPlotter > actors). > > Today I built a text output device which opens up a SWT window to display > text in. It is in it's own maven project and doesn't require that you have > the ptII source on your system as the ptII jar (my actorio version) and all > it's dependencies are stored in a maven repository. This small package works > on linux and windows, but i'm having trouble with the macosx swt libraries. > It's not bug free, but i think it's a good proof-of-concept. > > to play with this: > * install maven http://maven.apache.org/download.html > * install git (http://code.google.com/p/msysgit/ works great on windows) > * clone ptII-swt (git clone git://git.hpc.jcu.edu.au/jc124742/ptII-swt.git > ) > (the above two steps can be skipped by downloading the latest snapshot > from http://www.hpc.jcu.edu.au/git/?p=jc124742/ptII-swt.git;a=summary) > * compile and run using maven "mvn compile exec:exec" (this will take a > while the first time as maven has to download all the dependencies) > * make/load a workflow that uses the display actor and run it. > > If it has compile errors on the maven step, please run the command > mvn --version > and send me the results (if you feel technical, you can find the activation > section in the pom.xml file and fix up the os info to match the results from > mvn --version) > > And if you feel like playing, you can edit the properties in > src/main/resources/au/edu/jcu/eresearch/ptolemy/swt/spring-confix.xml to > modify the default width and height of the window (requires mvn compile > exec:exec again to apply the changes). > > Comments? > > Cheers > -Tristan > > On Thu, Jul 3, 2008 at 2:42 PM, Tristan King <[EMAIL PROTECTED]> > wrote: > >> I've started doing a bit of work on building an actor IO package ( >> ptolemy.actor.io) >> >> The purpose of this is to provide user input and output for actors so that >> the actors themselves don't have to be responsible for how they get user >> input, or how output is displayed. This will help to build actors that are >> useable in gui and headless environments without having to have modified >> actors for each situation. >> >> I've built a simple prototype which uses an IO factory which >> is embedded in the Manager (since all actors can get access to the manager >> which controls them). When an actor requires an IO "device" it makes a >> request to the IO factory which returns an instance of the desired "device". >> For example, the Display actor requests a Text-based output device. This >> device implements a standard text based output device interface which has a >> write(String) function, and all the Display actor has to do is "write" the >> text to the device which handles how to display it. I've used spring >> to instantiate the correct IOFactory so that in the case of vergil, each >> manager is loaded with a ptolemy.vergil.io.VergilIOFactory and if vergil is >> not used the manager defaults to a ptolemy.actor.io.HeadlessIOFactory. >> >> My work is currently stored in my ptII git mirror, in a branch which has >> been converted for maven compilation. >> If you want to clone the whole repository here are the git commands to >> clone the repository and to get to the branch (this will take a while): >> >> git clone git://git.hpc.jcu.edu.au/jc124742/ptII.git >> git checkout -b actorio origin/actorio >> >> or you can download the current snapshot of the branch (which is about >> 35mb) from: >> >> http://www.hpc.jcu.edu.au/git/?p=jc124742/ptII.git;a=shortlog;h=refs/heads/actorio >> you can then run it by doing: >> >> mvn compile # compiles the code, may take a while the first time while >> maven sorts out it's dependencies >> mvn exec:exec # starts vergil >> >> then fire up any workflow while uses a Display actor. Note that i'm >> rubbish with swing and some of the window placing/sizing functionality has >> been removed to facilitate the separation of the actor from the >> visualisation, so the display window isn't nearly as good as the old one. If >> you start the workflow using MoMLSimpleApplication (i.e: >> >> mvn compile >> java -cp >> target/classes:$HOME/.m2/repository/org/springframework/spring-context/2.0.8/spring-context-2.0.8.jar:$HOME/.m2/repository/org/springframework/spring-beans/2.0.8/spring-beans-2.0.8.jar:$HOME/.m2/repository/org/springframework/spring-core/2.0.8/spring-core-2.0.8.jar:$HOME/.m2/repository/log4j/log4j/1.2.15/log4j-1.2.15.jar:$HOME/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar >> ptolemy.actor.gui.MoMLSimpleApplication ../test.xml >> >> ) it will print the output of any Display actors to the console. >> >> If other people want to work on this, I will create a new branch for it on >> the ptolemy II svn (it requires a few changes to the core of ptolemy so i'm >> not gonna commit it to the trunk) and put it there in makefile building >> mode. >> >> So, is anyone else interested in this? I think it's a key component in >> making kepler available in multiple environments. But it's a big change, >> much too big to be left up to one person. I would feel a lot more >> comfortable with a bunch of people telling me my ideas and designs are >> rubbish and help me build a good system rather than to build something that >> no one but me wants to use. >> >> Things that need to be done: >> * My factory idea and prototype architecture needs to be criticised. >> * Types of "devices" need to be defined (i.e. text output, image output, >> file output, graph output, etc) >> * IO Factory and device interfaces need to be defined. >> * Existing actors need to be modified to use the factory. >> * standard factory implementations need to be written (i.e. I'm rubbish at >> swing and thus someone else should do the vergil factory). >> >> Comments? Ideas? Criticisms? >> Cheers >> -Tristan >> >> -- >> Tristan King >> Research Officer, >> eResearch Centre >> James Cook University, Townsville Qld 4811 >> Australia >> >> Phone: +61747816902 >> E-mail: [EMAIL PROTECTED] www: http://eresearch.jcu.edu.au > > > > > -- > Tristan King > Research Officer, > eResearch Centre > James Cook University, Townsville Qld 4811 > Australia > > Phone: +61747816902 > E-mail: [EMAIL PROTECTED] www: http://eresearch.jcu.edu.au > > ------------------------------ > _______________________________________________ > Kepler-dev mailing [EMAIL > PROTECTED]://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev > > -- Tristan King Research Officer, eResearch Centre James Cook University, Townsville Qld 4811 Australia Phone: +61747816902 E-mail: [EMAIL PROTECTED] www: http://eresearch.jcu.edu.au