[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Question about generated ArtifactRepository

Hi Thomas,

Sorry, apparently I missed the part where you specified this was just happening to features. ;)

Matthew


Inactive hide details for Thomas Hallgren ---04/24/2009 09:54:19 AM---Hi Matthew,Thomas Hallgren ---04/24/2009 09:54:19 AM---Hi Matthew,


From:

Thomas Hallgren <thomas@xxxxxxx>

To:

P2 developer discussions <p2-dev@xxxxxxxxxxx>

Date:

04/24/2009 09:54 AM

Subject:

Re: [p2-dev] Question about generated ArtifactRepository




Hi Matthew,
I have checked. I get a .jar that contains the .pack.gz content. Any attempt to open it as a jar fails. Renaming it to .pack.gz and then unpacking it with pack200 succeeds. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273519 for details on how to reproduce this. Please note that I'm not using the mirroring application.

- thomas

Matthew Piggott wrote:
      Hi Thomas,

      In my tests the property
      publishPackFilesAsSiblings isn't set which prevents that method from being accessed. Also I don't see the pack.gz files being written to the jars, they are written to the directory .blobstore Would you be able to check the file sizes to ensure that isn't the case in your test as well?

      Matthew



      Inactive hide details for Thomas Hallgren ---04/23/2009 05:37:26 PM---Hi Matthew,Thomas Hallgren ---04/23/2009 05:37:26 PM---Hi Matthew,

      From:

      Thomas Hallgren <thomas@xxxxxxx>

      To:

      P2 developer discussions <p2-dev@xxxxxxxxxxx>

      Date:

      04/23/2009 05:37 PM

      Subject:

      Re: [p2-dev] Question about generated ArtifactRepository




      Hi Matthew,
      I've done some debugging. While it's true that the source descriptor contains the artifact.reference appointing the .pack.gz, the destination computed from:

      private URI getLocationForPackedButFlatArtifacts(IArtifactDescriptor descriptor) {
      IArtifactKey key = descriptor.getArtifactKey();
      return mapper.map(location, key.getClassifier(), key.getId(), key.getVersion().toString(), descriptor.getProperty(IArtifactDescriptor.FORMAT));
      }

      does not. Not when I copy a feature since there's no pack rule for it in the mapper. So the problem is even worse, I actually copy a .pack.gz into a .jar *without* unpacking it!

      I haven't noticed this earlier since it got overwritten, but that's what happens. I'll add a bugzilla.

      - thomas




      Matthew Piggott wrote:
              Hi Thomas,

              The UpdateSite cheats a little with file locations, if you take a look at the generated artifacts.xml on each artifact there should be a property "
              artifact.reference" with the file location.

              That said, there does appear to be something odd occurring when mirroring from an UpdateSite. Running a test locally it appears that packed files obtained from an UpdateSite are sent into the blobstore which seems a little strange. I'll take a look to see if I can come up with something.

              Matthew

              Inactive hide details for Thomas Hallgren ---04/23/2009 03:43:39 PM---Hi,Thomas Hallgren ---04/23/2009 03:43:39 PM---Hi,

              From:

              Thomas Hallgren
              <thomas@xxxxxxx>

              To:

              P2 developer discussions
              <p2-dev@xxxxxxxxxxx>

              Date:

              04/23/2009 03:43 PM

              Subject:

              [p2-dev] Question about generated ArtifactRepository




              Hi,
              I see some weird behavior when testing my mirroring approach of copying
              the .jar.pack.gz files and regenerating the .jar locally. I debugged and
              nailed it down to this:

              1. My mirroring method finds two IArtifactDescriptors. One with no
              format and one that is 'packed'.
              2. I issue a RawMirroringRequest to copy the packed descriptor.
              3. The unpacked descriptor is copied!
              4. Restoring the .jar now results in an error. "Artifact repository out
              of sync, overwriting ..."

              As it turns out, this is because my source repository is generated from
              a site.xml and it contains these three rules (and no more):

              (& (classifier=osgi.bundle)), ${repoUrl}/plugins/${id}_${version}.jar
              (& (classifier=binary)), ${repoUrl}/binary/${id}_${version}
              (& (classifier=org.eclipse.update.feature)),
              ${repoUrl}/features/${id}_${version}.jar

              I'm missing this one normally present in repositories created with the
              publisher:

              (& (classifier=osgi.bundle) (format=packed)),
              ${repoUrl}/plugins/${id}_${version}.jar.pack.gz

              Well, in fact, I'm missing this one too:

              (& (classifier=org.eclipse.update.feature) (format=packed)),
              ${repoUrl}/plugins/${id}_${version}.jar.pack.gz

              or is it assumed that features are never packed? It wouldn't be much
              gain since they normally don't contain any Java binaries but tools like
              the site optimizer will pack features anyway I think.

              My problem is that I have no way of detecting that this will happen.
              I.e. there's no way of knowing that both ArtifactDescriptors represent
              the same physical artifact since the rules are incomplete. Or is there?
              If so, how do I do that?

              TIA
              - thomas
              _______________________________________________
              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
       
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


GIF image

GIF image