[JBoss JIRA] (SHRINKWRAP-480) Fix order of entries in exported zip file
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-480?page=com.atlassian.jira.pl... ]
Aslak Knutsen updated SHRINKWRAP-480:
-------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/95
> Fix order of entries in exported zip file
> -----------------------------------------
>
> Key: SHRINKWRAP-480
> URL: https://issues.jboss.org/browse/SHRINKWRAP-480
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: impl-base
> Affects Versions: 1.2.2
> Reporter: Stefan Bunciak
> Assignee: Michal Matloka
> Fix For: 1.2.3
>
> Attachments: jdk7-8.png
>
>
> ZipExporter from ShwinkWrap 1.0.1 created zip file with the following structure:
> {code}
> Archive: s-ramp-exporter.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/
> 3847 Defl:N 898 77% 03-31-2014 13:36 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/sramp/
> 1881 Defl:N 875 54% 03-31-2014 13:36 21ed2654 org/jboss/arquillian/container/sramp/DeploymentTest.class
> -------- ------- --- -------
> 5728 1787 69% 9 files
> {code}
> Newer versions on ShrinkWrap gave me:
> {code}
> Archive: s-ramp-resource.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 3847 Defl:N 898 77% 03-30-2014 17:45 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/
> 1790 Defl:N 842 53% 03-30-2014 17:45 7a7ed211 org/jboss/arquillian/container/sramp/DeploymentTest.class
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/sramp/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/
> -------- ------- --- -------
> 5637 1754 69% 9 files
> {code}
> Would it be possible to provide users with both exporting mechanisms (single & multi threaded)? By default use the multi-threaded approach.
> I assume this behavior is result of https://issues.jboss.org/browse/SHRINKWRAP-434. It's not against ZIP standard, afaik, however due to such structure I had to revert to older version of ShrinkWrap (I need zip file for further processing by 3rd party library)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKWRAP-480) Fix order of entries in exported zip file
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-480?page=com.atlassian.jira.pl... ]
Aslak Knutsen updated SHRINKWRAP-480:
-------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
pushed upstream https://github.com/shrinkwrap/shrinkwrap/commit/17f15f7b5ea1266b6ab9951db...
> Fix order of entries in exported zip file
> -----------------------------------------
>
> Key: SHRINKWRAP-480
> URL: https://issues.jboss.org/browse/SHRINKWRAP-480
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: impl-base
> Affects Versions: 1.2.2
> Reporter: Stefan Bunciak
> Assignee: Michal Matloka
> Fix For: 1.2.3
>
> Attachments: jdk7-8.png
>
>
> ZipExporter from ShwinkWrap 1.0.1 created zip file with the following structure:
> {code}
> Archive: s-ramp-exporter.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/
> 3847 Defl:N 898 77% 03-31-2014 13:36 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/sramp/
> 1881 Defl:N 875 54% 03-31-2014 13:36 21ed2654 org/jboss/arquillian/container/sramp/DeploymentTest.class
> -------- ------- --- -------
> 5728 1787 69% 9 files
> {code}
> Newer versions on ShrinkWrap gave me:
> {code}
> Archive: s-ramp-resource.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 3847 Defl:N 898 77% 03-30-2014 17:45 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/
> 1790 Defl:N 842 53% 03-30-2014 17:45 7a7ed211 org/jboss/arquillian/container/sramp/DeploymentTest.class
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/sramp/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/
> -------- ------- --- -------
> 5637 1754 69% 9 files
> {code}
> Would it be possible to provide users with both exporting mechanisms (single & multi threaded)? By default use the multi-threaded approach.
> I assume this behavior is result of https://issues.jboss.org/browse/SHRINKWRAP-434. It's not against ZIP standard, afaik, however due to such structure I had to revert to older version of ShrinkWrap (I need zip file for further processing by 3rd party library)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKWRAP-480) Fix order of entries in exported zip file
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-480?page=com.atlassian.jira.pl... ]
Aslak Knutsen updated SHRINKWRAP-480:
-------------------------------------
Fix Version/s: 1.2.3
> Fix order of entries in exported zip file
> -----------------------------------------
>
> Key: SHRINKWRAP-480
> URL: https://issues.jboss.org/browse/SHRINKWRAP-480
> Project: ShrinkWrap
> Issue Type: Feature Request
> Components: impl-base
> Affects Versions: 1.2.2
> Reporter: Stefan Bunciak
> Assignee: Michal Matloka
> Fix For: 1.2.3
>
> Attachments: jdk7-8.png
>
>
> ZipExporter from ShwinkWrap 1.0.1 created zip file with the following structure:
> {code}
> Archive: s-ramp-exporter.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/
> 3847 Defl:N 898 77% 03-31-2014 13:36 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/
> 0 Defl:N 2 0% 03-31-2014 13:36 00000000 org/jboss/arquillian/container/sramp/
> 1881 Defl:N 875 54% 03-31-2014 13:36 21ed2654 org/jboss/arquillian/container/sramp/DeploymentTest.class
> -------- ------- --- -------
> 5728 1787 69% 9 files
> {code}
> Newer versions on ShrinkWrap gave me:
> {code}
> Archive: s-ramp-resource.jar
> Length Method Size Cmpr Date Time CRC-32 Name
> -------- ------ ------- ---- ---------- ----- -------- ----
> 3847 Defl:N 898 77% 03-30-2014 17:45 b04e8666 META-INF/switchyard.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/beans.xml
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/
> 1790 Defl:N 842 53% 03-30-2014 17:45 7a7ed211 org/jboss/arquillian/container/sramp/DeploymentTest.class
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/container/sramp/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 META-INF/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/jboss/arquillian/
> 0 Defl:N 2 0% 03-30-2014 17:45 00000000 org/
> -------- ------- --- -------
> 5637 1754 69% 9 files
> {code}
> Would it be possible to provide users with both exporting mechanisms (single & multi threaded)? By default use the multi-threaded approach.
> I assume this behavior is result of https://issues.jboss.org/browse/SHRINKWRAP-434. It's not against ZIP standard, afaik, however due to such structure I had to revert to older version of ShrinkWrap (I need zip file for further processing by 3rd party library)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ]
Ralf Battenfeld commented on SHRINKDESC-163:
--------------------------------------------
Hi Toby and Bob, can you have a look at: https://github.com/rbattenfeld/descriptors/tree/SHRINKDESC-163
I added to the three module descriptors an interface called WrapperModuleDescriptor<T>. The corresponding implementation class is called: WrapperModuleDescriptorImpl.
As the name indicates, the idea is to wrap, or was at the beginning. I didn't saw a reason for making a base descriptor class. I also couldn't find a reason for making a real base descriptor with all features.
But maybe I am wrong and didn't get all of your points. Just let me know what you think and I will work more on this.
> Deal with descriptors with multiple possible roots better
> ---------------------------------------------------------
>
> Key: SHRINKDESC-163
> URL: https://issues.jboss.org/browse/SHRINKDESC-163
> Project: ShrinkWrap Descriptors
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-8
> Reporter: Toby Crawley
> Assignee: Ralf Battenfeld
>
> When implementing SHRINKDESC-162, I created three different
> descriptors for module.xml ({{ModuleDescriptor}},
> {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to
> the three root elements listed in the xsd ({{module}}, {{module-alias}},
> {{module-absent}}). This works fine if you are generating a module.xml,
> but if you are loading in an existing file, you don't know without
> looking at the file contents to know which type to instantiate.
> It would be swell if there was a way for descriptors to support
> multiple roots and do the correct thing. Or does that already exist
> and I missed it?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ]
Ralf Battenfeld commented on SHRINKDESC-163:
--------------------------------------------
Thanks Bob, I worked over the weekend and I will have something soon. And, I wanted to ask you for your workarounds so we can deliver something similar:-)
I will have a look about your workaround and yes, the solution will provide the common stuff (name and slot).
> Deal with descriptors with multiple possible roots better
> ---------------------------------------------------------
>
> Key: SHRINKDESC-163
> URL: https://issues.jboss.org/browse/SHRINKDESC-163
> Project: ShrinkWrap Descriptors
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-8
> Reporter: Toby Crawley
> Assignee: Ralf Battenfeld
>
> When implementing SHRINKDESC-162, I created three different
> descriptors for module.xml ({{ModuleDescriptor}},
> {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to
> the three root elements listed in the xsd ({{module}}, {{module-alias}},
> {{module-absent}}). This works fine if you are generating a module.xml,
> but if you are loading in an existing file, you don't know without
> looking at the file contents to know which type to instantiate.
> It would be swell if there was a way for descriptors to support
> multiple roots and do the correct thing. Or does that already exist
> and I missed it?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better
by Bob McWhirter (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ]
Bob McWhirter commented on SHRINKDESC-163:
------------------------------------------
I think a combination of adding a super-interface and some smarts around parsing.
Here's how I'm currently working-around:
https://github.com/wildfly-swarm/wildfly-swarm-fraction-plugin/blob/maste...
Basically parse into generic Nodes, inspect the root element, and then wrap that Node tree in the correct descriptor impl.
If we could do something like Descriptors.create( BaseModuleDescriptor.class, ....) which would do what I've done, returning some sub-class of BaseModuleDescriptor (ModuleAliasDescriptor, ModuleDescriptor, whatnot) then I could easily jam them into the same collection with no problem, and instanceof/downcast as necessary to get the actual leaf.
Bonus points if common attributes (name? slot?) could be floated up to the common super interface.
> Deal with descriptors with multiple possible roots better
> ---------------------------------------------------------
>
> Key: SHRINKDESC-163
> URL: https://issues.jboss.org/browse/SHRINKDESC-163
> Project: ShrinkWrap Descriptors
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-8
> Reporter: Toby Crawley
> Assignee: Ralf Battenfeld
>
> When implementing SHRINKDESC-162, I created three different
> descriptors for module.xml ({{ModuleDescriptor}},
> {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to
> the three root elements listed in the xsd ({{module}}, {{module-alias}},
> {{module-absent}}). This works fine if you are generating a module.xml,
> but if you are loading in an existing file, you don't know without
> looking at the file contents to know which type to instantiate.
> It would be swell if there was a way for descriptors to support
> multiple roots and do the correct thing. Or does that already exist
> and I missed it?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ]
Ralf Battenfeld reassigned SHRINKDESC-163:
------------------------------------------
Assignee: Ralf Battenfeld
> Deal with descriptors with multiple possible roots better
> ---------------------------------------------------------
>
> Key: SHRINKDESC-163
> URL: https://issues.jboss.org/browse/SHRINKDESC-163
> Project: ShrinkWrap Descriptors
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-8
> Reporter: Toby Crawley
> Assignee: Ralf Battenfeld
>
> When implementing SHRINKDESC-162, I created three different
> descriptors for module.xml ({{ModuleDescriptor}},
> {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to
> the three root elements listed in the xsd ({{module}}, {{module-alias}},
> {{module-absent}}). This works fine if you are generating a module.xml,
> but if you are loading in an existing file, you don't know without
> looking at the file contents to know which type to instantiate.
> It would be swell if there was a way for descriptors to support
> multiple roots and do the correct thing. Or does that already exist
> and I missed it?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better
by Ralf Battenfeld (JIRA)
[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ]
Ralf Battenfeld commented on SHRINKDESC-163:
--------------------------------------------
I worked a little bit over the weekend. What I see is the following:
* introducing a marker interface feature as configurable entry in the maven-metadata-plugin. Solves Bob's minimal wish. We do have something that allows to put common things together but the issue is that the top level element is already different.
* Introducing a wrapper descriptor wrapping descriptors internally. You can then at least load a file and you get then the right descriptor back. We may can then extend this wrapper with common stuff for all internal descriptors.
Makes this sense for you?
> Deal with descriptors with multiple possible roots better
> ---------------------------------------------------------
>
> Key: SHRINKDESC-163
> URL: https://issues.jboss.org/browse/SHRINKDESC-163
> Project: ShrinkWrap Descriptors
> Issue Type: Feature Request
> Affects Versions: 2.0.0-alpha-8
> Reporter: Toby Crawley
>
> When implementing SHRINKDESC-162, I created three different
> descriptors for module.xml ({{ModuleDescriptor}},
> {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to
> the three root elements listed in the xsd ({{module}}, {{module-alias}},
> {{module-absent}}). This works fine if you are generating a module.xml,
> but if you are loading in an existing file, you don't know without
> looking at the file contents to know which type to instantiate.
> It would be swell if there was a way for descriptors to support
> multiple roots and do the correct thing. Or does that already exist
> and I missed it?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months