-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle bundle folders in VirtualArtifactRepository.transferArtifact #1008
Conversation
} else { | ||
File zipFile = null; | ||
try { | ||
zipFile = File.createTempFile(bundleLocation.getName(), ".jar", null); //$NON-NLS-1$ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use a ZipOutputStream
instead of creating a physical file to open a stream fro it and copy it to the output stream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's better. Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few lines downwards we have used a JarOutputStream
.
Is there a reason for the difference? I wonder if just a ZipOutputStream
would be sufficient down there too?
Looking at JarOutputStream
the main addition to ZipOutputStream
seems to be that it adds a META-INF/MANIFEST.MF
entry and has a special magic-number for zips.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would probably better for them to be consistent.,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JarOutputStream
looks like a good idea, even though I think this is just jared to be extracted right away anyways but consistency is probably key here :-)
The implementation currently assumes all bundles are jars, but bundles from the shared bundle pool may be unpacked as folders. eclipse-pde#962
77df22c
to
77bb7b8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Ed for this fix.
I just have a few minor remarks. Please see them below.
try (InputStream is = new FileInputStream(bundleLocation)) { | ||
is.transferTo(destination); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try (InputStream is = new FileInputStream(bundleLocation)) { | |
is.transferTo(destination); | |
} | |
Files.copy(bundleLocation.toPath(), destination); |
ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/target/VirtualArtifactRepository.java
Show resolved
Hide resolved
I'm merging this now and create a follow-up PR shortly. |
The implementation currently assumes all bundles are jars, but bundles from the shared bundle pool may be unpacked as folders.
#962