Home » Eclipse Projects » Oomph » Variable for .setup file location
| Variable for .setup file location [message #1397941] |
Thu, 10 July 2014 11:24  |
|
Hello,
first of all: Thanks for this great tool! Within a few minutes I could create my first setup.
Now, I'm trying to add a UpdateSite-Archive which I want to contribute with the .setup-File.
My idea is, to add the zip-archived UpdateSite in the folder of the .setup-File and then, add the file as Repository to the P2 Director.
How can I get the path to the .setup-File as a variable?
I thought, ${setup.state.dir} from here would meet the need, but this variable could not be resolved.
Many thanks for any hint.
Regards,
Jo
[Updated on: Thu, 10 July 2014 11:25] Report message to a moderator |
|
|
| Re: Variable for .setup file location [message #1398002 is a reply to message #1397941] |
Thu, 10 July 2014 13:15  |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Joachim,
I suppose what you really want/need is just to be able to specify the
URL/URI as a relative one and have it be resolved against the URI of the
containing resource (like what ResourceCopyTask currently does). That's
significantly trickier with p2 tasks and targlet tasks, because they
merge and will lose information about the origin (containing resource)
of the URLs. But I suppose that during merging and consolidation we
could record that information (i.e., the URI of the resource containing
that original repository URL) via annotations and use that to ensure
that the URL actually passed to p2 is resolved to be absolute should it
arrive in relative form. But your specific case seems further
complicated by the fact that the final URL needs to be jar:<>!/ , though
I suppose we could have special case handling for something like
jar:relative:/My.zip!/. But the form of your repo seems less than ideal
for anyone wanting to install from it; I believe the whole archive needs
to be downloaded by p2 even just to access the metadata.
How do you intend to share your setup with other people? It seems that
to share it, you'd need the *.setup itself at some absolute location
(http or shared file system file:), and if that's the case, you also
know the absolute location of your p2 repository and the folks
installing will be better off with if the repository were not in zipped
form. I.e., p2 can load from I.e., p2 can load from
jar:https://hudson.eclipse.org/oomph/job/integration/lastSuccessfulBuild/artifact/updates/org.eclipse.oomph.site.zip!/
but it's better off loading from
https://hudson.eclipse.org/oomph/job/integration/lastSuccessfulBuild/artifact/updates/.
I suppose it would simpler (for us) if we induced some type of variable
like scope.project.folder.uri and scope.project.resource.uri so you
could just use that, but it does strike me as a bit odd to collocate the
setup and and archive. I'm curious about how you will share this
setup. Could you flesh out the details a bit? And why your choice of a
zipped site?
On 10/07/2014 1:24 PM, Joachim Engelhardt wrote:
> Hello,
>
> first of all: Thanks for this great tool! Within a few minutes I could
> create my first setup.
>
> Now, I'm trying to add a UpdateSite-Archive which I want to contribute
> the .setup-File.
> My idea is, to add the zip-archived UpdateSite in the folder of the
> .setup-File and then, add the file as Repository to the P2 Director.
>
> How can I get the path to the .setup-File as a variable?
>
> I thought, ${setup.state.dir} from
> https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Using_Variables would
> meet the need, but this variable could not be resolved.
>
> Many thanks for any hint.
>
> Regards,
> Jo
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Variable for .setup file location [message #1398665 is a reply to message #1398002] |
Fri, 11 July 2014 11:56 |
|
Hi Ed,
thank you for your comprehensive answer.
Your remarks for my indention are right. Perhaps I have to reconsider some points.
I'll try to comment some of your answer to make my purpose more clear.
Ed Merks wrote on Thu, 10 July 2014 09:15
I suppose what you really want/need is just to be able to specify the URL/URI as a relative one and have it be resolved against the URI of the containing resource (like what ResourceCopyTask currently does).
So I have to have a look at the ResourceCopyTask.
Quote:
I suppose we could have special case handling for something like jar:relative:/My.zip!/. But the form of your repo seems less than ideal for anyone wanting to install from it; I believe the whole archive needs to be downloaded by p2 even just to access the metadata.
You're right. It is better to provide the update site in a normal, not archived form. And of course, this is also possible for us.
Quote:
How do you intend to share your setup with other people? It seems that to share it, you'd need the *.setup itself at some absolute location (http or shared file system file:)
At the moment, the .setup file is shared via SVN repository and will be checked into the file system before performing the setup. If it is possible to load the file from SVN directly, this would also be fine, but as far as I know, Oomph doesn't support SVN repositories so far.
Quote:
, and if that's the case, you also know the absolute location of your p2 repository and the folks installing will be better off with if the repository were not in zipped form.
Yes, I know the absolute location, and I thought about to use a variable for this location which the user sets during the installing process. But this was the origin of the question, to avoid setting paths which are already known.
Quote:
I suppose it would simpler (for us) if we induced some type of variable like scope.project.folder.uri and scope.project.resource.uri so you could just use that, but it does strike me as a bit odd to collocate the setup and and archive. I'm curious about how you will share this setup.
You're right. Perhaps this is not a nice way of contribute the setup and its related files, but I don't know, how to do it better.
Quote:
Could you flesh out the details a bit?
I did my best.
Quote:
And why your choice of a zipped site?
Because I thought this is easier when sharing only the files without any source code management. But as I mentioned, we can also used the unzipped files and using a zipped site was not the main goal for this question.
|
|
|
| Re: Variable for .setup file location [message #1398742 is a reply to message #1398665] |
Fri, 11 July 2014 14:09 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Joachim,
Comments below.
On 11/07/2014 1:56 PM, Joachim Engelhardt wrote:
> Hi Ed,
>
> thank you for your comprehensive answer.
> Your remarks for my indention are right. Perhaps I have to reconsider
> some points.
> I'll try to comment some of your answer to make my purpose more clear.
>
> Ed Merks wrote on Thu, 10 July 2014 09:15
>> I suppose what you really want/need is just to be able to specify the
>> URL/URI as a relative one and have it be resolved against the URI of
>> the containing resource (like what ResourceCopyTask currently does).
>
> So I have to have a look at the ResourceCopyTask.
As a work-around, you could use this to copy the zipped update site to
the local machine, e.g., to ${installation.location|uri}/xyz.jar and
then use jar:${installation.location|uri}/xyz.jar as your update site in
the p2 task. Hmm, the p2 task might end up before your resource copy
task so you could use the advance properties to make the resource copy a
prececessor or the p2 task.
>
> Quote:
>> I suppose we could have special case handling for something like
>> jar:relative:/My.zip!/. But the form of your repo seems less than
>> ideal for anyone wanting to install from it; I believe the whole
>> archive needs to be downloaded by p2 even just to access the metadata.
>
> You're right. It is better to provide the update site in a normal, not
> archived form. And of course, this is also possible for us.
In that case, the "normal" approach of resolving the URI ought to work.
We'd be willing to explore making that work properly...
>
> Quote:
>> How do you intend to share your setup with other people? It seems
>> that to share it, you'd need the *.setup itself at some absolute
>> location (http or shared file system file:)
>
> At the moment, the .setup file is shared via SVN repository and will
> be checked into the file system before performing the setup.
I see. With git we can have a plain text http: link to refer to the
setup. E.g.,
http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup?id=9396bf5522ea398442d6e55e545a9edcba9f6665
Ideally the SVN would provide such a thing as well... The latest
version of Oomph even allows https URIs and will do the authentication.
> If it is possible to load the file from SVN directly, this would also
> be fine, but as far as I know, Oomph doesn't support SVN repositories
> so far.
No, and likely we won't given the prevalence of git in the open source
community. But even for git, we don't use anything git-specific to
access the files in git but rather rely on a web service that makes the
git repo accessible via http:....
>
> Quote:
>> , and if that's the case, you also know the absolute location of your
>> p2 repository and the folks installing will be better off with if the
>> repository were not in zipped form.
>
> Yes, I know the absolute location, and I thought about to use a
> variable for this location which the user sets during the installing
> process. But this was the origin of the question, to avoid setting
> paths which are already known.
So it's different for each user?
>
> Quote:
>> I suppose it would simpler (for us) if we induced some type of
>> variable like scope.project.folder.uri and scope.project.resource.uri
>> so you could just use that, but it does strike me as a bit odd to
>> collocate the setup and and archive. I'm curious about how you will
>> share this setup.
>
> You're right. Perhaps this is not a nice way of contribute the setup
> and its related files, but I don't know, how to do it better.
I'd generally expect there is some shared update site with the same URL
for all users. Either some http/https location or a shared file system
file: location...
>
> Quote:
>> Could you flesh out the details a bit?
>
> I did my best.
>
> Quote:
>> And why your choice of a zipped site?
>
> Because I thought this is easier when sharing only the files without
> any source code management. But as I mentioned, we can also used the
> unzipped files and using a zipped site was not the main goal for this
> question.
I see. Certainly the idea of update sites that are relatively located
to the resource containing the task seems sensible. I'm just having
trouble imagining the scenario where this isn't a fixed absolute URI
that everyone shares...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 21:13:41 GMT 2024
Powered by FUDForum. Page generated in 0.03149 seconds |
] 
Search
Help
Register
Login
Home
