Re: Maven return code 502, ReasonPhrase:notresolvable
Hi Karl, I will see what happens with the version change from 1.3 of maven-antrun-plugin, I will try to take a look into that and see if I can make those changes. Looking in the POM file there is no version specified for it explicitly. I'll have to see where that is coming from. "Return code is: 502 , ReasonPhrase:notresolvable." is the error Maven provides and looking at: http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException which is the link provided in the exception thrown by Maven, I have tried the suggestions provided there to no avail. We do not have anything else between Maven and Nexus. There is no Apache HTTP server in between, it is a direct connection to Nexus, so its Nexus OSS plain. The artefacts I listed in the original email below, are the only artefacts that are affected. All other artefacts are downloaded just fine. No Nexus changes have been made, I have already checked that. BEGIN settings.xml -- http corp-proxy-server.mycorp.com 80 *.oldcorp.com|*.mycorp*.com releases Internal Nexus Releases http://nexusoss.mycorp.com:8081/nexus/content/groups/releases central configure-snapshot-repository true snapshots Internal Nexus Snapshots http://nexusoss.mycorp.com:8081/nexus/content/groups/snapshots false true always releases Internal Nexus Releases http://nexusoss.mycorp.com:8081/nexus/content/groups/releases/ true false always snapshots Internal Nexus Snapshots http://nexusoss.mycorp.com:8081/nexus/content/groups/snapshots false true always releases Internal Nexus Releases http://nexusoss.mycorp.com:8081/nexus/content/groups/releases/ true false always override-properties true use-maven-central remote-central http://repo1.maven.org/maven2 remote-central http://repo2.maven.org/maven2 suborg-snapshots 664 775 nightly some-password suborg-releases 664 775 nightly some-password - END settings.xml - On Sun, Aug 13, 2017 at 12:56 PM, Karl Heinz Marbaise wrote: > Hi, > > first recommendation I can give is upgrade the plugin versions cause 1.3 > from 2008 ...is really old... > > furthermore error code 502 is "Bad Gateway"...do you have an Apache http > server between you and the Nexus ? Or do you use Nexus plain...? Sounds > like an issue on network level...Or bad configuration of Nexus etc.. > > How does your settings.xml look like? > > Kind regards > Karl Heinz Marbaise > > On 13/08/17 18:29, Mehul Sanghvi wrote: > >> I upgraded my Nexus OSS server to version 2.14.5-02, and I still see the >> same issue. All new builds that I have >> get affected by this, unless I manually copy the artefacts from an >> existing >> local maven repository. >> >> I have rebuilt the metadata, re-built the indexes, etc. as well. Still >> the >> same result. >> >> Anyone have any thoughts/suggestions/pointers ? >> >> cheers, >> >> mehul >> >> >> On Wed, Jul 26, 2017 at 9
Re: Maven return code 502, ReasonPhrase:notresolvable
I upgraded my Nexus OSS server to version 2.14.5-02, and I still see the same issue. All new builds that I have get affected by this, unless I manually copy the artefacts from an existing local maven repository. I have rebuilt the metadata, re-built the indexes, etc. as well. Still the same result. Anyone have any thoughts/suggestions/pointers ? cheers, mehul On Wed, Jul 26, 2017 at 9:21 AM, Mehul Sanghvi wrote: > Maven version: 3.3.3 > Nexus version: OSS 2.14.o-1 > > Starting this past Monday, I have been seeing the following: > > > build 25-Jul-2017 20:27:16 [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-antrun-plugin:1.3:run (default) on project > xml2jsonMigration: Execution default of goal > org.apache.maven.plugins:maven-antrun-plugin:1.3:run failed: Plugin > org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its > dependencies > could not be resolved: The following artifacts could not be resolved: > org.apache.maven:maven-plugin-api:jar:2.0.4, > org.apache.maven:maven-project:jar:2.0.4, > org.apache.maven:maven-settings:jar:2.0.4, > org.apache.maven:maven-profile:jar:2.0.4, > org.apache.maven:maven-model:jar:2.0.4, > org.apache.maven:maven-artifact-manager:jar:2.0.4, > org.apache.maven:maven-repository-metadata:jar:2.0.4, > org.apache.maven:maven-artifact:jar:2.0.4, > org.codehaus.plexus:plexus-utils:jar:1.5.6: Could not transfer artifact > org.apache.maven:maven-plugin-api:jar:2.0.4 from/to releases > (http://nexus.myorg.com:8081/nexus/content/groups/releases/): Failed to > transfer file: > http://nexus.myorg.com:8081/nexus/content/groups/releases/ > org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar. > Return code is: 502 , > ReasonPhrase:notresolvable. > > > At first it was for an artefact that was located in an internal corporate > Artifactory repository, which I was able to get past by modifying the proxy > settings in the settings.xml file. It used to be: > > *.myorg.com > > and I changed it to > > *.myorg.com|*.mycorp.com > > > > The error above that I am getting though, is for something that was > working. And the artefacts are accessible via the web browser. From a > network standpoint, the Nexus server is one hop away (based on traceroute > information). > > This used to work. There have been no network changes, not VM changes, > no updates to Maven. We did change the version number of our product by > removing the -SNAPSHOT, but that should not cause this error that we are > seeing. > > I have tried using the -U command line option, as well as just pointing > maven.repo.local to a new location and avoiding any cacheing issues. > > > Any pointers/suggestions/thoughts ? > > -- > Mehul N. Sanghvi > email: mehul.sang...@gmail.com > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven not getting latest artefact after deploy:deploy-file
I will do my best to illustrate with as simple an example as I can.
Hopefully I don't miss anything by simplifying it.
Project-A:
com.my.dept
dept-artefact
11.3.0.1.0-SNAPSHOT
The above is uploaded to Nexus using deploy:deploy-file
Project-B depends on Project-A artefact and so has the following in its POM
file.
com.my.dept
dept-artefact
11.3.0.1.0-SNAPSHOT
Nexus is setup to keep the latest 5 versions of the SNAPSHOTS.
So I see the following before the upload:
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--5-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--4-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--3-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--2-all.zip
com/my/dept/dept-artefact/11.3.0.1.0-SNAPSHOT/dept-artefact-11.3.0.1.0--1-all.zip
I have not shown the POM file and the MD5 and SHA1 files above, but they
also exist with similar names.
Now when I run Project-A, and it deploys a new build of the artefact to
Nexus, then from the above list of files the -1-all.zip file gets deleted,
and a -6-all.zip file is added, which is the latest version.
When a build of Project-B is triggered, it will pick up the -5-all.zip
rather than the -6-all.zip. I have to manually update
the metadata in order for Project-B to pick up the latest snapshot.
We also have scheduled tasks in Nexus that periodically run to rebuild the
metadata and the indexes, mainly due to
the level of activity we see.
Hope this helps illustrates a little better what I am running into.
cheers,
mehul
On Thu, Aug 3, 2017 at 3:19 AM, Yaron Golan wrote:
> The issue of getting the correct version when downloading is what written
> in the pom.xml file.
> It has nothing to do with whatever version you uploaded.
>
>
> Yaron Golan
>
>
> -----Original Message-
> From: Mehul Sanghvi [mailto:mehul.sang...@gmail.com]
> Sent: Wednesday, August 02, 2017 7:28 PM
> To: ML Maven Users
> Subject: Maven not getting latest artefact after deploy:deploy-file
>
> Maven: 3.3.3
> Nexus: OSS 2.14.0-1
>
> We have a build process that explicitly uploads a few artefacts using
> deploy:deploy-file. Subsequent builds in the chain, will than download
> these artefacts, but they never end up getting the latest artefact from
> Nexus.
>
> We can see the artefact is available in Nexus, but I always have to do a
> manual rebuilding of the metadata in Nexus before I am able to have the
> subsequent builds pick up the latest version.
>
> Here is what we use for uploading with deploy:deploy-file:
>
> ${mvn} deploy:deploy-file -B -V --quiet -s ${settings_file}
> -P${mvn_profile} ${maven_options} ${deploy_file_options}
> -DrepositoryId=${repo_id} -Durl=${repo_url} -DgroupId=${group_id}
> -Dversion=${version} -DartifactId=${artifact_id} -Dfile=${artefact}
>
> The above is run in a bash for-loop after the variables are setup via a
> case-esac statement.
>
>
> For downloading it is just "mvn clean install -B -V -U" followed by
> locations for security settings file and maven local repo.
>
>
>
> Any thoughts or suggestion ? Let me know if more information is required.
>
> cheers,
>
> mehul
>
>
> --
> Mehul N. Sanghvi
> email: mehul.sang...@gmail.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
--
Mehul N. Sanghvi
email: mehul.sang...@gmail.com
Maven not getting latest artefact after deploy:deploy-file
Maven: 3.3.3
Nexus: OSS 2.14.0-1
We have a build process that explicitly uploads a few artefacts using
deploy:deploy-file. Subsequent builds in the chain, will than download
these artefacts, but they never end up getting the latest artefact from
Nexus.
We can see the artefact is available in Nexus, but I always have to do a
manual rebuilding of the metadata in Nexus before I am able to have the
subsequent builds pick up the latest version.
Here is what we use for uploading with deploy:deploy-file:
${mvn} deploy:deploy-file -B -V --quiet -s ${settings_file}
-P${mvn_profile} ${maven_options} ${deploy_file_options}
-DrepositoryId=${repo_id} -Durl=${repo_url} -DgroupId=${group_id}
-Dversion=${version} -DartifactId=${artifact_id} -Dfile=${artefact}
The above is run in a bash for-loop after the variables are setup via a
case-esac statement.
For downloading it is just "mvn clean install -B -V -U" followed by
locations for security settings file and maven local repo.
Any thoughts or suggestion ? Let me know if more information is required.
cheers,
mehul
--
Mehul N. Sanghvi
email: mehul.sang...@gmail.com
Maven return code 502, ReasonPhrase:notresolvable
Maven version: 3.3.3 Nexus version: OSS 2.14.o-1 Starting this past Monday, I have been seeing the following: build 25-Jul-2017 20:27:16 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run (default) on project xml2jsonMigration: Execution default of goal org.apache.maven.plugins:maven-antrun-plugin:1.3:run failed: Plugin org.apache.maven.plugins:maven-antrun-plugin:1.3 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.apache.maven:maven-plugin-api:jar:2.0.4, org.apache.maven:maven-project:jar:2.0.4, org.apache.maven:maven-settings:jar:2.0.4, org.apache.maven:maven-profile:jar:2.0.4, org.apache.maven:maven-model:jar:2.0.4, org.apache.maven:maven-artifact-manager:jar:2.0.4, org.apache.maven:maven-repository-metadata:jar:2.0.4, org.apache.maven:maven-artifact:jar:2.0.4, org.codehaus.plexus:plexus-utils:jar:1.5.6: Could not transfer artifact org.apache.maven:maven-plugin-api:jar:2.0.4 from/to releases (http://nexus.myorg.com:8081/nexus/content/groups/releases/): Failed to transfer file: http://nexus.myorg.com:8081/nexus/content/groups/releases/org/apache/maven/maven-plugin-api/2.0.4/maven-plugin-api-2.0.4.jar. Return code is: 502 , ReasonPhrase:notresolvable. At first it was for an artefact that was located in an internal corporate Artifactory repository, which I was able to get past by modifying the proxy settings in the settings.xml file. It used to be: *.myorg.com and I changed it to *.myorg.com|*.mycorp.com The error above that I am getting though, is for something that was working. And the artefacts are accessible via the web browser. From a network standpoint, the Nexus server is one hop away (based on traceroute information). This used to work. There have been no network changes, not VM changes, no updates to Maven. We did change the version number of our product by removing the -SNAPSHOT, but that should not cause this error that we are seeing. I have tried using the -U command line option, as well as just pointing maven.repo.local to a new location and avoiding any cacheing issues. Any pointers/suggestions/thoughts ? -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: variable doesn't work for version
I am guessing that is what is happening in my case.
We have a multi-module project, and so the root POM has the following for
the project:
com.mehul
super-project
pom
${revision}
In sub-module-A/pom.xml:
com.mehul
super-project
${revision}
com.mehul
sub-module-A
In sub-module-A/sub-AA/pom.xml
com.mehul
sub-module-A
${revision}
com.mehul
sub-AA-maven-plugin
maven-plugin
sub-AA-maven-plugin is required before the project can be built, so I do
the following
steps in order to get the over-all project built:
bash% cd sub-module-A
bash% mvn -Drevision=1.2.3.4.5-SNAPSHOT -B -V clean install
bash% cd ..
bash% mvn -Drevision=1.2.3.4.5-SNAPSHOT -B -V clean install
Everything gets built, but when I look at the
~/.m2/repository/com/mehul/sub-module-A/1.2.3.4.5-SNAPSHOT/sub-module-A-1.2.3.4.5-SNAPSHOT.pom
file, the version is not substituted with 1.2.3.4.5-SNAPSHOT, but rather
still has
the ${revision} property, verbatim.
Is this expected behaviour or is this a bug? Is this what is being talked
about when saying
this doesn't fully include logic to ensure that the
substitution resolved pom is installed/deployed, so may cause issues
for
out-of-reactor consumption as a dependency
I do get dependency related issues when trying to use sub-AA-maven-plugin
in the build process. The failure is of
the following type:
No plugin found for prefix 'sub-AA' in the current project and in the
plugin groups ...
If I use an explicit version number in the POM files, everything works just
fine. Also if I use plugin with full GAV
resolution from the command line:
mvn com.mehul:sub-AA-maven-plugin:1.2.3.4.5-SNAPSHOT:do-fubar
it works just fine. Normally I would use the plug-in using the following:
mvn sub-AA:do-fubar
and nothing more.
Apologies if this is not related to the issue at hand. I was reading
through this thread and it seemed what was being talked about was similar
to my issue.
cheers,
mehul
On Thu, Mar 10, 2016 at 3:04 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Also I suspect this doesn't fully include logic to ensure that the
> substitution resolved pom is installed/deployed, so may cause issues for
> out-of-reactor consumption as a dependency, or GPG signature validation if
> you try to "fix" with a hack
>
> On Thursday 10 March 2016, Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> wrote:
>
> > It's ${revision} or ${changelist} or a third one I cannot recall, ${rev}
> > is on the "moan and wail" list
> >
> > On Wednesday 9 March 2016, Benson Margulies > > wrote:
> >
> >> Almost really working. The only gripe is that it is still warning me
> >> that I have an expression in , even when I use 'rev' as
> >> cited. Is that poor choice?
> >>
> >> [INFO] rev 0.0.1.20160309172035
> >> [INFO] Scanning for projects...
> >> [WARNING]
> >> [WARNING] Some problems were encountered while building the effective
> >> model for
> >> com.basistech:auto-version-maven-extension-test:jar:0.0.1.20160309172035
> >> [WARNING] 'version' contains an expression but should be a constant. @
> >> com.basistech:auto-version-maven-extension-test:${rev},
> >> /Users/benson/x/auto-version-maven-extension/src/it/basic/pom.xml,
> >> line 7, column 14
> >> [WARNING]
> >> [WARNING] It is highly recommended to fix these problems because they
> >> threaten the stability of your build.
> >> [WARNING]
> >> [WARNING] For this reason, future Maven versions might no longer
> >> support building such malformed projects.
> >> [WARNING]
> >>
> >>
> >>
> >> On Wed, Mar 9, 2016 at 5:14 PM, Benson Margulies >
> >> wrote:
> >> > Of course, as soon as I hit Send I found out what I screwed up.
> >> >
> >> > On Wed, Mar 9, 2016 at 5:12 PM, Benson Margulies <
> bimargul...@gmail.com>
> >> wrote:
> >> >> I tried this and it didn't work, even a little.
> >> >>
> >> >> See https://github.com/benson-basis/auto-version-maven-extension.
> >> >>
> >> >> My extension is never called, whether I put it into .mvn or the maven
> >> >> home lib/ext directory. (Proved by running mvnDebug, setting a
> >> >> breakpoint, and attaching a debugger).
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Mar 9, 2016 at 3:24 PM, Benson Margulies <
> >> bimargul...@gmail.com> wrote:
> >> >>> On Wed, Mar 9, 2016 at 3:20 PM, Stephen Connolly
> >> >>> wrote:
> >> On Wednesday, 9 March 2016, Benson Margulies <
> bimargul...@gmail.com>
> >> wrote:
> >>
> >> > On Wed, Mar 9, 2016 at 8:51 AM, Tamás Cservenák <
> >> ta...@cservenak.net
> >> > > wrote:
> >> > > I assume it should be this (instead of spy):
> >> > >
> >> http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
> >> > >
> >> > > And instead of starting beer machine, it can inject the
Re: debugging maven-deploy-plugin:deploy-file
I was able to resolve it, after doing a more thorough comparison of the help:effective-settings output. I had to clean out all the noise in the output first. After that I used Emacs and Ediff to do the diff between the two log outputs I had. That's when the following was noticed: Working POM:distributionManagement/repository/id = blah-blah-snapshotS Failing POM: distributionManagement/repository/id = blah-blah-snapshot It helped to look at it in different colours with Emacs/ediff. On a slightly different note, is there a way to get help:effective-settings to only output the effective pom to a log file, rather than using shell re-direct or tee which will capture all the noise as well ? cheers, mehul On Wed, Feb 10, 2016 at 12:11 PM, Mehul Sanghvi wrote: > I was able to manually upload using the following command-line: > > mvn deploy:deploy-file -B -V -s > /path/to/build/dir/maven/settings-unix-buildmachine.xml > -DrepositoryId=SNAPSHOTS-REPO-ID -Durl= > http://internal.nexus.host.com/nexus/content/repositories/snapshots-repo-being-used > -DgeneratePom=true -DgroupId=COM.GROUP.ID -Dversion=1.2.3.4.5-SNAPSHOT > -DartifactId=ARTIFACT-ID -Dfile=ZIP-FILE.zip -Dpackaging=zip > -Dclassifier=linux > > > Using mvn-3.0.5 it took just under 19 minutes to upload the zip file. > Using mvn-3.3.3 it took 22 seconds. > > > So there must be something wrong with the POM file that we are using. I > will try and narrow it down and see what I can find. > > > > On Tue, Feb 9, 2016 at 5:44 PM, Christofer Dutz > wrote: > >> Yeah I can confirm, that I too couldn't find any reference to invalid >> login attempts in my Artifactory logs. >> >> Chris >> >> >> Von: Mehul Sanghvi >> Gesendet: Dienstag, 9. Februar 2016 21:49 >> An: Maven Users List >> Betreff: Re: debugging maven-deploy-plugin:deploy-file >> >> What should I be looking at on the server side ? I have access to it, >> with >> admin privs. >> >> I don't know much about it, and am the admin because the people that set >> it >> up have all left >> the company. I'm "it" by default :) >> >> I looked at nexus.log, but nothing happens when I actually run maven with >> the pom.xml. I have compared >> the help:effective-settings output for the jars-upload vs zip-upload >> profile, and the only difference was >> the profile name. >> >> I am trying to figure out from the server side if there is anything >> configured incorrectly somewhere, or some role/privilege >> that is incorrect, though that doesn't make sense, as its the same user >> writing tot he same repository in both cases. >> >> >> >> >> On Tue, Feb 9, 2016 at 10:40 AM, Christofer Dutz < >> christofer.d...@c-ware.de> >> wrote: >> >> > In my case I'm the only user and admin of the Repo Manager. >> > >> > And I know that I didn't update anything or even log-in to the front end >> > for months now. Also I didn't change anything with my settings.xml >> (even if >> > I thought I had but it turned out that it was in another settings.xml). >> > It's still the same as in one really old backup. >> > >> > I'll hope to find some time to investigate this as I know it will bite >> me >> > pretty soon. >> > >> > Chris >> > >> > >> > Von: anders.g.ham...@gmail.com im Auftrag >> von >> > Anders Hammar >> > Gesendet: Dienstag, 9. Februar 2016 16:27 >> > An: Maven Users List >> > Betreff: Re: debugging maven-deploy-plugin:deploy-file >> > >> > Please keep in mind that there could be authorization rules in the >> > repository manager that gives access to some groupIds but not others, >> for >> > example. You should contact the ones responsible for your repo manager >> > instance and have them help you! >> > >> > /Anders >> > >> > On Tue, Feb 9, 2016 at 4:16 PM, Christofer Dutz < >> christofer.d...@c-ware.de >> > > >> > wrote: >> > >> > > Just to add my 50ct ... I too encountered a similar problem a few days >> > ago >> > > and am still having it. >> > > >> > > While I had a settings.xml that worked fine for ages I got the exact >> same >> > > Unauthorized errors. >> > > At first I thought I had a problem in my settings but I couldn't find >> > one. >&
Re: debugging maven-deploy-plugin:deploy-file
I was able to manually upload using the following command-line: mvn deploy:deploy-file -B -V -s /path/to/build/dir/maven/settings-unix-buildmachine.xml -DrepositoryId=SNAPSHOTS-REPO-ID -Durl= http://internal.nexus.host.com/nexus/content/repositories/snapshots-repo-being-used -DgeneratePom=true -DgroupId=COM.GROUP.ID -Dversion=1.2.3.4.5-SNAPSHOT -DartifactId=ARTIFACT-ID -Dfile=ZIP-FILE.zip -Dpackaging=zip -Dclassifier=linux Using mvn-3.0.5 it took just under 19 minutes to upload the zip file. Using mvn-3.3.3 it took 22 seconds. So there must be something wrong with the POM file that we are using. I will try and narrow it down and see what I can find. On Tue, Feb 9, 2016 at 5:44 PM, Christofer Dutz wrote: > Yeah I can confirm, that I too couldn't find any reference to invalid > login attempts in my Artifactory logs. > > Chris > > ________ > Von: Mehul Sanghvi > Gesendet: Dienstag, 9. Februar 2016 21:49 > An: Maven Users List > Betreff: Re: debugging maven-deploy-plugin:deploy-file > > What should I be looking at on the server side ? I have access to it, with > admin privs. > > I don't know much about it, and am the admin because the people that set it > up have all left > the company. I'm "it" by default :) > > I looked at nexus.log, but nothing happens when I actually run maven with > the pom.xml. I have compared > the help:effective-settings output for the jars-upload vs zip-upload > profile, and the only difference was > the profile name. > > I am trying to figure out from the server side if there is anything > configured incorrectly somewhere, or some role/privilege > that is incorrect, though that doesn't make sense, as its the same user > writing tot he same repository in both cases. > > > > > On Tue, Feb 9, 2016 at 10:40 AM, Christofer Dutz < > christofer.d...@c-ware.de> > wrote: > > > In my case I'm the only user and admin of the Repo Manager. > > > > And I know that I didn't update anything or even log-in to the front end > > for months now. Also I didn't change anything with my settings.xml (even > if > > I thought I had but it turned out that it was in another settings.xml). > > It's still the same as in one really old backup. > > > > I'll hope to find some time to investigate this as I know it will bite me > > pretty soon. > > > > Chris > > > > > > Von: anders.g.ham...@gmail.com im Auftrag > von > > Anders Hammar > > Gesendet: Dienstag, 9. Februar 2016 16:27 > > An: Maven Users List > > Betreff: Re: debugging maven-deploy-plugin:deploy-file > > > > Please keep in mind that there could be authorization rules in the > > repository manager that gives access to some groupIds but not others, for > > example. You should contact the ones responsible for your repo manager > > instance and have them help you! > > > > /Anders > > > > On Tue, Feb 9, 2016 at 4:16 PM, Christofer Dutz < > christofer.d...@c-ware.de > > > > > wrote: > > > > > Just to add my 50ct ... I too encountered a similar problem a few days > > ago > > > and am still having it. > > > > > > While I had a settings.xml that worked fine for ages I got the exact > same > > > Unauthorized errors. > > > At first I thought I had a problem in my settings but I couldn't find > > one. > > > I "resolved" the problem, by disabling the settings.xml and pulling > from > > > maven central instead of my private repo ... but that's not a real > > > resolution. > > > > > > I was also using a pretty recent 3.3.x version (not the 3.3.9 cause it > > > breaks most of my important plugins) > > > My repo is an Artifactory (Haven't updated that for quite some time) > > > > > > As I don't seem to be alone with this eventually I'll use Wireshark > > > investigate what's going over the wire. Mabe this will help find out > > what's > > > going wrong. > > > > > > Chris > > > > > > > > > Von: Mehul Sanghvi > > > Gesendet: Dienstag, 9. Februar 2016 15:02 > > > An: Maven Users List > > > Cc: i...@soebes.de > > > Betreff: Re: debugging maven-deploy-plugin:deploy-file > > > > > > The repositoryId is the same for both. They are getting uploaded to > the > > > same repository. > > > > > > So face I have tested the following: > > >
Re: debugging maven-deploy-plugin:deploy-file
What should I be looking at on the server side ? I have access to it, with admin privs. I don't know much about it, and am the admin because the people that set it up have all left the company. I'm "it" by default :) I looked at nexus.log, but nothing happens when I actually run maven with the pom.xml. I have compared the help:effective-settings output for the jars-upload vs zip-upload profile, and the only difference was the profile name. I am trying to figure out from the server side if there is anything configured incorrectly somewhere, or some role/privilege that is incorrect, though that doesn't make sense, as its the same user writing tot he same repository in both cases. On Tue, Feb 9, 2016 at 10:40 AM, Christofer Dutz wrote: > In my case I'm the only user and admin of the Repo Manager. > > And I know that I didn't update anything or even log-in to the front end > for months now. Also I didn't change anything with my settings.xml (even if > I thought I had but it turned out that it was in another settings.xml). > It's still the same as in one really old backup. > > I'll hope to find some time to investigate this as I know it will bite me > pretty soon. > > Chris > > > Von: anders.g.ham...@gmail.com im Auftrag von > Anders Hammar > Gesendet: Dienstag, 9. Februar 2016 16:27 > An: Maven Users List > Betreff: Re: debugging maven-deploy-plugin:deploy-file > > Please keep in mind that there could be authorization rules in the > repository manager that gives access to some groupIds but not others, for > example. You should contact the ones responsible for your repo manager > instance and have them help you! > > /Anders > > On Tue, Feb 9, 2016 at 4:16 PM, Christofer Dutz > > wrote: > > > Just to add my 50ct ... I too encountered a similar problem a few days > ago > > and am still having it. > > > > While I had a settings.xml that worked fine for ages I got the exact same > > Unauthorized errors. > > At first I thought I had a problem in my settings but I couldn't find > one. > > I "resolved" the problem, by disabling the settings.xml and pulling from > > maven central instead of my private repo ... but that's not a real > > resolution. > > > > I was also using a pretty recent 3.3.x version (not the 3.3.9 cause it > > breaks most of my important plugins) > > My repo is an Artifactory (Haven't updated that for quite some time) > > > > As I don't seem to be alone with this eventually I'll use Wireshark > > investigate what's going over the wire. Mabe this will help find out > what's > > going wrong. > > > > Chris > > > > > > Von: Mehul Sanghvi > > Gesendet: Dienstag, 9. Februar 2016 15:02 > > An: Maven Users List > > Cc: i...@soebes.de > > Betreff: Re: debugging maven-deploy-plugin:deploy-file > > > > The repositoryId is the same for both. They are getting uploaded to the > > same repository. > > > > So face I have tested the following: > > > > 1. verified username/password by logging into the web ui > > > > 2. verified that server id in settings.xml matches the distribution > > repository id in the pom.xml > > > > 3. verified correct settings.xml was being used. I used > > > >mvn help:effective-settings > > > > 4. verified the url is correct and the protocol being used is http and > not > > https > > > > 5. using one of the latest versions of maven i.e. 3.3.3 > > > > > > > > > > > > On Tue, Feb 9, 2016 at 4:03 AM, Adrien Rivard > > wrote: > > > > > Hi, > > > > > > > > > I'm guessing you have a mismatch between the repositories ids you have > at > > > execution and the configured in your settings.xml (where > the > > > username/password are). > > > Probably the repository id for upload-zip stuff is different that the > one > > > for upload-jars? > > > > > > > > > > > > On Tue, Feb 9, 2016 at 1:54 AM, Mehul Sanghvi > > > > wrote: > > > > > > > > > > > > > > > I have attached a copy of the pom.xml that I am using. > > > > > > > > > > > > > > > > On Mon, Feb 8, 2016 at 4:05 AM, Karl Heinz Marbaise < > khmarba...@gmx.de > > > > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> On
Re: debugging maven-deploy-plugin:deploy-file
The repositoryId is the same for both. They are getting uploaded to the same repository. So face I have tested the following: 1. verified username/password by logging into the web ui 2. verified that server id in settings.xml matches the distribution repository id in the pom.xml 3. verified correct settings.xml was being used. I used mvn help:effective-settings 4. verified the url is correct and the protocol being used is http and not https 5. using one of the latest versions of maven i.e. 3.3.3 On Tue, Feb 9, 2016 at 4:03 AM, Adrien Rivard wrote: > Hi, > > > I'm guessing you have a mismatch between the repositories ids you have at > execution and the configured in your settings.xml (where the > username/password are). > Probably the repository id for upload-zip stuff is different that the one > for upload-jars? > > > > On Tue, Feb 9, 2016 at 1:54 AM, Mehul Sanghvi > wrote: > > > > > > > I have attached a copy of the pom.xml that I am using. > > > > > > > > On Mon, Feb 8, 2016 at 4:05 AM, Karl Heinz Marbaise > > wrote: > > > >> Hi, > >> > >> On 2/8/16 6:43 AM, Mehul Sanghvi wrote: > >> > >>> I have a project with multiple modules and sub-modules. Two of the > >>> modules, use > >>> the same maven-deploy-plugin:deploy-file logic, just the artefacts they > >>> are > >>> working > >>> > >> > >> > >> Can you show an example of your deploy-file logic? Cause if you are > >> really using deploy-file goal within your pom file and in your life > cycle > >> there is something wrong... > >> > >> Kind regards > >> Karl Heinz Marbaise > >> > >> with are different. One module uploads designated JARs to Nexus. The > >>> other is > >>> meant for uploading ZIP files. Both are activated only if their > >>> respective > >>> profiles > >>> are activated, -Pupload-jars and -Pupload-zips respectively. Both > >>> modules > >>> share the same settings.xml information regarding repositories and > >>> servers. > >>> > >>> > >>> Upload-jars is able to successfully upload the JARs using deploy-file. > >>> Upload-zips always fails with: > >>> > >>> Return code is: 401, ReasonPhrase:Unauthorized > >>> > >>> How do I figure out the credentials that are being used ? When I use > >>> > >>> mvn -X > >>> > >>> I do not see anything that would indicate what user/passwd combination > is > >>> being used. Any thoughts or suggestions ? > >>> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > -- > Adrien Rivard > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: debugging maven-deploy-plugin:deploy-file
I have attached a copy of the pom.xml that I am using.
On Mon, Feb 8, 2016 at 4:05 AM, Karl Heinz Marbaise
wrote:
> Hi,
>
> On 2/8/16 6:43 AM, Mehul Sanghvi wrote:
>
>> I have a project with multiple modules and sub-modules. Two of the
>> modules, use
>> the same maven-deploy-plugin:deploy-file logic, just the artefacts they
>> are
>> working
>>
>
>
> Can you show an example of your deploy-file logic? Cause if you are really
> using deploy-file goal within your pom file and in your life cycle there is
> something wrong...
>
> Kind regards
> Karl Heinz Marbaise
>
> with are different. One module uploads designated JARs to Nexus. The
>> other is
>> meant for uploading ZIP files. Both are activated only if their
>> respective
>> profiles
>> are activated, -Pupload-jars and -Pupload-zips respectively. Both modules
>> share the same settings.xml information regarding repositories and
>> servers.
>>
>>
>> Upload-jars is able to successfully upload the JARs using deploy-file.
>> Upload-zips always fails with:
>>
>> Return code is: 401, ReasonPhrase:Unauthorized
>>
>> How do I figure out the credentials that are being used ? When I use
>>
>> mvn -X
>>
>> I do not see anything that would indicate what user/passwd combination is
>> being used. Any thoughts or suggestions ?
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Mehul N. Sanghvi
email: mehul.sang...@gmail.com
http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
GROUP.ID
publish-zip-artifacts
ZIP PUBLISH
pom
ORG.GROUP.ID
SOME-ARTIFACT-ID
1.2.3-SNAPSHOT
${project.distributionManagement.snapshotRepository.id}
${project.distributionManagement.snapshotRepository.url}
GROUP.ID
PROFILE-ZIP-UPLOAD
integration-releases
Internal Release Repository
http://nexus.internal.com:8081/nexus/content/repositories/repo-releases
true
integration-snapshot
Internal Snapshot Repository
http://internal.nexus.com:8081/nexus/content/repositories/repo-snapshot
false
org.apache.maven.plugins
maven-deploy-plugin
2.7
deploy-artifact-zip
install
deploy-file
${repositoryId}
${url}
${groupId}
SOME-ARTIFACT
${project.version}
${project.parent.basedir}/path/to/target-${osArch}-${osName}.zip
${release.platform}
true
zip
ORG.GROUP.ID
SOME-ASSEMBLY
${project.version}
pom
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
debugging maven-deploy-plugin:deploy-file
I have a project with multiple modules and sub-modules. Two of the modules, use the same maven-deploy-plugin:deploy-file logic, just the artefacts they are working with are different. One module uploads designated JARs to Nexus. The other is meant for uploading ZIP files. Both are activated only if their respective profiles are activated, -Pupload-jars and -Pupload-zips respectively. Both modules share the same settings.xml information regarding repositories and servers. Upload-jars is able to successfully upload the JARs using deploy-file. Upload-zips always fails with: Return code is: 401, ReasonPhrase:Unauthorized How do I figure out the credentials that are being used ? When I use mvn -X I do not see anything that would indicate what user/passwd combination is being used. Any thoughts or suggestions ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: How to use 5 digit version numbers with Maven ?
Is there documentation on the mercury scheme ? I tried following the link at http://www.mojohaus.org/versions-maven-plugin/version-rules.html, but that just gives me a "Page Not Found". cheers, mehul On Thu, Jan 7, 2016 at 7:27 AM, Robert Patrick wrote: > Yes, you can use the Mercury version numbering scheme for artifacts having > the 5 digit version number. Create a version rules XML file that specifies > which artifacts use Mercury and which artifacts use Maven version schemes. > Pass the file using the versions plugin's rulesUri or > -Dmaven.version.rules... > > > On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi > wrote: > > > > We need to use 5 digit version numbers going forward. Maven only > handles 3 > > digit version numbers > > using the versions-maven-plugin. Is there a way to use 5 digits for > > project.version ? > > > > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and > > 1.2.3.4.5 vs 1.2.3 after > > the release. > > > > > > > > cheers, > > > > mehul > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
How to use 5 digit version numbers with Maven ?
We need to use 5 digit version numbers going forward. Maven only handles 3 digit version numbers using the versions-maven-plugin. Is there a way to use 5 digits for project.version ? What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and 1.2.3.4.5 vs 1.2.3 after the release. cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: errors when using release:update-versions
Karl, Thanks for the information. Based on your response, it seems that I have specify the SCM in order to use maven-release-plugin. I have also found the versions-maven-plugin, which seems to do what I want it to do, without using the SCM from maven. There are plenty of other files that I need to update as part of the version change, and I don't want to have multiple change lists for it. As for the ancient version of the release plugin, I'll update the version information in the next development cycle. cheers, mehul On Mon, Oct 5, 2015 at 12:24 PM, Karl Heinz Marbaise wrote: > Hi, > > > On 10/5/15 6:19 PM, Mehul Sanghvi wrote: > >> I am trying to use the following: >> >> mvn -V -B release:update-versions >> -DdevelopmentVersion=1.2.3.4-SNAPSHOT >> >> and it keeps coming back with the following: >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-release-plugin:2.0:update-versions >> > > First you are using an ancient version of the > maven-release-plugin[2]you should define the version by using a > pluginManagement in a corporate pom file... > > > (default-cli) on project FUBAR: Missing required setting: scm connection or >> developerConnection must be specified. >> >> We do not use the maven scm plugin. The POMs are all checked out locally >> on my system, and ready for editing. So why is it complaining about the >> scm connection and developerConnection ? >> >> I tried to google and read the documents, but I am most likely missing >> someting in my interpretation of things. >> > > > You have to define the scm connection[1] information into your pom's: > > for example like this: > > > scm:svn:http://127.0.0.1/svn/my-project > > scm:svn:https://127.0.0.1/svn/my-project > > > > If you like to use maven-release-plugin you have to define those > informations in the pom file. > > [1]: https://maven.apache.org/pom.html#SCM > [2]: http://maven.apache.org/maven-release/maven-release-plugin/ > > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
errors when using release:update-versions
I am trying to use the following: mvn -V -B release:update-versions -DdevelopmentVersion=1.2.3.4-SNAPSHOT and it keeps coming back with the following: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:update-versions (default-cli) on project FUBAR: Missing required setting: scm connection or developerConnection must be specified. We do not use the maven scm plugin. The POMs are all checked out locally on my system, and ready for editing. So why is it complaining about the scm connection and developerConnection ? I tried to google and read the documents, but I am most likely missing someting in my interpretation of things. cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
maven.config file and variable substitution
Maven 3.3.1 introduces a ${maven.projectBaseDir}/.mvn/maven.config file
where I can specify common command line options. How do I use variables in
that ? Specifically if I'm trying to set the settings file to be something
like ${maven.projectBaseDir}/settings.xml, how would I set that in
maven.config ?
Currently I pass a -s${Bamboo.WorkingDir}/settings.xml option to the as
part of the automated builds. When I run the builds manually on my laptop
I have to pass something like
-s${HOME}/path/to/project/root/dir/settings.xml. And if I'm trying run it
manually on the build system, I had to pass something like
-s/path/to/Bamboo/build/working/dir/settings.xml.
Using maven.config would help tremendously, but it does not seem to
understand ${maven.projectBaseDir}.
I have a maven.config that contains the following:
-B -V -s ${maven.projectBaseDir}/settings.xml
I get the following error when I try to build:
bash% cd ${HOME}/source-repos/ProjectA
bash% mvn clean install
[ERROR] The specified user settings file does not exist:
/home/mehul/source-repos/ProjectA/${maven.projectBaseDir}/settings.xml
Shouldn't Maven substitute the value of the ${maven.projectBaseDir}
variable ?
cheers,
mehul
--
Mehul N. Sanghvi
email: mehul.sang...@gmail.com
local repository permissions
How can I get maven to create directories and files with world writeable permissions when it is downloading or installing to the local ~/.m2 repository ? -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
That is certainly something that my bosses will look to. On Tue, Jun 3, 2014 at 5:37 PM, Dan Tran wrote: > Perhaps Artifactory is cheaper and support repos like NPM? > > 100$ per seat for nexus professional is way expensive? :-) > > -D > > > On Tue, Jun 3, 2014 at 1:10 PM, Glenn Brown > wrote: > > > My question was what use case was making you think of no longer using > > nexus? > > > > > > On Tue, Jun 3, 2014 at 3:05 PM, Manfred Moser > > wrote: > > > > > The majority of developers seem to be using Nexus according to > > > > > > > > > > > > http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/ > > > > > > Slides 2 and 19 > > > > > > manfred > > > > > > PS: I am part of the Nexus team.. but was not involved in that survey. > > > > > > Glenn Brown wrote on 03.06.2014 12:22: > > > > > > > I would not recommend Archiva. It's intended to be mainly a reference > > > > implementation of the repository and, personally, i find it's UI to > be > > a > > > > bit clunky. Whats moving you off Nexus? > > > > > > > > > > > > On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi < > mehul.sang...@gmail.com > > > > > > > wrote: > > > > > > > >> Hit the reply button too quickly on the previous one. > > > >> > > > >> I did not expect a full review and comparison of the systems plus a > > > >> migration guide. I was more looking for gotchas that people may have > > run > > > >> into when doing a migration and/or what they took into account when > > > >> choosing a system. I will take Dan's suggestion to search the mail > > > >> archives, and see what I find there, and if I need to, will send out > > > >> another email > > > >> and be more specific next time around. > > > >> > > > >> > > > >> cheers, > > > >> > > > >> mehul > > > >> > > > >> > > > >> > > > >> On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch < > > > >> alexan...@kriegisch.name> wrote: > > > >> > > > >> > With all due respect: Can you ask in an even more general way? You > > do > > > not > > > >> > expect someone to write a full review and comparison of those > > systems > > > >> plus > > > >> > migration guide for you, do you? For such general information > there > > > are > > > >> web > > > >> > search engines and tutorials. > > > >> > > > > >> > Constructive hint: Maybe if you explain which concrete problems or > > > >> > shortcomings you see in Nexus OSS, why you consider migration and > > what > > > >> you > > > >> > want to achieve with the migration, someone will be glad to help > > you. > > > >> > > > > >> > I do not mean to be rude, but this is not a very smart way to ask > a > > > >> > question on any mailing list. > > > >> > -- > > > >> > Alexander Kriegisch > > > >> > > > > >> > > > > >> > > Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi < > > > mehul.sang...@gmail.com > > > >> >: > > > >> > > > > > >> > > Currently we are using Nexus OSS version. I am leaning toward > > > Archiva, > > > >> > but > > > >> > > there is also > > > >> > > Artifactory. > > > >> > > > > > >> > > > > > >> > > What is involved if we were to migrate from Nexus to one of the > > > others > > > >> ? > > > >> > > Do the repository URLs > > > >> > > change ? Or the layout ? > > > >> > > > > > >> > > What do people recommend ? Why ? > > > >> > > > > > >> > > > > > >> > > cheers, > > > >> > > > > > >> > > mehul > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Mehul N. Sanghvi > > > >> > > email: mehul.sang...@gmail.com > > > >> > > > > >> > > > - > > > >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > >> > For additional commands, e-mail: users-h...@maven.apache.org > > > >> > > > > >> > > > > >> > > > >> > > > >> -- > > > >> Mehul N. Sanghvi > > > >> email: mehul.sang...@gmail.com > > > >> > > > > > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
There isn't any particular reason for moving off of Nexus. We have Nexus as its the most common repository manager used. I want to do an evaluation before we make the decision to go with one or the other and whether to get the paid version or stick to the free version. Archiva, Artifactory, and Nexus are my choices. Part of the evaluation will be to take a look at our processes, see where and how we can leverage a repository manager. Currently we use something that was written internally earlier this century, in JHTML and JSP, which hasn't been updated since and is difficult to update and maintain. I want to modernise by shifting things away from the home grown solution. We've got groups using Ant, Maven, and homegrown Perl based build tools, and Make, and I have no idea what else is lurking out there. Some of those will need ways to upload to the repository manager. That's the back story to it. On Tue, Jun 3, 2014 at 3:22 PM, Glenn Brown wrote: > I would not recommend Archiva. It's intended to be mainly a reference > implementation of the repository and, personally, i find it's UI to be a > bit clunky. Whats moving you off Nexus? > > > On Tue, Jun 3, 2014 at 1:40 PM, Mehul Sanghvi > wrote: > > > Hit the reply button too quickly on the previous one. > > > > I did not expect a full review and comparison of the systems plus a > > migration guide. I was more looking for gotchas that people may have run > > into when doing a migration and/or what they took into account when > > choosing a system. I will take Dan's suggestion to search the mail > > archives, and see what I find there, and if I need to, will send out > > another email > > and be more specific next time around. > > > > > > cheers, > > > > mehul > > > > > > > > On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch < > > alexan...@kriegisch.name> wrote: > > > > > With all due respect: Can you ask in an even more general way? You do > not > > > expect someone to write a full review and comparison of those systems > > plus > > > migration guide for you, do you? For such general information there are > > web > > > search engines and tutorials. > > > > > > Constructive hint: Maybe if you explain which concrete problems or > > > shortcomings you see in Nexus OSS, why you consider migration and what > > you > > > want to achieve with the migration, someone will be glad to help you. > > > > > > I do not mean to be rude, but this is not a very smart way to ask a > > > question on any mailing list. > > > -- > > > Alexander Kriegisch > > > > > > > > > > Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi < > mehul.sang...@gmail.com > > >: > > > > > > > > Currently we are using Nexus OSS version. I am leaning toward > Archiva, > > > but > > > > there is also > > > > Artifactory. > > > > > > > > > > > > What is involved if we were to migrate from Nexus to one of the > others > > ? > > > > Do the repository URLs > > > > change ? Or the layout ? > > > > > > > > What do people recommend ? Why ? > > > > > > > > > > > > cheers, > > > > > > > > mehul > > > > > > > > > > > > -- > > > > Mehul N. Sanghvi > > > > email: mehul.sang...@gmail.com > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
Hit the reply button too quickly on the previous one. I did not expect a full review and comparison of the systems plus a migration guide. I was more looking for gotchas that people may have run into when doing a migration and/or what they took into account when choosing a system. I will take Dan's suggestion to search the mail archives, and see what I find there, and if I need to, will send out another email and be more specific next time around. cheers, mehul On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch < alexan...@kriegisch.name> wrote: > With all due respect: Can you ask in an even more general way? You do not > expect someone to write a full review and comparison of those systems plus > migration guide for you, do you? For such general information there are web > search engines and tutorials. > > Constructive hint: Maybe if you explain which concrete problems or > shortcomings you see in Nexus OSS, why you consider migration and what you > want to achieve with the migration, someone will be glad to help you. > > I do not mean to be rude, but this is not a very smart way to ask a > question on any mailing list. > -- > Alexander Kriegisch > > > > Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi : > > > > Currently we are using Nexus OSS version. I am leaning toward Archiva, > but > > there is also > > Artifactory. > > > > > > What is involved if we were to migrate from Nexus to one of the others ? > > Do the repository URLs > > change ? Or the layout ? > > > > What do people recommend ? Why ? > > > > > > cheers, > > > > mehul > > > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Maven repository management systems
Points well taken. No offence taken. :) On Tue, Jun 3, 2014 at 1:49 PM, Alexander Kriegisch < alexan...@kriegisch.name> wrote: > With all due respect: Can you ask in an even more general way? You do not > expect someone to write a full review and comparison of those systems plus > migration guide for you, do you? For such general information there are web > search engines and tutorials. > > Constructive hint: Maybe if you explain which concrete problems or > shortcomings you see in Nexus OSS, why you consider migration and what you > want to achieve with the migration, someone will be glad to help you. > > I do not mean to be rude, but this is not a very smart way to ask a > question on any mailing list. > -- > Alexander Kriegisch > > > > Am 03.06.2014 um 18:55 schrieb Mehul Sanghvi : > > > > Currently we are using Nexus OSS version. I am leaning toward Archiva, > but > > there is also > > Artifactory. > > > > > > What is involved if we were to migrate from Nexus to one of the others ? > > Do the repository URLs > > change ? Or the layout ? > > > > What do people recommend ? Why ? > > > > > > cheers, > > > > mehul > > > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Maven repository management systems
Currently we are using Nexus OSS version. I am leaning toward Archiva, but there is also Artifactory. What is involved if we were to migrate from Nexus to one of the others ? Do the repository URLs change ? Or the layout ? What do people recommend ? Why ? cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Nexus / Maven repository artifact handling
Jason, William, Thanks for the clarifications. The information will certainly help in setting up for the next release cycle. cheers, mehul On Tue, Jun 3, 2014 at 12:29 AM, William Ferguson < william.fergu...@xandar.com.au> wrote: > Mehul, this is the wrong pattern to use. It goes against the entire Maven > dependency mechanism. > > Each GAV (aside from snapsghots) should represent a unique build. > > You should be creating new RC GAVs for each release candidate. eg > groupX-artifactX-versionZ.rc1 > > William > > > > On Tue, Jun 3, 2014 at 12:27 PM, Mehul Sanghvi > wrote: > > > We use SNAPSHOT during development, say 1.1.0-SNAPSHOT. At code freeze, > we > > branch off from main line to a version specific branch and remove > SNAPSHOT > > from the version string, so it becomes 1.1.0. Between code freeze and > > release we have RC builds. Its at that point that when a newer build of > > the same artifact is uploaded, so the GAV is identical, > > maven will not download the newest build. So its the same JAR file being > > uploaded, with the same version. The only thing changing is the file > size > > and time stamp of the uploaded > > artifact. > > > > So I have fubar-1.1.0.jar uploaded to Nexus. The consumer picks up this > > jar file and downloads to ~/.m2. Now we find some problems with it, and > > there is an update. So a newer > > fubar-1.1.0.jar is uploaded, over-writing the old one. Then next time a > > build of the consuming project is run, it does not download the newly > built > > fubar-1.1.0.jar. Based on what > > you're saying, this is a feature and the right way to do things, correct > ? > > > > > > Than, how do folks handle RC versions ? > > > > > > > > cheers, > > > > mehul > > > > > > > > > > > > On Mon, Jun 2, 2014 at 6:54 PM, Jason van Zyl wrote: > > > > > Are you deploying different artifacts with the same version? Release > > > versions are expected to be immutable and Maven will not try to > download > > a > > > released artifact again because it's not expected to change. If you are > > > deploying different artifacts using the same version you are using > Maven > > > incorrectly. > > > > > > On Jun 2, 2014, at 6:06 PM, mehul.sang...@gmail.com wrote: > > > > > > > > > > > We have a Nexus server to which various projects upload artifacts. > > > > The artifacts are uploaded to a release repository, not a snapshot > > > repository. > > > > > > > > One project is just a consumer of the artifacts. It does not upload > > > anything. > > > > > > > > Even though we have an updated artifact available, the consuming > > project > > > does not download the artifacts from nexus until we clear out the local > > > repo in ~/.m2. > > > > > > > > How does Nexus / Maven determine that a new artifact needs to be > > > downloaded from the remote repo? The timestamp reflects the time of > > upload > > > of the artifact. So what am I missing ? > > > > > > > > The GAV is of the form: > > > > > > > > group:artifact.id:group.artifact.id-11.1.0.jar > > > > > > > > When a new group.artifact.id-11.1.0.jar is uploaded, it won't get > > > downloaded by the consuming project. > > > > > > > > > > > > cheers, > > > > > > > > mehul > > > > > > > > -- > > > > Sent from my "smart" phone > > > > > > > > > > > > > > Thanks, > > > > > > Jason > > > > > > -- > > > Jason van Zyl > > > Founder, Apache Maven > > > http://twitter.com/jvanzyl > > > http://twitter.com/takari_io > > > - > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: Nexus / Maven repository artifact handling
We use SNAPSHOT during development, say 1.1.0-SNAPSHOT. At code freeze, we branch off from main line to a version specific branch and remove SNAPSHOT from the version string, so it becomes 1.1.0. Between code freeze and release we have RC builds. Its at that point that when a newer build of the same artifact is uploaded, so the GAV is identical, maven will not download the newest build. So its the same JAR file being uploaded, with the same version. The only thing changing is the file size and time stamp of the uploaded artifact. So I have fubar-1.1.0.jar uploaded to Nexus. The consumer picks up this jar file and downloads to ~/.m2. Now we find some problems with it, and there is an update. So a newer fubar-1.1.0.jar is uploaded, over-writing the old one. Then next time a build of the consuming project is run, it does not download the newly built fubar-1.1.0.jar. Based on what you're saying, this is a feature and the right way to do things, correct ? Than, how do folks handle RC versions ? cheers, mehul On Mon, Jun 2, 2014 at 6:54 PM, Jason van Zyl wrote: > Are you deploying different artifacts with the same version? Release > versions are expected to be immutable and Maven will not try to download a > released artifact again because it's not expected to change. If you are > deploying different artifacts using the same version you are using Maven > incorrectly. > > On Jun 2, 2014, at 6:06 PM, mehul.sang...@gmail.com wrote: > > > > > We have a Nexus server to which various projects upload artifacts. > > The artifacts are uploaded to a release repository, not a snapshot > repository. > > > > One project is just a consumer of the artifacts. It does not upload > anything. > > > > Even though we have an updated artifact available, the consuming project > does not download the artifacts from nexus until we clear out the local > repo in ~/.m2. > > > > How does Nexus / Maven determine that a new artifact needs to be > downloaded from the remote repo? The timestamp reflects the time of upload > of the artifact. So what am I missing ? > > > > The GAV is of the form: > > > > group:artifact.id:group.artifact.id-11.1.0.jar > > > > When a new group.artifact.id-11.1.0.jar is uploaded, it won't get > downloaded by the consuming project. > > > > > > cheers, > > > > mehul > > > > -- > > Sent from my "smart" phone > > > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > - > > > > > > > > > > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
maven-install-plugin:install - naming the installed artifact
Hi, Below is the output of the maven-install-plugin being executed. What do I have to do so that I can specify the name of the installed artifact ? If you look at line 26, the artifact got renamed to mandrage-module-rpm-1.4.0-bin.rpm and that is not the name that it should have. The name should be the same as the source. 24: [2012-04-03_18-05-16] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ mandrake-module-rpm --- 25: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/pom.xml to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0.pom 26: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/target/rpm/mandrake_20120403_180515-bin/RPMS/noarch/mandrake_20120403_180515-1.4.0-20120403_180515.noarch.rpm to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0-bin.rpm 27: [2012-04-03_18-05-16] [INFO] Installing /opt/jenkins/slave/workspace/build-mandrake-master/mandrake-module-rpm/target/rpmversion.properties to /opt/maven-cache/mandrake-master/repository/com/constantcontact/apps/mandrake/mandrake-module-rpm/1.4.0/mandrake-module-rpm-1.4.0-rpmversion.properties 28: [2012-04-03_18-05-16] [INFO] cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
