Okay, thanks for pointing that out. Well, I am trying to see your perspective, but I don't share the sentiment changing scope somehow demotes the reputation of a ZIP file. By it's very nature, it is merely a container. It's nature should be how Maven treats it as default. If a developer wants to add code semantics to it, then changing scope is how that should be accomplished. Scope is always how Maven has controlled how code-related artifacts behave throughout the build phase.
Cheers, Paul On Wed, Aug 17, 2016 at 3:14 PM, Michael Osipov <[email protected]> wrote: > Am 2016-08-17 um 22:05 schrieb Paul Benedict: > >> I am in agreement a ZIP file shouldn't be a "second-class type". I do not >> want that either. However, it seems I may have said something that makes >> you believe I am saying otherwise? Can you please let me know what you saw >> in my explanation? I'd just like to know and make sure we're on the same >> page. Thanks, Michael. >> > > It was actually this statement: > (2) or explicitly set a different scope to make it part of the class path > > All items shall be equal by default unless told otherwise. > > > On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <[email protected]> >> wrote: >> >> Am 2016-08-17 um 21:57 schrieb Paul Benedict: >>> >>> Yes, it is valid for a ZIP to contain class files. However, I don't >>>> believe >>>> Maven should create a bias here for Java. The ZIP file type, in its >>>> objective form, has nothing to do with Java. It just so happens Java >>>> chose >>>> to support that file type as a source of classes. >>>> >>>> As as a consequence, a ZIP file could be either of the two use cases in >>>> a >>>> project.... and MNG-6080 explains how to handle that: >>>> (1) default handling is to treat ZIP files as a mere container >>>> >>>> >>> I agree here. No assumptions shall be made since this is a generic >>> container but it does not mean that it doesn't has be to a second-class >>> type of artifact in the system. >>> >>> >>> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <[email protected]> >>> >>>> wrote: >>>> >>>> Am 2016-08-17 um 19:20 schrieb Paul Benedict: >>>> >>>>> >>>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an >>>>> >>>>>> idea >>>>>> to run by the dev folks here: >>>>>> >>>>>> A ZIP file is a type of resource. A resource artifact gets a new scope >>>>>> to >>>>>> remain in the reactor but does not contribute to the compiling process >>>>>> or >>>>>> runtime environment. It's up to the build to determine how to consume >>>>>> it >>>>>> (via some other mechanism like input into a plugin). But is a ZIP >>>>>> artifact >>>>>> really any different from any other kind of non-functional artifact? >>>>>> What >>>>>> about text files, markdown files, or any other kind of non-code >>>>>> resource >>>>>> you want to share and use? >>>>>> >>>>>> One such thought of mine was people who want to deploy OSS license >>>>>> files. >>>>>> Instead of keeping a static copy in a project for distribution >>>>>> bundling, >>>>>> it >>>>>> could be part of a project dependency and added. I am pretty sure >>>>>> there >>>>>> are >>>>>> Maven plugins specifically built for this -- but are these plugin to >>>>>> workaround the absence of native functionality? >>>>>> >>>>>> So the big philosophical question is... >>>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven >>>>>> "zip" >>>>>> type that should be supported... it should be a new Maven "resource" >>>>>> type >>>>>> that can be any kind of file. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> >>>>>> As per definition, ZIP files can also contain class files. Perfectly >>>>> valid. Additionally, a lot of people are wating for MNG-1683 just like >>>>> you >>>>> and me. I would require to solve this issue first before we continue >>>>> discussion. >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
