-was-not-specified-in-the-pom-inside-distributionmanagement-el/39439911
So, I read up the below:
https://maven.apache.org/pom.html#Distribution_Management
My question is since I am doing this on a stand alone basis and do not need to
share the POM denpendencies, how do I get rid of this message
-distributionmanagement-el/39439911
So, I read up the below:
https://maven.apache.org/pom.html#Distribution_Management
My question is since I am doing this on a stand alone basis and do not need to
share the POM denpendencies, how do I get rid of this message?
With Spring-boot, it is very easy I
Yep, that is one of the many pages I had looked at also. I was also
considering the stage-deploy target as I think that actually does have a
property for URL, but was not sure what other side affects it would have
since it might be deemed a mis-use of that feature. I need to
understand it a
Hello Robert,
reading the information at
https://maven.apache.org/plugins/maven-site-plugin/deploy-mojo.html I
do not think there is an easy way to do this and probably never will
be.
1) AFAIK there is no (central) server available which hosts sites by default.
2) As stated on above page, there a
So is there an equivalent to altReleaseDeploymentRepository and
altSnapshotDeploymentRepository for the Site Deployment information
also? Since all three are in the Distribution Management directive, I
was hoping I could define this last one in the settings.xml also.
Robert Kuropkat
On 03
Actually, I did set these properties up in my settings.xml file :-)
Great minds think alike ;-)
Cheers, Eric
On 3/19/2014 3:53 PM, Mark Struberg wrote:
You could also add those properties into a profile in your settings.xml. That
way you don't even have the url in the projects pom anymore.
Do
You could also add those properties into a profile in your settings.xml. That
way you don't even have the url in the projects pom anymore.
Downside: this needs to be set up on each of your colleagues computers.
LieGrue,
strub
On Wednesday, 19 March 2014, 23:16, Eric Kolotyluk
wrote:
OK,
OK, this was great advice. :-)
This works nicely because I do not have to have separate profiles in my
pom.xml for my local Nexus or Sonatype's remote one. This keeps the
pom.xml smaller.
This would be a nice narrative to add to
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven
Hello Eric,
as outlined in
https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
in your settings.xml you might define properties
altReleaseDeploymentRepository and altSnapshotDeploymentRepository in
a profile internal-repository which is activated by default while you
do not defi
Hello Eric,
I'd consider using Sonatype OSS with Sonatype OSS parent pom and everything
that goes along (see more details at
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide)
For OSS development maybe use private (and not local) Nexus as proxy only,
with mirro
Hi Eric,
> Should I put this in a parent POM
Here is how my projects do it:
http://search.maven.org/remotecontent?filepath=org/scijava/pom-scijava/1.150/pom-scijava-1.150.pom
Note in particular the profiles at the bottom.
We use this pom-scijava as parent for all our stuff. To deploy to OSS
Son
Does anyone know of any good documentation on 'Open Source Best
Practices with Maven'
For example, in my POM, I want to set up
http://localhost:8081/nexus/content/groups/public
false
nexus-kolotyluk
Local Release Repository
http://localhost:8081/nexus/content/repositor
rds Mirko
>
> On Sun, Apr 29, 2012 at 21:22, Olivier Lamy wrote:
> > Yup you can add properties to project.getProperties()
> > But in your case you want to change distributionManagement urls using
> > properties interpolation mechanism ? but it's too late using a plugi
change distributionManagement urls using
> properties interpolation mechanism ? but it's too late using a plugin
> as model has been build.
>
> An option you have maybe it's to use maven3 lifecycle extension
> mechanism: http://maven.apache.org/examples/maven-3-lifecycle-extensions.html
&
Yup you can add properties to project.getProperties()
But in your case you want to change distributionManagement urls using
properties interpolation mechanism ? but it's too late using a plugin
as model has been build.
An option you have maybe it's to use maven3 lifecycle extension
ame of the property is inserted. I may access the calculated property
>> > and insert it into Could anybody tell me in which phase the urls in
>> > distributionManagement are resolved?
>> >
>> > Regards Mirko
>> >
>> > ---
> > validate phase and want to use it as part of the
> > snapshotRepository/url. However the property is not resolved but the
> > name of the property is inserted. I may access the calculated property
> > and insert it into Could anybody tell me in which phase th
ry/url. However the property is not resolved but the
> name of the property is inserted. I may access the calculated property
> and insert it into Could anybody tell me in which phase the urls in
> distributionManagement are res
release:perform will fail if is not set.
Shouldn't release:prepare check for this field and fail it it's not set?
Regards,
Daniel Serodio
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-
m: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Sent: Wednesday, March 28, 2012 8:42 AM
To: Maven Users List
Subject: Re: There is a way to override distributionManagement in Maven
and what is exactly wrong with
mvn -DaltDeploymentRepository=id::default::url deploy
?
no change to pom re
d "goodness" has the ability to creep up on us during production
> builds.
>
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Wednesday, March 28, 2012 2:45 AM
> To: Maven Users List
> Subject: Re: There is a way
2 2:45 AM
To: Maven Users List
Subject: Re: There is a way to override distributionManagement in Maven
Take a step back and try and explain exactly what the problem is that you think
you are trying to solve.
I have a sneaky feeling you are trying to get functionality similar to
staging/promotion avai
One possibility is to use properties in the distributionMgmt section
and then override the property values from command line. Have a look
at how this is done in the Apache parent pom (for snapshotRepository
distribution):
http://repo.maven.apache.org/maven2/org/apache/apache/10/apache-10.pom
/Ande
Take a step back and try and explain exactly what the problem is that you
think you are trying to solve.
I have a sneaky feeling you are trying to get functionality similar to
staging/promotion available from the good repository managers (iirc nexus
free does not, but nexus pro and artifactory cer
Hello Maven users,
I have a project master pom.xml with a distribution management section defined
like this:
one
Blah Managed Releases Repository
http://:8080/archiva/repository/one/
default
snapshots
Blah Managed Snapshots Repository
He is talking about apache ivy I think
http://ant.apache.org/ivy/history/2.0.0/use/makepom.html
On Sun, Jun 26, 2011 at 4:25 AM, Aldrin Leal wrote:
> I am not sure what makepom is, so I went to google. It seems likely an Ivy
> Question
>
> With regards to distributionManag
t facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> Date: Sun, 26 Jun 2011 06:25:40 -0300
> Subject: Re: distributionManagement
> From: ald...@leal.eng.br
> To: users@maven.apache.org
>
> I am not sure what makepom
probably why distribution management is not part of the output
from the utility that you are using.
Ron
On 26/06/2011 5:25 AM, Aldrin Leal wrote:
I am not sure what makepom is, so I went to google. It seems likely an Ivy
Question
With regards to distributionManagement: It is optional
I am not sure what makepom is, so I went to google. It seems likely an Ivy
Question
With regards to distributionManagement: It is optional
--
-- Aldrin Leal, / http://www.leal.eng.br/mnemetica/
On Sun, Jun 26, 2011 at 6:03 AM, Brosh, Yossi wrote:
>
> Hi to all,
>
> I would lik
Hi to all,
I would like to know if distributionManagement tag should be exist in pom.xml ?
I am using makepom command - so who can I adding this distributionManagement
tag to pom.xml ?
Best regards,
Yos
gt; 2012 NM Haarlem
> T +31 23 547 6369
> F +31 23 547 6370
> I www.iprofs.nl
>
>
>
> On Thu, Jun 23, 2011 at 3:44 PM, Rick Mangi wrote:
>> Hello Maven Users,
>>
>> I'm trying to migrate my users to a new nexus repository on a different
>> domain.
On Thu, Jun 23, 2011 at 9:44 AM, Rick Mangi wrote:
> I'm trying to migrate my users to a new nexus repository on a different
> domain. I'm trying to avoid having to tell all of the developers to change
> their distributionManagement/repository and /snapshotRepository values i
> domain. I'm trying to avoid having to tell all of the developers to change
> their distributionManagement/repository and /snapshotRepository values in
> their pom files or to upgrade to new parent poms all at once. They can do it
> over time, but we support hundreds of developer
Hello Maven Users,
I'm trying to migrate my users to a new nexus repository on a different
domain. I'm trying to avoid having to tell all of the developers to change
their distributionManagement/repository and /snapshotRepository values in
their pom files or to upgrade to new parent p
distributionManagement is the target for the Maven artifacts.
release:perform calls deploy as default, and deploy needs the
distributionManagement. If you do not want this (e.g. only install the
Maven artifact in the local repository), then you have to do something
like this:
maven-release
=scm:svn:https://svn.vis.ethz.ch/svn/webengineering/trunk
-DtagBase=file:Users/bravegag/code/webengineering/tags
So I don't understand why is needed yet another way to specify the
repository. AFAIK distributionManagement is used to specify the target of
the project report and web site but I don&#
bravegag wrote:
> Hello,
>
> I have a project for which I do not really need a site or for that matter a
> distributionManagement ... is there a way to successfully release i.e.
> branch out etc etc without having to specify a distributionManagement?
>
> TIA,
> Best regards
Hello,
I have a project for which I do not really need a site or for that matter a
distributionManagement ... is there a way to successfully release i.e.
branch out etc etc without having to specify a distributionManagement?
TIA,
Best regards,
Giovanni
--
View this message in context:
http
Thanks for your reply.
I re-checked and the problem was because the pom version was a release
but the parent pom defined a snapshot repository.
-Original Message-
From: Anders Hammar
To: iapazm...@sri.gob.ec, Maven Users List
Subject: Re: Inheritance of distributionManagement
Date: Mon
Do the module projects declare a parent, from which the distMgmt will be
inherited?
/Anders (mobile)
Den 2010 11 29 16:27 skrev "Pazmiño Mazón, Iván Andrés" :
> Hi,
>
> I'm having problems with a composite maven 2 project. I have set up a
> base project which carries the configuration.
> When it'
Hi,
I'm having problems with a composite maven 2 project. I have set up a
base project which carries the configuration.
When it's extended by another project without modules it works just
fine.
But now I happened to need to extend the base project from another
project which has some modules decl
On Thu, Oct 7, 2010 at 11:34 AM, Benson Margulies wrote:
> This conversation turns on a classic dilemma in release management.
>
> 1. The important thing is to ship exactly the bits that have been
> tested. Prepare a package, give it to QA. If they like it, ship it. If
> they don't, rinse, lather,
This conversation turns on a classic dilemma in release management.
1. The important thing is to ship exactly the bits that have been
tested. Prepare a package, give it to QA. If they like it, ship it. If
they don't, rinse, lather, and repeat.
2. The important thing is to never, ever, ever create
> Why would the package change? Were' using the assembly plugin to
> create a zip of the binaries (dlls, libs, and headers). Why should
> that change if the code it's built from hasn't changed?
The names of the artifacts would change. The meta data used to retrieve the
artifacts is also differe
somethign that occurrs to me...
Take a step back and look at your processes... what determines when a build
goes to QA? Look for a way to have that trigger a "mvn release" which will
push the build to your release repo
On Thu, Oct 7, 2010 at 10:26 AM, Phillip Hellewell wrote:
> On Thu, Oct 7, 2
On Thu, Oct 7, 2010 at 11:08 AM, Thiessen, Todd (Todd)
wrote:
>> So this is one aspect where our setup will differ slightly. We don't
>> need the release plugin to create tags for us because our build
>> scripts on our build machines are already set up to create tags with
>> every single build (e
On Thu, Oct 7, 2010 at 10:43 AM, Thiessen, Todd (Todd)
wrote:
>
>> But the main thing I'm thinking about is the fact that the package
>> hasn't changed. So why should I have to rebuild the code?
>
> But it has changed. Very much so. A SNAPSHOT is not a release.
Why would the package change? Wer
> So this is one aspect where our setup will differ slightly. We don't
> need the release plugin to create tags for us because our build
> scripts on our build machines are already set up to create tags with
> every single build (even snapshots builds).
I think we may be getting to crux of your.
On Thu, Oct 7, 2010 at 7:06 AM, Thiessen, Todd (Todd)
wrote:
>> Yeah, I'll just keep it pretty simple like this, however it will be
>> even simpler because our build process will append the SVN tag name,
>> so we won't ever need to manually add like "01", "02", "03", etc.
>
> What are you using as
> But the main thing I'm thinking about is the fact that the package
> hasn't changed. So why should I have to rebuild the code?
But it has changed. Very much so. A SNAPSHOT is not a release.
> That not
> only wastes time but more importantly it adds risks that the build may
> not be identical
On Thu, Oct 7, 2010 at 6:51 AM, Thiessen, Todd (Todd)
wrote:
> Bingo. I was just about to reply to say that. You generally never go from a
> SNAPSHOT to release as the way the artifacts are generated are very
> different. Not only are the names of the artifacts themselves different but
> the me
> Yeah, I'll just keep it pretty simple like this, however it will be
> even simpler because our build process will append the SVN tag name,
> so we won't ever need to manually add like "01", "02", "03", etc.
What are you using as the SVN tag name? The release plugin will create the tag
for you f
rs List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> > Well, at this point all I'm mainly after is the ability to copy an
> > artifact from snapshot to release repo (removing -SNAPSHOT from the
> > version) without having to go through th
> Well, at this point all I'm mainly after is the ability to copy anartifact
> from snapshot
> to release repo (removing -SNAPSHOT from theversion) without having to go
> through
> the rebuild process.
> If thatfunctionality does not exist as a free plugin or anything at
> themoment,
> who kn
aven Users List
Sent: Wed, Oct 6, 2010 11:31 pm
Subject: Re: Can't specify distributionManagement in settings.xml
On Wed, Oct 6, 2010 at 1:57 PM, Anders Hammar wrote:
> Philip, have a look at the staging feature of Nexus Pro. That's what you
> want. I believe I already said thi
> Well, at this point all I'm mainly after is the ability to copy an
> artifact from snapshot to release repo (removing -SNAPSHOT from the
> version) without having to go through the rebuild process. If that
As Vincent already stated, this is harder than it initially appears
for most builds as th
On Wed, Oct 6, 2010 at 4:19 PM, Thiessen, Todd (Todd)
wrote:
> What you are asking for definitely is not recommended. The release plugin
> already has a "staging" feature but it is not the recommended way to do.
Good to know, thanks.
> Putting a "staging" build into the release repo is not reco
: Wednesday, October 06, 2010 5:51 PM
> To: Maven Users List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> On Wed, Oct 6, 2010 at 2:04 PM, Ron Wheeler
> wrote:
> > On 06/10/2010 3:42 PM, Phillip Hellewell wrote:
> >>
> >> If I deplo
In Maven/Nexus terminology, you deploy a release candidate to a staging area
(#2) in your example. This artifact (or group of artifacts) is then made
available to a group of people for validation (it can be automated or
manual). Once it's validated it is promoted and copied to the release
repositor
On Wed, Oct 6, 2010 at 3:50 PM, Phillip Hellewell wrote:
>
> No, there are basically there types of builds I want to do. Most
> people don't have a stage between snapshot and release, so I'm
> guessing that is why I am not getting any clear direction about the
> best way to do this.
> 1. A snapsh
On Wed, Oct 6, 2010 at 2:04 PM, Ron Wheeler
wrote:
> On 06/10/2010 3:42 PM, Phillip Hellewell wrote:
>>
>> If I deploy non-snapshot builds to the snapshot repository first
>
> How. I do not think that this can be done.
I asked earlier if non-snapshot builds can be deployed to a snapshot
reposito
On Wed, Oct 6, 2010 at 3:34 PM, Thiessen, Todd (Todd)
wrote:
> Err mean to say "Write a plugin for Nexus". Bah sorry. Hate it when I make
> typos like that. Reply too fast. ;-)
The file structure of a repository seems to make it look like copying
artifacts is almost trivial.
Phillip
--
ubject: RE: Can't specify distributionManagement in settings.xml
>
> Why a plugin for the open source version of nexus. I'd bet it isn't quite
> as straight forward as you might think ;-)
>
> > -Original Message-
> > From: Phillip Hellewell [mailto
ubject: Re: Can't specify distributionManagement in settings.xml
>
> On Wed, Oct 6, 2010 at 1:57 PM, Anders Hammar wrote:
> > Philip, have a look at the staging feature of Nexus Pro. That's what
> you
> > want. I believe I already said this...
>
> Thanks.
On Wed, Oct 6, 2010 at 2:00 PM, Thiessen, Todd (Todd)
wrote:
> Phil. I think you just need to try it and read the Nexus docs. Sounds like
> you are really making things complicated for yourself.
Yeah, you are probably right.
Phillip
On Wed, Oct 6, 2010 at 1:57 PM, Anders Hammar wrote:
> Philip, have a look at the staging feature of Nexus Pro. That's what you
> want. I believe I already said this...
Thanks. I wonder if there are any free alternatives that provide this
functionality. You'd think you wouldn't have to pay for
On 06/10/2010 3:42 PM, Phillip Hellewell wrote:
On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
wrote:
No worries. I've already got Nexus installed (just dropped the WAR
into Tomcat; almost too easy). I just haven't played with it enough
yet to make sure it can do everything I need it to (like
gt; Subject: Re: Can't specify distributionManagement in settings.xml
>
> On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
> wrote:
> >>
> >> No worries. I've already got Nexus installed (just dropped the WAR
> >> into Tomcat; almost too easy). I just
Philip, have a look at the staging feature of Nexus Pro. That's what you
want. I believe I already said this...
/Anders
On Wed, Oct 6, 2010 at 21:42, Phillip Hellewell wrote:
> On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
> wrote:
> >>
> >> No worries. I've already got Nexus installed (just dr
On Wed, Oct 6, 2010 at 1:37 PM, Ron Wheeler
wrote:
>>
>> No worries. I've already got Nexus installed (just dropped the WAR
>> into Tomcat; almost too easy). I just haven't played with it enough
>> yet to make sure it can do everything I need it to (like copy
>> artifacts between repositories).
On 06/10/2010 3:14 PM, Phillip Hellewell wrote:
On Wed, Oct 6, 2010 at 12:42 PM, Siegmann Daniel, NY
wrote:
Phillip,
Nexus supports deployment via HTTP. Probably other repo managers do too.
Yeah, I just figured that out. But I'm still getting a 401 error
because I haven't set my credential
On Wed, Oct 6, 2010 at 1:17 PM, Ron Wheeler
wrote:
> On 06/10/2010 2:42 PM, Siegmann Daniel, NY wrote:
>>
>> Using Maven in a corporate setting without having a repository manager
>> is like working in a team without a version control system. You could do
>> it but you're going to suffer.
>
> +1
ject: Re: Can't specify distributionManagement in settings.xml
On Wed, Oct 6, 2010 at 9:28 AM, Anders Hammar wrote:
Please, please, please have a look at a repo manager. It has these
type of
features. That's why it's called a manager.
I'm sure a repo manager can do fancy th
On Wed, Oct 6, 2010 at 12:42 PM, Siegmann Daniel, NY
wrote:
> Phillip,
>
> Nexus supports deployment via HTTP. Probably other repo managers do too.
Yeah, I just figured that out. But I'm still getting a 401 error
because I haven't set my credentials yet. I haven't figured out yet
if it is Tomc
ssage-
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: Wednesday, October 06, 2010 11:55 AM
To: Maven Users List
Subject: Re: Can't specify distributionManagement in settings.xml
On Wed, Oct 6, 2010 at 9:28 AM, Anders Hammar wrote:
> Please, please, please have a look at a repo ma
On Wed, Oct 6, 2010 at 9:28 AM, Anders Hammar wrote:
> Please, please, please have a look at a repo manager. It has these type of
> features. That's why it's called a manager.
I'm sure a repo manager can do fancy things with multiple repositories
for downloading, and I am already working on getti
On Wed, Oct 6, 2010 at 11:19 AM, Phillip Hellewell wrote:
> Speaking of snapshots, is there an easy way to delete all snapshots
> older than a given date to free up disk space? Since snapshots are
> temporary, yet plentiful, deleting old ones seems like it would be a
> common need.
Some of the r
Please, please, please have a look at a repo manager. It has these type of
features. That's why it's called a manager.
/Anders (mobile)
Den 2010 10 6 17:19 skrev "Phillip Hellewell" :
> On Mon, Oct 4, 2010 at 11:26 PM, Ron Wheeler
> wrote:
>>
>> Maven will do this automatically for you. Just set
On Tue, Oct 5, 2010 at 12:29 AM, Anders Hammar wrote:
> Have a look at this parent:
> http://repo2.maven.org/maven2/org/sonatype/forge/forge-parent/6/forge-parent-6.pom
>
> There you see that properties are used for both the repo name and url. This
> makes it possible to override these values from
On Mon, Oct 4, 2010 at 11:26 PM, Ron Wheeler
wrote:
>
> Maven will do this automatically for you. Just set the version to
> X.Y-SNAPSHOT and Maven will deploy it to your SNAPSHOT repository as defined
> in your parent POM.
Thanks Ron. I was thinking about snapshots, but wasn't quite sure if
I wa
Have a look at this parent:
http://repo2.maven.org/maven2/org/sonatype/forge/forge-parent/6/forge-parent-6.pom
There you see that properties are used for both the repo name and url. This
makes it possible to override these values from command line. This is
normally not anything you do, but it's ve
On 05/10/2010 12:45 AM, Phillip Hellewell wrote:
On Mon, Oct 4, 2010 at 2:58 PM, Ron Wheeler
wrote:
On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
Yeah, part of the problem is I still haven't got this working with a
"parent" pom, and I don't even know exactly what is meant by a parent
pom
On Mon, Oct 4, 2010 at 2:58 PM, Ron Wheeler
wrote:
> On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
>>
>> Yeah, part of the problem is I still haven't got this working with a
>> "parent" pom, and I don't even know exactly what is meant by a parent
>> pom (I assume it was using the tag, but I'm
On 04/10/2010 4:28 PM, Phillip Hellewell wrote:
On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric
wrote:
-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
The pattern I was talking about was all the issues Philip runs into as
he
was trying t
One of the absolutely best way to understand some of the patterns/best
practice is to look at examples.
For instance, look at how things (like parent poms) are structured at
Apache, Codehaus or even Sonatype.
One example:
http://repo2.maven.org/maven2/org/codehaus/codehaus-parent/3/codehaus-parent
On Mon, Oct 4, 2010 at 4:28 PM, Phillip Hellewell wrote:
> I am getting a better picture now of how many feel it is good to have
> the default deploy location in a pom somewhere, but I still haven't
> been convinced that it is absolutely necessity, and I'm not sure it is
> worth dealing with the h
On 04/10/2010 3:46 PM, Phillip Hellewell wrote:
On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd)
wrote:
I don't think it is arbitary. Where you deploy your artifacts TO, I think
should be fixed. I think that is the intent. It is a one off thing that is
applicable to the build at hand a
On Mon, Oct 4, 2010 at 2:24 PM, Haszlakiewicz, Eric
wrote:
>>-Original Message-
>>From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
>>
>>The pattern I was talking about was all the issues Philip runs into as
> he
>>was trying to not follow the Maven way.
>
> So, again,
>-Original Message-
>From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
>
>The pattern I was talking about was all the issues Philip runs into as
he
>was trying to not follow the Maven way.
So, again, I ask: what IS the pattern? What IS the "Maven way" in this
situation
2010/10/4 Arnaud Héritier :
> mvn deploy -DaltDeploymentRpository=...
> But some times ago there was a bug which disallow to use it without a
> distribMgt part in the pom :(
Thanks. Unfortunately, it appears that Maven 2.2.1 still has this bug :(
Phillip
---
ers List
> Subject: Re: Can't specify distributionManagement in settings.xml
>
> It is interesting to have it variable in several cases :
> - You want to validate your builds on several environments. I'm just
> moving my infrastructure and I'm very happy to have that because I'
mvn deploy -DaltDeploymentRpository=...
But some times ago there was a bug which disallow to use it without a
distribMgt part in the pom :(
Arnaud Héritier
Software Factory Manager
http://www.exoplatform.com
Phone : +33 (0)6 89 74 64 24
Skype : aheritier
Twitter : @aheritier
Blog : http://aher
The pattern I was talking about was all the issues Philip runs into as he
was trying to not follow the Maven way.
/Anders
On Mon, Oct 4, 2010 at 21:07, Haszlakiewicz, Eric wrote:
> >-Original Message-
> >From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
> >
> >Are you
ber 04, 2010 3:40 PM
>> To: Maven Users List
>> Subject: Re: Can't specify distributionManagement in settings.xml
>>
>> On Mon, Oct 4, 2010 at 1:36 PM, Phillip Hellewell
>> wrote:
>>> 2010/10/4 Arnaud Héritier :
>>>> Wrong :-)
>>>> Let m
>-Original Message-
>From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com]
>
>I don't think it is arbitary. Where you deploy your artifacts TO, I
think
>should be fixed. I think that is the intent. It is a one off thing that
is
>applicable to the build at hand and isn't something you wil
I think where you deploy to isn't in the settings.xml file because there there
is no need for it. Where you get artifacts from does have a specific need.
It sounds like a nice to have feature, but I don't think there is a dire need
for it from the community.
>
> But anyway, that is neither he
On Mon, Oct 4, 2010 at 1:43 PM, Thiessen, Todd (Todd)
wrote:
> Hehe. It always gets back to that.
>
> Not sure why your hung up over it ;-).
Well, I'm going to do some more tests now to see if I can get this
working with a parent pom. If I run into an error that I can't figure
out you'll probabl
yes, which is a best practice :-)
It can work like that too :
- In your pom you put the distributionMgt with the property
- in your settings you create a profile with this property but instead of using
an activation activateByDefault you define it in activatedProfiles list.
It will work but I thi
On Mon, Oct 4, 2010 at 1:36 PM, Thiessen, Todd (Todd)
wrote:
> I don't think it is arbitary. Where you deploy your artifacts TO, I think
> should be fixed. I think that is the intent. It is a one off thing that is
> applicable to the build at hand and isn't something you will want to try and
>
that found of making it a variable though. That just sounds
like extra work for very little gain.
> -Original Message-
> From: Phillip Hellewell [mailto:ssh...@gmail.com]
> Sent: Monday, October 04, 2010 3:40 PM
> To: Maven Users List
> Subject: Re: Can't specify distr
1 - 100 of 174 matches
Mail list logo
