Hi Davy,
I'm assuming you meant "file:${basedir}/../../etc"? Using ${basedir}/../../etc gives me a java.net.MalformedURLException: no protocol: ...
Even that doesn't work, however. Not all my projects are at the same depth, and ${basedir} seems to resolve to each project's directory, even though I used it in my parent pom.
To be clear, this is the relevant stuff from my parent pom:
<project>
...
<repositories>
<repository>
<id>myLibs</id>
<layout>p2</layout>
<url>file:../../repos/myLibs</url>
</repository>
</repositories>
...
</project>
I tried <url>${basedir}/../../repos/myLibs</url> as well as <url>file:${basedir}/../../repos/myLibs</url>
Thanks,
-Dave
On Tue, Aug 28, 2012 at 3:51 PM, Davy Meers <davymeers@xxxxxxxxxxx <mailto:davymeers@xxxxxxxxxxx>> wrote:
Hello Dave,
if i understand your case correctly you could use maven properties [1].
The maven property "basedir" points to the directory containing the pom.xml.
Instead of "file:../../etc" try to use "${basedir}/../../etc".
This would ensure it works for your coworkers too.
Regards,
Davy
[1] http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Date: Tue, 28 Aug 2012 10:55:18 -0400
From: dhenderson@xxxxxxxxx <mailto:dhenderson@xxxxxxxxx>
To: tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
Subject: Re: [tycho-user] multiple Tycho modules in one aggregator?
So, a few hours after this, I started having bizarre issues with resolving my repositories, and it turns out the file:../../etc URLs were to blame. I replaced them with fully-qualified URLs, and everything started working again.
Really weird stuff. However, this raises an issue which I think would be pretty common -- I have some dependencies in local p2 repos (stored in source control) which I need to resolve for the build. Obviously, a fully-qualified file: URL won't work, since my coworkers' paths will be totally different. My next approach will be to try to build a URL with the Ant <makeurl/> task and somehow set that as a property before Tycho tries to resolve my p2 repositories. I'm a Maven newbie, so
Let me know if that's a foolish endeavour, or if there's a more reasonable way to do this that I haven't thought of...
Thanks,
-Dave
On Tue, Aug 28, 2012 at 5:39 AM, Oberlies, Tobias <tobias.oberlies@xxxxxxx <mailto:tobias.oberlies@xxxxxxx>> wrote:
This is allright :-) AFAIK, the file: scheme is a bit under-specified, so there might be room for interpretation. Still, I would never use the Java URL class as reference – it’s behaving weird in a lot of corner cases, and it has to stay this way for compatibility reasons.____
__ __
I suspect be observed behaviour comes from p2’s use of their URIUtil, which has yet another idea of what could be interpreted as URL. That tool accepts “file:C:\Temp” as a valid URL, so I wouldn’t be surprised it also likes the relative URLs.____
__ __
Regards____
Tobias____
__ __
*From:*tycho-user-bounces@xxxxxxxxxxx <mailto:tycho-user-bounces@xxxxxxxxxxx> [mailto:tycho-user-bounces@xxxxxxxxxxx <mailto:tycho-user-bounces@xxxxxxxxxxx>] *On Behalf Of *Dave Henderson
*Sent:* Montag, 27. August 2012 14:57
*To:* Tycho user list
*Subject:* Re: [tycho-user] multiple Tycho modules in one aggregator?____
__ __
Hi,____
__ __
I'm new to this conversation (and list), so I hope I'm not misunderstanding or jumping in where I shouldn't...____
__ __
I just ran into a similar issue, and I successfully used a URI that looks like "file:../../etc" as the repository url value. I think that form should be valid, according to the URI RFC (though the wording is open to interpretation in places).____
__ __
I'll note that in Java, new File(URI.create("file:../../foo")) will throw a "not hierarchical" exception, but new URL("file:../../foo").getContent() works just fine. I have no idea how Tycho resolves repository URLs, but perhaps if Java supports relative URLs with schemes, then Tycho might be expected to support them.____
__ __
Thanks,____
-Dave____
On Mon, Aug 27, 2012 at 4:01 AM, Oberlies, Tobias <tobias.oberlies@xxxxxxx <mailto:tobias.oberlies@xxxxxxx>> wrote:____
I am a bit surprised to hear that the file:///../../etc URL is interpreted as relative path at all. This is not correct, because the path component of that URL is "/../../etc" and hence it is absolute (and not pointing to anything reasonable). The only correct way to specify a relative URL is by omitting the scheme (e.g. "../../etc") but I don't think this is currently supported by Tycho.
So to summarize: This is only working by coincidence, and don't blame us if we should need to fix this one day...
Best regards
Tobias
> -----Original Message-----
> From: tycho-user-bounces@xxxxxxxxxxx <mailto:tycho-user-bounces@xxxxxxxxxxx> [mailto:tycho-user- <mailto:tycho-user->
> bounces@xxxxxxxxxxx <mailto:bounces@xxxxxxxxxxx>] On Behalf Of Max Spring
> Sent: Samstag, 25. August 2012 09:05
> To: tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
> Subject: Re: [tycho-user] multiple Tycho modules in one aggregator?
>
> I should have said that site-producer is not a regular Tycho module.
>
> Via exec-maven [1], it pulls a Tycho codebase from a Subversion
> repository,
> applies a patch and builds it with Maven/Tycho [2],
> resulting in the update site which gets consumed by site-consumer.
>
> I guess if Tycho didn't complain about the non-existing file://...
> repository, the profile/module trickery wouldn't be necessary.
>
> (Admittedly, once my patch gets applied to the source Subversion
> repository by the maintainer of the same, my workaround is no longer
> needed.)
>
> -Max
>
> [1] https://github.com/jenkinsci/jenkow-plugin/blob/master/activiti-
> patch/pom.xml#L43
> [2] https://github.com/jenkinsci/jenkow-plugin/blob/master/activiti-
> patch/patch.sh
>
>
> On 08/24/2012 06:08 PM, Igor Fedorenko wrote:
> > Tycho is expected to resolve dependencies among reactor modules
> > directly, without need to publish them in a p2 repository. You should
> > not need site-producer project at all.
> >
> > --
> > Regards,
> > Igor
> >
> > On 12-08-24 7:30 PM, Max Spring wrote:
> >> I have a multi-module POM with two Tycho modules (and other non-Tycho
> >> modules).
> >>
> >> <modules>
> >> <module>site-producer</module>
> >> <module>non-tycho1</module>
> >> <module>site-consumer</module>
> >> <module>non-tycho2</module>
> >> </modules>
> >>
> >> The site-producer module results (among other) in an update site
> >> (package=eclipse-repository).
> >> The site-consumer module wants to use this update site as repository,
> >> via a file:///../../site-producer/target/repository reference.
> >>
> >> With the naive approach, when doing anything in a clean state on the
> >> aggregator, Maven/Tycho complains with
> >>
> >> No repository found at file:/.../target/repository.
> >>
> >> As a workaround, I came up with some profile trickery to have
> >> site-consumer only active if the needed repository is actually there.
> >> Now, this requires running 'mvn package' twice.
> >> Not great.
> >>
> >> Is there a better way to do this?
> >> Thanks!
> >> -Max
> >>
> >> P.S.: The actual project is at https://github.com/jenkinsci/jenkow-
> plugin
> >>
> >> _______________________________________________
> >> tycho-user mailing list
> >> tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
> >> https://dev.eclipse.org/mailman/listinfo/tycho-user
> > _______________________________________________
> > tycho-user mailing list
> > tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/tycho-user
> >
>
> _______________________________________________
> tycho-user mailing list
> tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tycho-user____
__ __
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________ tycho-user mailing list tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx> https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx <mailto:tycho-user@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
