lensfield --update fails in my machine
8 views
Skip to first unread message
Pablo Echenique
Aug 19, 2011, 12:52:07 PM8/19/11
to Peter Murray-Rust, Quixote mail list, Jorge Estrada
Hi everybody,
when I issue 'lensfield --update' in my machine, I get
** ERROR: Unable to resolve dependency org.lensfield:org.lensfield:lensfield2-api:jar:0.1.1:compile:0.1.1
Try running with '--update'
The repository system is offline and the requested artifact is not locally available at /Users/pablo/.m2/repository/org/lensfield/lensfield2-api/0.1.1/lensfield2-api-0.1.1.jar
org.lensfield:lensfield2-api:jar:0.1.1
from the specified remote repositories:
(none)
Any ideas?
Best,
Pablo.
Pablo Echenique
Aug 19, 2011, 2:34:23 PM8/19/11
to Peter Murray-Rust, Quixote mail list, Jorge Estrada
Dear everyone,
the error was a stupid one:
due to copy-paste issues, I was using a long dash instead of two normal ones.
Now lensfield updates just fine.
However, I experience an error when I try to use it, which I describe below (all mentioned files are attached):
When I try to parse a Gaussian file called f-15_f-15.log, which sits in a folder 'test', and using convert.lf, it generates a f-15_f-15.raw.cml and a f-15_f-15.cml in which a lot of items seem to be correctly captured... but some error is printed out (included as errorlog.txt).
Any idea what is happening?
Best,
Pablo.
Peter Murray-Rust
Aug 21, 2011, 7:05:28 AM8/21/11
to Sam Adams, Jorge Estrada, quixot...@googlegroups.com
Sam, are you able to help with this?
In the longer term Sam and I have been discussing the cost-benefit of Lensfield and come to the conclusion that we shall not be further developing it.
This means that we need to think about other workflow systems, and this is probably a good thing although it may be painful and there are no absolutely obvious solutions.
* The simplest thing is for people to write Java code or scripts that runs the combination of jobs they need. Downside is that each solution is personal and is poor for maintenance and documentation
* I developed a declarative approach under JUMBO and this worked reasonably well. It allowed jobs to be created as XML files which allows documentation. I stopped using it in favour of Lensfield, but it could be resurrected. It's easier to distribute as it's pure Java.
* use an Open workflow system such as Taverna, KNIME or Galaxy (Python). These have the advantage that they have critical mass, but they are not necessary easily adapted to the precise requirements.
The positive aspect is that JUMBO-converters will increase in critical mass usage and it is extremely modular so should fit under any workflow system. The actual amount of workflow required is not huge.
Carol Goble said "workflows are hard"; there is no trivial solution. I think in the first instance we'll use lightweight approaches with procedural code.
P.--
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
In the longer term Sam and I have been discussing the cost-benefit of Lensfield and come to the conclusion that we shall not be further developing it.
This means that we need to think about other workflow systems, and this is probably a good thing although it may be painful and there are no absolutely obvious solutions.
* The simplest thing is for people to write Java code or scripts that runs the combination of jobs they need. Downside is that each solution is personal and is poor for maintenance and documentation
* I developed a declarative approach under JUMBO and this worked reasonably well. It allowed jobs to be created as XML files which allows documentation. I stopped using it in favour of Lensfield, but it could be resurrected. It's easier to distribute as it's pure Java.
* use an Open workflow system such as Taverna, KNIME or Galaxy (Python). These have the advantage that they have critical mass, but they are not necessary easily adapted to the precise requirements.
The positive aspect is that JUMBO-converters will increase in critical mass usage and it is extremely modular so should fit under any workflow system. The actual amount of workflow required is not huge.
Carol Goble said "workflows are hard"; there is no trivial solution. I think in the first instance we'll use lightweight approaches with procedural code.
P.
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
Reply all
Reply to author
Forward
0 new messages