I first created it to be included into my "Galileo Builder" tool (which
I'm just about to release). I raised the question here to see if there
was an interest of getting it into P2. If so, I'll submit a patch for
it.
- thomas
Jeff McAffer wrote:
Yup. the approach seems reasonable especially if it is configurable.
is this something you are thinking of putting in now?
Jeff
Thomas Hallgren wrote:
Pascal Rapicault wrote:
What you are suggesting has been mentioned in the past as a
way
to
reduce the bandwidth necessary to mirror. However I personally disagree
with doing this automatically because the processing step introduces
another point of variability that could be the source of problems (for
example imagine that the unpacker you use when you mirror has a bug
that can't be found until runtime).
In my case, it's very likely that the unpacker I use is similar to the
one that will later be used by the consumers of the mirror so it's
actually an advantage if I discover that some files cannot be unpacked
while mirroring. That way, I can fix the problem before I make the
mirror available.
If this is enabled, it has to be done through an explicit end
user
decision.
I agree. It should be configurable.
Also the other thing to be careful is to not create artifacts that were
not in the original repo (e.g. maybe the original repo does not have
the canonical artifact for a given plug-in).
My current implementation checks that. If there's no canonical artifact
in the source, none is created in the mirror.
- thomas
PaScaL
Thomas
Hallgren ---04/13/2009 11:03:12 AM---After some research I concluded
that there was no shrink-wrapped way of doing this. So I created a
After some research I concluded that there was no
shrink-wrapped
way of
doing this. So I created a new class:
public class CanonicalizeRequest extends MirrorRequest {
private IArtifactDescriptor optimizedDescriptor;
private IArtifactDescriptor canonicalDescriptor;
public CanonicalizeRequest(IArtifactDescriptor optimizedDescriptor,
IArtifactDescriptor canonicalDescriptor,
IArtifactRepository targetRepository) {
super(canonicalDescriptor.getArtifactKey(), targetRepository,
null, null);
this.optimizedDescriptor = optimizedDescriptor;
this.canonicalDescriptor = canonicalDescriptor;
setSourceRepository(targetRepository);
}
public void perform(IProgressMonitor monitor) {
setResult(transfer(canonicalDescriptor, optimizedDescriptor,
monitor));
}
}
The mirroring is done by first using a RawMirrorRequest on the
optimized
descriptor, and then using CanonicalizeRequest to unpack (source and
destination both pointing to the target repo). It seems to work well.
Perhaps something to consider as a more generic feature for a mirroring
application?
Regards,
Thomas Hallgren
Thomas Hallgren wrote:
> Let's assume that I have a remote repository that contains two
> descriptors per artifact key, one optimized (pack200) and one
> canonical. I want to mirror this repository to another that later
also
> will be deployed as a remote repository. How do I create a mirror
that
> contains both the optimized and the canonical files? Copying both
from
> a remote location using a RawMirrorRequest doesn't seem very
optimal
> and using a standard MirrorRequest will transfer the optimized
version
> but only store the canonical.
>
> What I would like the mirror request to do is:
> 1. Copy the optimized version over the wire.
> 2. Store the optimized version verbatim.
> 3. Recreate the canonical version from the optimized one and store
> that too.
>
> Has this use-case been considered?
>
> Regards,
> Thomas Hallgren
>
>
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|