On 29/01/2008, Patrick Shea <[EMAIL PROTECTED]> wrote:
>
> I saw that you fixed most of the bugs, Thanks Stuart.
>
> One thing that is still not working great is the lock file. using scp it
> is never removed and on the second pass it refuses to update the repository.
Hi Patrick,
I've added aliases to the plugin parameters, so you can now set them in your
POM:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-obr-plugin</artifactId>
<version>1.2.0-SNAPSHOT</version>
<configuration>
<ignore-lock>true</ignore-lock>
</configuration>
</plugin>
and cleaned up some of the lock code - note that because the wagon component
doesn't allow deletion of remote files the code uses the file-size to
determine if it's
been locked or not (0 bytes == unlocked)
if you still see problems, could you try setting ignore-lock to true and do
a fresh
"deploy", then try again with ignore-lock set to false (the previous deploy
should
have reset the lock file to zero length, so it shouldn't block)
if you still see it block, send me the output from maven + any relevant
settings
HTH
I saw that there's a "ignore-lock" vm parameter but that forces me to add it
> to all my build definitions. Can you add it as a plugin configuration, this
> way we can have if set on the plugin config.
>
> Patrick
>
>
> -----Original Message-----
> From: Stuart McCulloch <[EMAIL PROTECTED]>
> Sent: Friday, January 25, 2008 6:00am
> To: [email protected], [EMAIL PROTECTED]
> Subject: Re: OBR resource uri is wrong...
>
> On 25/01/2008, Patrick Shea <[EMAIL PROTECTED]> wrote:
> >
> > I haven't looked too closely at the code but I don't see why windows
> would
> > be the issue...
>
>
> trust me, I've reviewed the code and this is the issue: it's because the
> file separator character on Windows is '\' whereas the URI file separator
> on *all* platforms is '/' (in fact '\' is a valid non-separator URI
> character)
>
> the PathFile class has code to normalize file paths to URIs and extract
> certain parts, but it's a bit fragile and only works when the path passed
> into it is in a certain form - in this case the path from the deploy goals
> on Windows is not in the right form (it has mixed separators).
>
> On the local repo the uri should be "file://..." and on the remote should
> be
> > something like "http://..."; if using http for the remote repo.
>
>
> yes, unfortunately the PathFile code has kind of evolved over time so it's
> been hard to check it's doing the right thing (another reason to review
> it)
>
> Right?
> >
> > Patrick
> >
> >
> >
> >
> > -----Original Message-----
> > From: Stuart McCulloch <[EMAIL PROTECTED]>
> > Sent: Thursday, January 24, 2008 11:01pm
> > To: [email protected], [EMAIL PROTECTED]
> > Subject: Re: OBR resource uri is wrong...
> >
> > On 25/01/2008, Patrick Shea <[EMAIL PROTECTED]> wrote:
> > >
> > > Unless I don't fully understand, when I deploy my bundle to my maven
> > > remote repository, the repository.xml file still refers to the file in
> > my
> > > local repository.
> > >
> > > So when I try to install my bundle through servicemix runtime it gets
> > the
> > > repository.xml and tries to get the file from the uri that point to
> the
> > > local repo and not the remote...
> > >
> > > Any ideas?
> >
> >
> > this is a known bug, again related to how the PathFile class behaves on
> > Windows:
> >
> > http://issues.apache.org/jira/browse/FELIX-457
> >
> > I'm going to replace that class with some Plexus utilities, as they're
> > more
> > proven.
> >
> > Patrick
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > --
> > Cheers, Stuart
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Cheers, Stuart
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Cheers, Stuart
