Hi,
On 29 Apr 2011, at 01:06, Nicolas Anquetil wrote:
Hummmm, I am not convinced yet :-(
The argument of preservation of behaviour as some strength, but still verveinej is not
infusion.
I was talking about the behavior that Moose relies on. inFusion merely complies to it, and
I would expect other exporters to comply to it as well.
And above all, I believe the proposed behaviour is
more flexible and powerful.
It is not more flexible. I never had the need for this behavior, but I always wanted to
have it nicely portable. As a consequence, I would always have to cd first. This is less
flexible :).
It only constraints us and adds more variables to a situation that is already complex:
explaining people that they have to set the root folder is already problematic without the
extra possibilities.
If you really insist on it, you could provide it as an optional setting (but the default
should be no prefix)?
Cheers,
Doru
You can very simply have the old behaviour just by
doing "cd project-root ; verveinej ."
And you can have full paths, or paths relative to some other place than the project
root.
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Cc: codesite-noreply(a)google.com
Envoyé: Vendredi 29 Avril 2011 00:03:22
Objet: [Moose-dev] Re: Issue 603 in moose-technology: VerveineJ should export relative
paths
Hi Nicolas,
I gave full path as argument, but even if I give relative path I do
not want to see it in the MSE file.
In Moose, we always relate the file anchor path to a root folder.
For example:
verveinej.sh -- Annotations/
results in a path like:
"Annotations/src/layout/SpringUtilities.java"
but, I only want "src/layout/SpringUtilities.java" (without the
trailing "/")
Like that, the model is movable in other locations without a problem
without having to think about how to invoke the parser. It only
depends on the root folder, and this folder can be renamed after the
fact.
We have the same convention in inFusion and it works well. From what
it sounds, you already add this information explicitly in VerveineJ,
so it would not be difficult to take out.
Cheers,
Doru
On 28 Apr 2011, at 23:50, Nicolas Anquetil wrote:
Not sure about this one.
On my computer, it does output relative path.
Only they are not really relative to the input folder, but relative
to the argument you gave to verveinej:
so if you say:
verveinej.sh ../some/path/to/java/project
all path in the file anchors will start with
"../some/path/to/java/project"
I think it is more conveniant because you can still have relative
path if you want, you only need to give them relative when you call
verveinej
and you can also get absolute paths if needed by giving absolute
paths as argument ...
Did you give fullpaths as arguments?
nicolas
----- Mail original -----
De: moose-technology(a)googlecode.com
À: moose-dev(a)iam.unibe.ch
Envoyé: Jeudi 28 Avril 2011 23:40:37
Objet: [Moose-dev] Issue 603 in moose-technology: VerveineJ should
export relative paths
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 603 by tudor.gi...(a)gmail.com: VerveineJ should export
relative
paths
http://code.google.com/p/moose-technology/issues/detail?id=603
Currently, VerveineJ exports the FileAnchors with full path. It
should
export it with the path relative to the input folder.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow."