RE: AW: "mvn clean package" requests access rights for local Nexus repository
as bernd suggested can you view possible access when you enable -X? might also help to see extension errors with -e mvn -e -X package > package.out can we view package.out? I would be interested looking at the netstat deltas specifically sh>netstat -a > netstat_before.log run command sh>mvn -X package run another shell and view any new network connections >netstat -a > netstat_after.log any deltas between netstat_before.log and netstat_after.log can you display both here so we can diff the 2 files? ? Martin > From: k...@quipsy.de > To: users@maven.apache.org > Date: Wed, 18 Mar 2015 16:42:06 +0100 > Subject: AW: "mvn clean package" requests access rights for local Nexus > repository > > Bernd, > > your theory failed the test: > > * Unplugged USB stick, so Maven has no passwords anymore > * Removed .m2\repository folder from disk, so Maven is enforced to download > rather everything newly from our Nexus mirror > * "mvn clean package" built maven-dependency-plugin without any problem > > Conclusion: It is definitively NOT a download problem, but still supports my > theory that maven-dependency-plugin wants to UPLOAD something at "package" > phase. > > If I just would have kept the protocol earlier today, I could tell you what > "thing" actually it was... :-( > > Regards > -Markus > > > -Ursprüngliche Nachricht- > Von: Bernd [mailto:e...@zusammenkunft.net] > Gesendet: Mittwoch, 18. März 2015 14:27 > An: Maven Users List > Betreff: Re: "mvn clean package" requests access rights for local Nexus > repository > > Hello, > > It sounds more like a download as it does not ask again. You can wipe your > local repo cache (or use a different one in settings.xml) and try to > reproduce the problem. If you run with -X and actually keep the maven log > output you should be able to see the access in question. > > Gruss > Bernd > Am 18.03.2015 14:02 schrieb "Markus Karg" : > > > Dear Maven Experts, > > > > just did "svn checkout" to get trunk of maven-dependency-plugin, and > > wanted to build it using "mvn clean package". What then happened is > > really > > scary: > > > > > > * It complained about missing access on that path where my USB > > stick stores the encrypted password for my local Nexus repository. > > > > * My local Nexus repository is a mirror of "central" with public > > access, only demanding passwords for uploads. > > > > * I plugged in my stick, did "mvn clean package" again, and it > > worked pretty well. > > > > * REMOVED my stick, and since then "mvn clean package" works > > without, still! > > > > That looks if packaging "maven-dependency-plugin" would need to WRITE > > into my Nexus (possibly central?) at package phase, if a particular > > "thing" is not found there. > > > > This is scary, as nobody expects UPLOADS are done at packaging. > > > > If somebody has an explanation why that happens, I'd ask him to > > publish here, so everybody will understand the reason for this! :) > > > > Regards > > -Markus > > > > > > > B�CB�� [��X��ܚX�KK[XZ[� \�\��][��X��ܚX�PX]�[��\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[� \�\��Z[ X]�[��\X�K�ܙ�B
Maven License Plugin question
Hi all!
I have problems understanding the purpose of an attribute of
license:update-project-license goal.
About the generateBundle attribute the docs say:
"A flag to copy the main license file in a bundled place. This is usefull
for final application to have a none confusing location to seek for the
application license. If Sets to true, will copy the license file to the
bundleLicensePath to outputDirectory. *Note:* This option is not available
for pom module types."
I understand, that by default this will copy the full license file to
META-INF/${project.artifactId}-LICENSE.txt
which would otherwise be copied to the root of the jar.
What I don't understand is the explanation of the cases in which this is
benificial.
Is the "bundle" in generateBundle the "bundle" from OSGi, so this attribute
something connected with generating OSGi bundles?
I would appreciate if someone could provide an explaining paraphrasis of "
This is usefull for final application to have a none confusing location to
seek for the application license.".
Markward
[ANN] Apache Maven JavaDoc Plugin Version 2.10.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven JavaDoc Plugin, version 2.10.2 http://maven.apache.org/plugins/maven-javadoc-plugin/ The Javadoc Plugin uses the Javadoc tool to generate javadocs for the specified project. org.apache.maven.plugins maven-javadoc-plugin 2.10.2 Release Notes - Maven JavaDoc Plugin - Version 2.10.2 Bug: * [MJAVADOC-365] - [Patch] sourceFileExcludes does not work due to inclusion of packages Improvements: * [MJAVADOC-415] - Update plexus-archiver to 2.6.3 and p-utils to 3.0.18 * [MJAVADOC-417] - Update version of plexus-archive from 2.5 to 2.9 Enjoy, - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven 3.3.1 Release
Great news. I love how Maven has picked up the pace and is really moving forward a lot again. Now given that 3.2.5 is the last relase with Java 6 support .. should that not be on the downloads page somewhere? Either replacing 3.1.1 or as an addition. Personally I think that page should ONLY contain 3.3.1 and all the old releases show be on the archive page. Wdyt? manfred Jason van Zyl wrote on 17.03.2015 20:37: > Hi! > > The Apache Maven Team is pleased to announce the release of 3.3.1 > > The official release notes can be found here: > http://maven.apache.org/docs/3.3.1/release-notes.html > > But Karl Heinz has written up better release notes here: > http://blog.soebes.de/blog/2015/03/17/apache-maven-3-dot-3-1-features/ > > The release can be downloaded from: > http://maven.apache.org/download.cgi > > Full list of changes can be viewed in JIRA: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=21013 > > Thanks, > > The Maven Team > > > > > > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: "mvn clean package" requests access rights for local Nexus repository
Bernd, your theory failed the test: * Unplugged USB stick, so Maven has no passwords anymore * Removed .m2\repository folder from disk, so Maven is enforced to download rather everything newly from our Nexus mirror * "mvn clean package" built maven-dependency-plugin without any problem Conclusion: It is definitively NOT a download problem, but still supports my theory that maven-dependency-plugin wants to UPLOAD something at "package" phase. If I just would have kept the protocol earlier today, I could tell you what "thing" actually it was... :-( Regards -Markus -Ursprüngliche Nachricht- Von: Bernd [mailto:e...@zusammenkunft.net] Gesendet: Mittwoch, 18. März 2015 14:27 An: Maven Users List Betreff: Re: "mvn clean package" requests access rights for local Nexus repository Hello, It sounds more like a download as it does not ask again. You can wipe your local repo cache (or use a different one in settings.xml) and try to reproduce the problem. If you run with -X and actually keep the maven log output you should be able to see the access in question. Gruss Bernd Am 18.03.2015 14:02 schrieb "Markus Karg" : > Dear Maven Experts, > > just did "svn checkout" to get trunk of maven-dependency-plugin, and > wanted to build it using "mvn clean package". What then happened is > really > scary: > > > * It complained about missing access on that path where my USB > stick stores the encrypted password for my local Nexus repository. > > * My local Nexus repository is a mirror of "central" with public > access, only demanding passwords for uploads. > > * I plugged in my stick, did "mvn clean package" again, and it > worked pretty well. > > * REMOVED my stick, and since then "mvn clean package" works > without, still! > > That looks if packaging "maven-dependency-plugin" would need to WRITE > into my Nexus (possibly central?) at package phase, if a particular > "thing" is not found there. > > This is scary, as nobody expects UPLOADS are done at packaging. > > If somebody has an explanation why that happens, I'd ask him to > publish here, so everybody will understand the reason for this! :) > > Regards > -Markus > > >
Custom plugin configuration for custom packaging?
Hi, I have created a custom packaging with a custom lifecycle binding. During building projects with this packaging, the maven-assembly-plugin is invoked. This plugin needs a special configuration, which seems to be impossible within the components.xml. What would be the preferred way to do this (except prescribing the usage of a parent pom to configure the plugin)? Would it be possible (and how) to declare a custom super pom for my custom packaging? Regards, Ralf Zahn ARS Computer und Consulting GmbH, http://www.ars.de Ridlerstrasse 55, 80339 Muenchen, Deutschland Application Development Services, Business Transformation Services, IT Infrastruktur Services Beratung und Vertrieb zu IBM Software, System x, POWER Systems, Storage License Management Services, IBM Passport Advantage Lizenzierung Handelsregister Muenchen, HRB 101829, USt-ID: DE 155 068 909 Geschaeftsfuehrer: Michael Arbesmeier, Kai-Uwe Rommel, Roland Schock, Joachim Gucker
Re: Documentation (wrongly?) says Maven 3.3.1 runs with Java 1.6
Olivier fixed the doco so that should do out shortly. On Mar 18, 2015, at 9:48 AM, Anders Hammar wrote: > That is correct, the docs haven't been updated. Maven 3.3+ requires JDK 1.7. > > /Anders (mobile) > Den 18 mar 2015 09:37 skrev "Arend v. Reinersdorff" : > >> Hi, >> >> Maven 3.3.1 requires Java 1.7: >> - [MNG-5780] - upgrade Java minimum version prerequisite from Java 6 to >> Java 7 >> - When I try to run Maven 3.3.1 with Java 1.6 I get the exception: >> Exception in thread "main" java.lang.UnsupportedClassVersionError: >> org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0 >> >> >> But the documentation says the system requirements are still at Java 1.6: >> - On the download page: http://maven.apache.org/download.cgi#Requirements >> - In README.txt when downloading Maven 3.3.1: >> System Requirements >> --- >> JDK: >>1.6 or above (this is to execute Maven - it still allows you to build >> against 1.3 >>and prior JDK's). >> >> I assume the requirement is really Java 1.7 but the documentation has not >> been updated? >> >> Regards, >> Arend >> Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Documentation (wrongly?) says Maven 3.3.1 runs with Java 1.6
That is correct, the docs haven't been updated. Maven 3.3+ requires JDK 1.7. /Anders (mobile) Den 18 mar 2015 09:37 skrev "Arend v. Reinersdorff" : > Hi, > > Maven 3.3.1 requires Java 1.7: > - [MNG-5780] - upgrade Java minimum version prerequisite from Java 6 to > Java 7 > - When I try to run Maven 3.3.1 with Java 1.6 I get the exception: > Exception in thread "main" java.lang.UnsupportedClassVersionError: > org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0 > > > But the documentation says the system requirements are still at Java 1.6: > - On the download page: http://maven.apache.org/download.cgi#Requirements > - In README.txt when downloading Maven 3.3.1: > System Requirements > --- > JDK: > 1.6 or above (this is to execute Maven - it still allows you to build > against 1.3 > and prior JDK's). > > I assume the requirement is really Java 1.7 but the documentation has not > been updated? > > Regards, > Arend >
Re: "mvn clean package" requests access rights for local Nexus repository
Hello, It sounds more like a download as it does not ask again. You can wipe your local repo cache (or use a different one in settings.xml) and try to reproduce the problem. If you run with -X and actually keep the maven log output you should be able to see the access in question. Gruss Bernd Am 18.03.2015 14:02 schrieb "Markus Karg" : > Dear Maven Experts, > > just did "svn checkout" to get trunk of maven-dependency-plugin, and > wanted to build it using "mvn clean package". What then happened is really > scary: > > > * It complained about missing access on that path where my USB > stick stores the encrypted password for my local Nexus repository. > > * My local Nexus repository is a mirror of "central" with public > access, only demanding passwords for uploads. > > * I plugged in my stick, did "mvn clean package" again, and it > worked pretty well. > > * REMOVED my stick, and since then "mvn clean package" works > without, still! > > That looks if packaging "maven-dependency-plugin" would need to WRITE into > my Nexus (possibly central?) at package phase, if a particular "thing" is > not found there. > > This is scary, as nobody expects UPLOADS are done at packaging. > > If somebody has an explanation why that happens, I'd ask him to publish > here, so everybody will understand the reason for this! :) > > Regards > -Markus > > >
"mvn clean package" requests access rights for local Nexus repository
Dear Maven Experts, just did "svn checkout" to get trunk of maven-dependency-plugin, and wanted to build it using "mvn clean package". What then happened is really scary: * It complained about missing access on that path where my USB stick stores the encrypted password for my local Nexus repository. * My local Nexus repository is a mirror of "central" with public access, only demanding passwords for uploads. * I plugged in my stick, did "mvn clean package" again, and it worked pretty well. * REMOVED my stick, and since then "mvn clean package" works without, still! That looks if packaging "maven-dependency-plugin" would need to WRITE into my Nexus (possibly central?) at package phase, if a particular "thing" is not found there. This is scary, as nobody expects UPLOADS are done at packaging. If somebody has an explanation why that happens, I'd ask him to publish here, so everybody will understand the reason for this! :) Regards -Markus
Documentation (wrongly?) says Maven 3.3.1 runs with Java 1.6
Hi, Maven 3.3.1 requires Java 1.7: - [MNG-5780] - upgrade Java minimum version prerequisite from Java 6 to Java 7 - When I try to run Maven 3.3.1 with Java 1.6 I get the exception: Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/maven/cli/MavenCli : Unsupported major.minor version 51.0 But the documentation says the system requirements are still at Java 1.6: - On the download page: http://maven.apache.org/download.cgi#Requirements - In README.txt when downloading Maven 3.3.1: System Requirements --- JDK: 1.6 or above (this is to execute Maven - it still allows you to build against 1.3 and prior JDK's). I assume the requirement is really Java 1.7 but the documentation has not been updated? Regards, Arend
AW: How to configure maven-dependency-plugin's encoding used for unpack?
No I have never heard of vfs-maven-plugin before, and I doubt it will be an easy solution, as the "download" address is not known in the POM -- it is a DEPENDENCY, hence the dependency resolution mechanism has to be used. -Ursprüngliche Nachricht- Von: Andreas Gudian [mailto:andreas.gud...@gmail.com] Gesendet: Dienstag, 17. März 2015 20:20 An: Maven Users List Betreff: Re: How to configure maven-dependency-plugin's encoding used for unpack? Markus, as for an "ASAP" quick fix, did you try using the vfs-maven-plugin to unpack your zip files? I don't fully understand your usecase, but I use that one to download and unpack zip files within a maven build. 2015-03-17 13:34 GMT+01:00 Kristian Rosenvold : > I can guarantee a timely review, which is about as much as we > guarantee around here :) > > There is a practical issue, since maven assembly plugin uses a > parameter called "archiverConfig" configure the Archiver. I am still > pondering if for assembly I should supply the *same* config object or > create a separate one called "unarchiverConfig". The same would apply > for dependency plugin, since we'd definitely want this to be done in > the same manner. > > Kristian > > > 2015-03-17 9:49 GMT+01:00 Markus Karg : > > Great, thanks a lot! :-) > > > > But let's negotiate one thing upfront: If we provide code that adds > to maven-dependency-plugin's , which > essentially forwards the encoding to the Plexus Unarchiver, and it > looks good to you from a technical view, will you guarantee us that it > will definitively up in the plugin? I have to ask that upfront because > of the discussion going on here currently about the general usefulness > of encodings and we must not spend any time into providing code if it > ends up in the trash due to different opinions within the pluging > management team. So if you can ensure this, we will lookup some people coding > the solution. > > > > Thanks! > > -Markus > > > > > > -Ursprüngliche Nachricht- > > Von: kristian.rosenv...@zenior.no > > [mailto:kristian.rosenv...@zenior.no] > Im Auftrag von Kristian Rosenvold > > Gesendet: Dienstag, 17. März 2015 08:39 > > An: Maven Users List > > Betreff: Re: How to configure maven-dependency-plugin's encoding > > used > for unpack? > > > > I'm not kidding about anything. I reopened the issue. > > > > If you make a patch that applies encoding to zip files I can review that. > > > > Kristian > > > > > > 2015-03-17 8:27 GMT+01:00 Markus Karg : > > > >> Kristian, > >> > >> you're kidding, don't you? ;-) > >> > >> what you propose does not work. We are an ISV providing a download > >> for virtually anybody. We cannot tell the world "Hey, you cannot > >> simply use Windows to unzip, but you must first download some other > >> application, because we're using Maven, and it is unable to deal > >> with encodings.". :-( > >> > >> We are NOT packaging a "jar" file. We are packaging a "zip" file. > >> In fact I never mentioned "jar" AFAIK. That one is publicly downloadable. > >> Some team told us they use that "zip" as a dependency and need to > >> unpack it as part of their "prepare-package" phase (they only need > >> some files, not the full zip). At that moment, then file names are > >> turned into garbage. If there is headroom, then let's use that > >> headroom. All we demand is a way to tell in the POM that the plexus > >> "zip unarchiver" used by maven-dependency-plugin for that single > >> artifactItem shall use CP850. :-) > >> > >> I'm talking about http://jira.codehaus.org/browse/MDEP-436 > >> > >> Thank you for your kind help. > >> > >> Regards > >> -Markus > >> > >> > >> -Ursprüngliche Nachricht- > >> Von: kristian.rosenv...@zenior.no > >> [mailto:kristian.rosenv...@zenior.no] > >> Im Auftrag von Kristian Rosenvold > >> Gesendet: Montag, 16. März 2015 21:19 > >> An: Maven Users List > >> Betreff: Re: How to configure maven-dependency-plugin's encoding > >> used for unpack? > >> > >> There is no way to specify unarchiver encoding in the dependency > >> plugin, I have checked. So currently you have to make your users > >> install a less brain dead zip program than the windows compressed > folder mechanism. > >> > >> I am also slightly questioning of what you are trying to achieve > >> here; if you are unpacking a "jar" file then it *will* and *should* > >> be UTF8, meaning you cannot use the lobotomized zip support that is > >> included in windows, no matter what. I don't see us fixing /that/ > >> issue, since we'd be violating the jar specification. If your > >> dependency is to an actual "zip" file, we have slightly more > >> headroom, and such a patch > might be applied. > >> > >> I am not sure which issue you are referring to, I know there is one > >> for assembly-plugin (http://jira.codehaus.org/browse/MASSEMBLY-748) > >> since the encoding feature should be fixed to work for "unpack" too. > >> > >> Kristian > >> > >> > >> > >> > >> 2015-03-16 15:04 GMT+01:00 Mark
