[infinispan-issues] [JBoss JIRA] (ISPN-2560) Distribution ZIP file polluted

[ https://issues.jboss.org/browse/ISPN-2560?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2560: -------------------------------- Description: There appear to be a lot of files packaged up and archived in various (incorrect and superfluous) places in the ZIP archives. 1. Looking at 5.2.0.Beta4-all.zip, I see: {code} Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf infinispan-core.jar | grep "\.sh" functions.sh importConfig.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ {code} Why are these shell scripts in the JAR file? 2. Also, I see similar things in other JAR files: {code} Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/demos/ec2/infinispan-ec2-demo.jar | grep "\.sh" runEC2Demo-all.sh runEC2Demo-influenza.sh runEC2Demo-nucleotide.sh runEC2Demo-protein.sh runEC2Demo-query.sh runEC2Demo-reader.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ {code} {code} Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/cli-client/infinispan-cli-client.jar | grep "\.sh" ispn-cli.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ {code} 3. I see these in {{/etc/}} which, if I now put {{/etc/}} in my classpath, causes things to break in spectacular ways due to the service loaded picking up incorrect metadata. {code} Multiverse:infinispan-5.2.0.Beta4-all manik $ ls etc/META-INF/services/ org.infinispan.cli.commands.Command org.infinispan.cli.connection.Connector org.infinispan.commands.module.ModuleCommandExtensions org.infinispan.configuration.parsing.ConfigurationParser org.infinispan.distexec.mapreduce.spi.MapReduceTaskLifecycle org.infinispan.distexec.spi.DistributedTaskLifecycle org.infinispan.factories.components.ModuleMetadataFileFinder org.infinispan.lifecycle.ModuleLifecycle Multiverse:infinispan-5.2.0.Beta4-all manik $ {code} 4. Why do we package {{etc/infinispan-query-component-metadata.dat}}? That should be a part of infinispan-query.jar, and not in etc. 5. What is in {{/etc/help}}? Looks like resource files for the CLI, which should really be in one of the CLI jars. Marking this as critical, since this is messy and confusing for users, and can cause breakage when running some demos and makes things very confusing to debug. was: There appear to be a lot of files packaged up and archived in various (incorrect and superfluous) places in the ZIP archives. 1. Looking at 5.2.0.Beta4-all.zip, I see: {code} Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf infinispan-core.jar | grep "\.sh" functions.sh importConfig.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ {code} Why are these shell scripts in the JAR file? 2. Also, I see similar things in other JAR files: {{ Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/demos/ec2/infinispan-ec2-demo.jar | grep "\.sh" runEC2Demo-all.sh runEC2Demo-influenza.sh runEC2Demo-nucleotide.sh runEC2Demo-protein.sh runEC2Demo-query.sh runEC2Demo-reader.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ }} {{ Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/cli-client/infinispan-cli-client.jar | grep "\.sh" ispn-cli.sh Multiverse:infinispan-5.2.0.Beta4-all manik $ }} 3. I see these in {{/etc/}} which, if I now put {{/etc/}} in my classpath, causes things to break in spectacular ways due to the service loaded picking up incorrect metadata. {{ Multiverse:infinispan-5.2.0.Beta4-all manik $ ls etc/META-INF/services/ org.infinispan.cli.commands.Command org.infinispan.cli.connection.Connector org.infinispan.commands.module.ModuleCommandExtensions org.infinispan.configuration.parsing.ConfigurationParser org.infinispan.distexec.mapreduce.spi.MapReduceTaskLifecycle org.infinispan.distexec.spi.DistributedTaskLifecycle org.infinispan.factories.components.ModuleMetadataFileFinder org.infinispan.lifecycle.ModuleLifecycle Multiverse:infinispan-5.2.0.Beta4-all manik $ }} 4. Why do we package {{etc/infinispan-query-component-metadata.dat}}? That should be a part of infinispan-query.jar, and not in etc. 5. What is in {{/etc/help}}? Looks like resource files for the CLI, which should really be in one of the CLI jars. Marking this as critical, since this is messy and confusing for users, and can cause breakage when running some demos and makes things very confusing to debug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira