Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
If I provide custom jar manifest, I expect the manifest to be used as-is, without anything added, removed or reordered. Just my 2 kopecks. -- Regards, Igor On Sun, Jun 7, 2015, at 12:50 PM, Karl Heinz Marbaise wrote: On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? One more thing. If the MANIFEST contains sections these will be broken...which is my opionion a real bug... [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
S; if you cannot add a class-path element to the manifest then ? You're wrong. Kristian 2015-06-07 19:09 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de: Hi Igor, On 6/7/15 6:57 PM, Igor Fedorenko wrote: If I provide custom jar manifest, I expect the manifest to be used as-is, without anything added, removed or reordered. Just my 2 kopecks. That's exactly what i would expect...but in all our components / plugins it works different About adding entries. I could understand that two entries like Manifest-version and Build-Jdk would be added (but may be best not by default) controlled by options... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
Hi, i wasn't discussing what kind of entries / attributes whould be helpfull... In my current builds i have much more information in there like groupId, artifactId, version, etc. This was more about ordering / adding supllemental entries if i have provided an MANIFEST.MF file...reusing it... Kind regards Karl Heinz Marbaise On 6/7/15 7:17 PM, Robert Scholte wrote: The following attributes are very handsome to be able to reproduce a build based on sources Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver I've hit several projects which I had to rebuild and this gave me enough info to do so. You actually want Build-OS as well (if that exists), but asking 'kama' for additional info when required will do the trick as well. These values shouldn't be copied from the specified MANIFEST.MF, since *this* archive has probably been built with other values. best, Robert Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise khmarba...@gmx.de: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: MNG-5837: Use a subshell, rather than the 'loc...
GitHub user josephw opened a pull request: https://github.com/apache/maven/pull/50 MNG-5837: Use a subshell, rather than the 'local' keyword, for POSIX compliance 'local' is not POSIX, but supported by most shells. However, it's not supported by Solaris's /bin/sh, so use a subshell instead. Tested on OS X by invoking with `/bin/ksh`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/josephw/maven MNG-5837-avoid-non-posix-local-keyword Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/50.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #50 commit 1efce60e0594f7445f946aeb34f89e36907fdaf1 Author: Joseph Walton j...@kafsemo.org Date: 2015-06-07T13:29:39Z MNG-5837: Use a subshell, rather than the 'local' keyword, for POSIX compliance. 'local' is not POSIX, but supported by most shells. However, it's not supported by Solaris's /bin/sh, so use a subshell instead. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.0 versions in branches ?
Hi, I've made those branches to see how much work it is to drop M2 support and to not lose my work. And it is quite a lot. I still haven't covered everything. I'm actually happy I didn't use the trunk for it, since now it was possible to do a 2.x release of the maven-shade-plugin. Now we're on it, for surefire the ArtifactResolver[1] needs to be replaced for 3.0. I still see activity for surefire-2.x, so I'll wait to work on those changes until one has decided to go for 3.0 thanks, Robert http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49 Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: Do we really need to keep the 3.0 versions in branches ? Can't we just make a branch if we need to fix something in the 2.x range ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
Hi Igor, On 6/7/15 6:57 PM, Igor Fedorenko wrote: If I provide custom jar manifest, I expect the manifest to be used as-is, without anything added, removed or reordered. Just my 2 kopecks. That's exactly what i would expect...but in all our components / plugins it works different About adding entries. I could understand that two entries like Manifest-version and Build-Jdk would be added (but may be best not by default) controlled by options... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
The jar specification says explicitly that Attributes which are not understood are ignored.; I interpret this to mean it's ok for every man and his dog to add values. Which I think means that you should expect your *values* to win, not necessarily your particular file - there's an implicit support for toolchain layering in the spec. Thats my 2 NOK. Additionally it follows map semantics, last present value wins. When we switched from the old plexus manifest to using the jdk manifest we lost the ordering, since the jdk manifest class does not support ordering. I have been trying to decide for myself if we're mostly talking about people scratching their OCD and theoretical use cases here. To this date I have yet to see anything that really convinces me otherwise. Kristian 2015-06-07 18:57 GMT+02:00 Igor Fedorenko i...@ifedorenko.com: If I provide custom jar manifest, I expect the manifest to be used as-is, without anything added, removed or reordered. Just my 2 kopecks. -- Regards, Igor On Sun, Jun 7, 2015, at 12:50 PM, Karl Heinz Marbaise wrote: On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? One more thing. If the MANIFEST contains sections these will be broken...which is my opionion a real bug... [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
The sections should be preserved though, so that's definitely a bug. K 2015-06-07 19:17 GMT+02:00 Robert Scholte rfscho...@apache.org: The following attributes are very handsome to be able to reproduce a build based on sources Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver I've hit several projects which I had to rebuild and this gave me enough info to do so. You actually want Build-OS as well (if that exists), but asking 'kama' for additional info when required will do the trick as well. These values shouldn't be copied from the specified MANIFEST.MF, since *this* archive has probably been built with other values. best, Robert Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise khmarba...@gmx.de: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shade Plugin version 2.4
Hi, On 6/7/15 12:15 PM, Karl Heinz Marbaise wrote: Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12331393 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1189 https://repository.apache.org/content/repositories/maven-1189/org/apache/maven/plugins/maven-shade-plugin/2.4/maven-shade-plugin-2.4-source-release.zip Source release checksum(s): maven-shade-plugin-2.4-source-release.zip sha1: 2ffe5cb14f62410523a59f9eb1e181d78ad47659 Staging site: http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ Please use the us mirror cause there seemed to be a sync issue with eu mirror. So please use the following URL to access the new site: http://maven.us.apache.org/plugins-archives/maven-shade-plugin-LATEST/ Already opened an issue at INFRA... Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: For example: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? One more thing. If the MANIFEST contains sections these will be broken...which is my opionion a real bug... [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Mit freundlichem Gruß Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579 Hauptstrasse 177 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
Indeed, I would not expect to having my provided manifest modified at all. On 2015-06-07 18:57, Igor Fedorenko wrote: If I provide custom jar manifest, I expect the manifest to be used as-is, without anything added, removed or reordered. Just my 2 kopecks. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
The following attributes are very handsome to be able to reproduce a build based on sources Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver I've hit several projects which I had to rebuild and this gave me enough info to do so. You actually want Build-OS as well (if that exists), but asking 'kama' for additional info when required will do the trick as well. These values shouldn't be copied from the specified MANIFEST.MF, since *this* archive has probably been built with other values. best, Robert Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise khmarba...@gmx.de: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver
I see. In that case Kristian is right: it's a bug. Op Sun, 07 Jun 2015 19:33:03 +0200 schreef Karl Heinz Marbaise khmarba...@gmx.de: Hi, i wasn't discussing what kind of entries / attributes whould be helpfull... In my current builds i have much more information in there like groupId, artifactId, version, etc. This was more about ordering / adding supllemental entries if i have provided an MANIFEST.MF file...reusing it... Kind regards Karl Heinz Marbaise On 6/7/15 7:17 PM, Robert Scholte wrote: The following attributes are very handsome to be able to reproduce a build based on sources Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver I've hit several projects which I had to rebuild and this gave me enough info to do so. You actually want Build-OS as well (if that exists), but asking 'kama' for additional info when required will do the trick as well. These values shouldn't be copied from the specified MANIFEST.MF, since *this* archive has probably been built with other values. best, Robert Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise khmarba...@gmx.de: Sorry was too fast with my send button... Hi, at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]... If i create a MANIFEST.MF my own and let maven-jar-plugin take that file via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be extended by several entries: My own file: Manifest-Version: 1.0 Test: This is my MANUALLY CREATED MANIFEST FILE Second: This is the second line. After running through maven-jar-plugin you will get the following: Manifest-Version: 1.0 Second: This is the second line. Test: This is my MANUALLY CREATED MANIFEST FILE Built-By: kama Build-Jdk: 1.7.0_21 Created-By: Apache Maven 3.1.1 Archiver-Version: Plexus Archiver There are comming up two questions: 1. Does it make sense to add only Manifest-Version and Build-Jdk entries. But nothing else if i use my own MANIFEST.MF file. Based on what i have read on [3] it would make sense. 2. Currently the handling internally does not kepp the order of the original entries which is based on the used implementation (HashMap, Hashtable etc. which makes sense. Wouldn't it be better to keep the original order of elements? So based on what i can see we have handling of manifest in maven-archiver component and in plexus-archiver ? [1] https://issues.apache.org/jira/browse/MJAR-195 [2] https://issues.apache.org/jira/browse/MJAR-193 [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.0 versions in branches ?
+1 On Sunday, June 7, 2015, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Do we really need to keep the 3.0 versions in branches ? Can't we just make a branch if we need to fix something in the 2.x range ? Kristian -- Sent from my phone
[VOTE] Release Apache Maven Shade Plugin version 2.4
Hi, We solved 14 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12331393 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1189 https://repository.apache.org/content/repositories/maven-1189/org/apache/maven/plugins/maven-shade-plugin/2.4/maven-shade-plugin-2.4-source-release.zip Source release checksum(s): maven-shade-plugin-2.4-source-release.zip sha1: 2ffe5cb14f62410523a59f9eb1e181d78ad47659 Staging site: http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 3.0 versions in branches ?
And I appreciate your work a lot. I've got the assembly-plugin migration in github and I'll just land that right on trunk once I'm happy with it. Kristian 2015-06-07 17:35 GMT+02:00 Robert Scholte rfscho...@apache.org: Hi, I've made those branches to see how much work it is to drop M2 support and to not lose my work. And it is quite a lot. I still haven't covered everything. I'm actually happy I didn't use the trunk for it, since now it was possible to do a 2.x release of the maven-shade-plugin. Now we're on it, for surefire the ArtifactResolver[1] needs to be replaced for 3.0. I still see activity for surefire-2.x, so I'll wait to work on those changes until one has decided to go for 3.0 thanks, Robert http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49 Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: Do we really need to keep the 3.0 versions in branches ? Can't we just make a branch if we need to fix something in the 2.x range ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
3.0 versions in branches ?
Do we really need to keep the 3.0 versions in branches ? Can't we just make a branch if we need to fix something in the 2.x range ? Kristian
Re: 3.0 versions in branches ?
I don't expect M2 specific changes on the shared component anymore, so I think we those projects are ready to be merged back to the trunk. That is: - maven-artifact-transfer - maven-common-artifact-filters - maven-dependency-tree Let me do that the following period, including the creation of matching JIRA issues to trace back all changes Robert Op Sun, 07 Jun 2015 17:52:24 +0200 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: And I appreciate your work a lot. I've got the assembly-plugin migration in github and I'll just land that right on trunk once I'm happy with it. Kristian 2015-06-07 17:35 GMT+02:00 Robert Scholte rfscho...@apache.org: Hi, I've made those branches to see how much work it is to drop M2 support and to not lose my work. And it is quite a lot. I still haven't covered everything. I'm actually happy I didn't use the trunk for it, since now it was possible to do a 2.x release of the maven-shade-plugin. Now we're on it, for surefire the ArtifactResolver[1] needs to be replaced for 3.0. I still see activity for surefire-2.x, so I'll wait to work on those changes until one has decided to go for 3.0 thanks, Robert http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49 Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold kristian.rosenv...@gmail.com: Do we really need to keep the 3.0 versions in branches ? Can't we just make a branch if we need to fix something in the 2.x range ? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: http://repository.apache.org/ is down?
Nexus UI showed up from here (Toronto). -- Regards, Igor On Sun, Jun 7, 2015, at 08:41 PM, Dan Tran wrote: Can someone confirm if http://repository.apache.org is down at your side? Thanks -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
http://repository.apache.org/ is down?
Can someone confirm if http://repository.apache.org is down at your side? Thanks -Dan
Re: http://repository.apache.org/ is down?
It is back now in California Thanks -Dan On Sun, Jun 7, 2015 at 5:47 PM, Igor Fedorenko i...@ifedorenko.com wrote: Nexus UI showed up from here (Toronto). -- Regards, Igor On Sun, Jun 7, 2015, at 08:41 PM, Dan Tran wrote: Can someone confirm if http://repository.apache.org is down at your side? Thanks -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: http://repository.apache.org/ is down?
Up here is Sourthern Cal. Gary On Sun, Jun 7, 2015 at 5:41 PM, Dan Tran dant...@gmail.com wrote: Can someone confirm if http://repository.apache.org is down at your side? Thanks -Dan -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
