Re: MNG-1683: Zip packaging
Stephen, I don't feel strongly about it but I don't think there is another option. Unlike assembly:single which is used to create multiple distributions, this is about creating an artifact destined to be consumed as a dependency. Correct me if wrong, but Maven artifact types are meant to produce one single/prime artifact, otherwise you have to begin specifying type element on your dependencies. On Dec 17, 2014 1:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote: With regards to the mythical assembly type, just like other artifact types, there is just only one primary artifact. Unlike running assembly:single, which can output multiple files (.zip, .gz, etc.), the output here will be just one artifact. Does anyone disagree with that perspective? If multiple files can still be generated, we'd still have to choose one as the primary, no I would say that there is only one *descriptor* That descriptor could produce multiple formats, .zip and .tar.gz for example But if you feel strongly otherwise... Cheers, Paul On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com javascript:; wrote: I like this approach as well. Having to have an attached artifact to have a zip or tar.gz with a meaningless pom or jar always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org javascript:; wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com javascript:; wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net javascript:; wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though,
Re: MNG-1683: Zip packaging
On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote: Stephen, I don't feel strongly about it but I don't think there is another option. Unlike assembly:single which is used to create multiple distributions, this is about creating an artifact destined to be consumed as a dependency. Correct me if wrong, but Maven artifact types are meant to produce one single/prime artifact, otherwise you have to begin specifying type element on your dependencies. No you have it wrong there. Type defaults to `jar` if unspecified, so you will need to declare a type to consume either the zip or tar.gz The only case I know of where you get away from that is the horrible hack in jenkins plugins where you depend on the jar and the hpi plugin up-interprets the actual type from the resolved pom so that hpi dependencies are linked at runtime and non-hpi dependencies are packaged in WEB-INF/lib Most of the other packaging types produce jar files and use the packaging to determine the lifecycle Having said all that, the *default* descriptor should be just a zip... But if you override the default you can have a descriptor that produces .tar.gz and .tar.bz2 as well as .zip So I would say that the mojo should: * use its default descriptor if none in src/assembly * use the descriptor if one and only one in src/assembly * fail if more than one descriptor in src/assembly unless the user adds config to say which one to use HTH On Dec 17, 2014 1:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org javascript:; wrote: With regards to the mythical assembly type, just like other artifact types, there is just only one primary artifact. Unlike running assembly:single, which can output multiple files (.zip, .gz, etc.), the output here will be just one artifact. Does anyone disagree with that perspective? If multiple files can still be generated, we'd still have to choose one as the primary, no I would say that there is only one *descriptor* That descriptor could produce multiple formats, .zip and .tar.gz for example But if you feel strongly otherwise... Cheers, Paul On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com javascript:; javascript:; wrote: I like this approach as well. Having to have an attached artifact to have a zip or tar.gz with a meaningless pom or jar always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org javascript:; javascript:; wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; javascript:; wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com javascript:; javascript:; wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi
Re: MNG-1683: Zip packaging
Yes, this definitely helps, Stephen. Thanks for your detailed and well-written explanation. I appreciate it much. Cheers, Paul On Wed, Dec 17, 2014 at 9:22 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote: Stephen, I don't feel strongly about it but I don't think there is another option. Unlike assembly:single which is used to create multiple distributions, this is about creating an artifact destined to be consumed as a dependency. Correct me if wrong, but Maven artifact types are meant to produce one single/prime artifact, otherwise you have to begin specifying type element on your dependencies. No you have it wrong there. Type defaults to `jar` if unspecified, so you will need to declare a type to consume either the zip or tar.gz The only case I know of where you get away from that is the horrible hack in jenkins plugins where you depend on the jar and the hpi plugin up-interprets the actual type from the resolved pom so that hpi dependencies are linked at runtime and non-hpi dependencies are packaged in WEB-INF/lib Most of the other packaging types produce jar files and use the packaging to determine the lifecycle Having said all that, the *default* descriptor should be just a zip... But if you override the default you can have a descriptor that produces .tar.gz and .tar.bz2 as well as .zip So I would say that the mojo should: * use its default descriptor if none in src/assembly * use the descriptor if one and only one in src/assembly * fail if more than one descriptor in src/assembly unless the user adds config to say which one to use HTH
Re: MNG-1683: Zip packaging
I like this approach as well. Having to have an attached artifact to have a zip or tar.gz with a meaningless pom or jar always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org java script:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net java script:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org java script:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com java script:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul
Re: MNG-1683: Zip packaging
With regards to the mythical assembly type, just like other artifact types, there is just only one primary artifact. Unlike running assembly:single, which can output multiple files (.zip, .gz, etc.), the output here will be just one artifact. Does anyone disagree with that perspective? If multiple files can still be generated, we'd still have to choose one as the primary, no? Cheers, Paul On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com wrote: I like this approach as well. Having to have an attached artifact to have a zip or tar.gz with a meaningless pom or jar always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org java script:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net java script:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org java script:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the
Re: MNG-1683: Zip packaging
On Wednesday, December 17, 2014, Paul Benedict pbened...@apache.org wrote: With regards to the mythical assembly type, just like other artifact types, there is just only one primary artifact. Unlike running assembly:single, which can output multiple files (.zip, .gz, etc.), the output here will be just one artifact. Does anyone disagree with that perspective? If multiple files can still be generated, we'd still have to choose one as the primary, no I would say that there is only one *descriptor* That descriptor could produce multiple formats, .zip and .tar.gz for example But if you feel strongly otherwise... Cheers, Paul On Tue, Dec 16, 2014 at 11:25 AM, Manfred Moser manf...@mosabuam.com javascript:; wrote: I like this approach as well. Having to have an attached artifact to have a zip or tar.gz with a meaningless pom or jar always seemed a bit weird. manfred Stephen Connolly wrote on 11.12.2014 07:14: either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org javascript:; wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com javascript:; wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net javascript:; wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; java script:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; java script:; wrote: I don't think that the zip package type should be
Re: MNG-1683: Zip packaging
Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-1683: Zip packaging
Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: MNG-1683: Zip packaging
Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: MNG-1683: Zip packaging
I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: MNG-1683: Zip packaging
I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone -- Sent from my phone
Re: MNG-1683: Zip packaging
I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul
Re: MNG-1683: Zip packaging
either mojo or a pull request against the assembly plugin (as you may need to tweak the assembly:single default parameters) On 11 December 2014 at 14:54, Paul Benedict pbened...@apache.org wrote: I am in agreement with Stephen. If I decide to try to prototype this out, where is a good place to lay down some code? Cheers, Paul On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think having an assembly type with a default binding of assembly:single to the packaging phase and a default descriptor being the zip or zip and tar.gz descriptors would achieve what is required while simplifying escalating to more complex descriptors On Thursday, December 11, 2014, Timothy Astle timothy.as...@caris.com wrote: I have a situation/problem/use-case where I would like to take a collection of XML schemas and create a bundle of themso that they could be included into other projects. The destination projects vary. Some are written in Java, some in C++, etc. So I'd like to produce amore platform agnostic bundling artifact. At the moment, we lean on Subversion externals, which I really dislike doing. In this type of case, I figured a ZIP packaging type would have described the project and produced the expected output, while using Maven. A big thing that I like about Maven is how you model the project. Plugins are great, but opening up a POM and seeing the packaging type is just so nice and explicit. There are several ways I can accomplish my goal, but somewhere, deepdown, Ihad hoped that I'd live long enough to see a first-class ZIP packaging type become available. :-) Tim On 11/12/2014 4:41 AM, domi wrote: Hmm, not sure I agree - I think its just fact that users would love to have simpler way to create ZIPs/TARs and the most logical/simple way (from a users point of view) to do this is a packaging typ for these. Domi On 11.12.2014, at 09:27, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Well the real question is what would you do with dependencies? So, for example, if you have a zip dependency, do you unpack it and overlay or do you copy it in? Or do you do nothing and leave it to the dependency plugin? What about zip vs tar.gz dependency? If building a zip I might expect exploding the zip dependencies and copy tar.gz? A better approach might be an assembly packaging with a default assembly descriptor directory and if empty it falls back to zip and tar.gz of target/classes with the resources plugin being in the default lifecycle binding That would make using the assembly plugin less work and ack the fact that a zip or tar.gz needs the descriptor to control file permissions On Thursday, December 11, 2014, Anders Hammar and...@hammar.net wrote: Yes, but I don't think making a specific plugin just for adding zip packaging is optimal. Hence the idea of having it in the assembly plugin. Thinking of it though, one very likely wants to create both a zip and a tar file. So maybe the packaging type should be something else, and then it creates both types. But then I always advocate that one maven project should only create one artifact...hmm. /Anders On Thu, Dec 11, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net javascript:; wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org javascript:; wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com javascript:; wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org javascript:;: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683
RE: MNG-1683: Zip packaging
But there is nothing stopping people from adding custom packaging types, right? The real question is there enough demand to warrant folding it into Maven itself versus making the people that need it define it themselves. We have defined a number of custom packaging types for our own component archive formats and it is pretty straightforward... -- Robert Patrick robert.patr...@oracle.com VP, FMW Platform Engineering, Oracle Corporation 7460 Warren Pkwy, Ste. 300 Office: +1.972.963.2872 Frisco, TX 75034, USA Mobile: +1.469.556.9450 Professional Oracle WebLogic Server by Robert Patrick, Gregory Nyberg, and Philip Aston with Josh Bregman and Paul Done Book Home Page: http://www.wrox.com/ Kindle Version: http://www.amazon.com/ -Original Message- From: Paul Benedict [mailto:pbened...@apache.org] Sent: Wednesday, December 10, 2014 11:38 PM To: Apache Maven Developers Subject: MNG-1683: Zip packaging Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-1683: Zip packaging
Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-1683: Zip packaging
Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-1683: Zip packaging
I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG-1683: Zip packaging
Anders, like make a maven-zip-plugin project? On Dec 11, 2014 1:50 AM, Anders Hammar and...@hammar.net wrote: I don't think that the zip package type should be part of Maven core, but we could provide some plugin which provides for it as a custom packaging type. Possibly this could be part of the assembly plugin. /Anders On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict pbened...@apache.org wrote: Well my experience in building a zip *as a dependency* feels like it's hackish. For example, I create a pom packaging type and then configure the assembly plugin for the package phase. Okay, but I say this is hackish because it's not straight forward, and the zip is a second artifact (the pom is first) for installation. This pattern kind of smells to me and makes me think an official zip type really is needed. Having such a type can take away all this boilerplate. Cheers, Paul On Thu, Dec 11, 2014 at 12:27 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Probably because people just use the assembly plugin ? Kristian 2014-12-11 6:38 GMT+01:00 Paul Benedict pbened...@apache.org: Recently I needed to create zip artifacts for overlays into WAR. Maven doesn't have support for zip packaging type projects, but MNG-1683 wants to introduce it. I am curious why this issue has been ignored. Is it just a lack of time or interest? Or is there a philosophical issue behind the delay? I can't see much difference between the zip lifecycle and jar lifecycle except there is no default compile or test bindings. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
