in fact, the way the issue is described is misleading:
"How to use 5 digit version numbers with Maven ?" and
"Maven only handles 3 digit version numbers using the versions-maven-plugin"
it should be phrased:
"How to use 5 digit version numbers with versions-maven-plu
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
ject: 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,
e versions plugin's rulesUri or
> -Dmaven.version.rules...
>
> > On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi <mehul.sang...@gmail.com>
> wrote:
> >
> > We need to use 5 digit version numbers going forward. Maven only
> handles 3
> > digit version numbers
> > using the ve
or -Dmaven.version.rules...
> On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi <mehul.sang...@gmail.com> 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
> projec
Hi,
On 1/7/16 1:08 PM, Mehul Sanghvi wrote:
We need to use 5 digit version numbers going forward. Maven only handles 3
digit version numbers
where is this documented ?
which is simply not true.
https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
Since Maven 3 you can use
We will have a full write up but we need to change the way resolution works to
make building partial sets from the reactor correctly (--projects, --am, and
--amd). My requirement is that there be full documentation before we release it.
On Aug 31, 2014, at 10:40 PM, Milos Kleint
As of Maven 3.2.x, we have this ability to parameterize a project
version, or to drop some sort of extension point module into a Maven
install to take control of versioning.
I'm considering pushing this as an approach. However, I would be
grateful for some more details about it. Has anyone
Takari's CD solution will be open sourced around the end of September. We have
two implementations in progress: one for a customer with a large project (500+
modules) in p4, and another for Facebook Presto which is a smaller project (20+
modules). The large project has been using the mechanism
Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x
specific ( it really doesn't like the tiles plugin ).
I have a fork of Idea where I've bumped the embedded version of Maven
but as yet, it dies horribly with RMI Classloader issues :(
On 1 Sep 2014, at 4:57, Benson
netbeans is also embedding 3.0.5 (which is used for project loading
exclusively, for building any version can be used)
Milos
On Mon, Sep 1, 2014 at 8:22 AM, Mark Derricutt m...@talios.com wrote:
Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x
specific ( it really
Hello.
I'm working on a project that uses version numbers of the form:
2.0-rc9
Where '2' is the major version, '0' is the minor version, and
'rc9' is obviously some sort of qualifier - this one being release
candidate 9. Obviously, Maven doesn't deal with this too well (it
falls back
Hi,
I'm using profiles at work for the sole purpose of deciding what to do
with the build artifact, i.e. activating different deployment targets
(application servers) for an EAR.
I see this as a completely different task where you're simply using
Maven as a utility tool. When using
We're having lots of projects building at least one EAR, and each EAR is
deployed to the same application server(s), but in different flavors:
developer (snapshot) build, integration build and/or release build. Using
a CI server configured with special jobs doing these deployment tasks
would
Hi,
When been over this several times on this list. You have to extract
the configuration out of the binary. You mustn't have a Maven build
that could generate different flavors of an artifact. Which one would
you deploy to the repository?
Ok, this was a bit misleading by me. With flavors I
pour le contenu fourni.
From: chad.da...@emc.com
To: users@maven.apache.org
Date: Fri, 16 Mar 2012 12:51:03 -0400
Subject: useing profiles to control properties to drive version numbers in
poms
Does anyone have any experience using a property to control the version
numbers in poms? Like
Hi,
Yes, profiles are evil.
If you use them for changing / defining _what_ gets built and/or how, yes.
If you think you should be using profiles, think again. If you still
think they are the solution, please think it through once more. If you
still persist, go use Ant.
Profiles are simply
If you think you should be using profiles, think again. If you still
think they are the solution, please think it through once more. If you
still persist, go use Ant.
Profiles are simply very rarely a good solution.
I'm using profiles at work for the sole purpose of deciding what to do
with
On 18/03/2012 5:41 PM, Thorsten Heit wrote:
Hi,
Yes, profiles are evil.
If you use them for changing / defining _what_ gets built and/or how, yes.
If you think you should be using profiles, think again. If you still
think they are the solution, please think it through once more. If you
On 18/03/2012 5:53 PM, Anders Hammar wrote:
If you think you should be using profiles, think again. If you still
think they are the solution, please think it through once more. If you
still persist, go use Ant.
Profiles are simply very rarely a good solution.
I'm using profiles at work for the
Not good.
Dependency versions should be deterministic. For the same reason avoid
version ranges.
/Anders (mobile)
Den 16 mar 2012 17.52 skrev chad.da...@emc.com:
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version
Not good.
Dependency versions should be deterministic. For the same reason avoid
version ranges.
That's pretty definitive, and I think I agree on a gut level. Can you
articulate any specific issues? I'd appreciate it if you could.
Search the forum for profile.
You will see people in all kinds of difficulty and dead-ends caused by
trying to use profiles.
There are (apparently) some actual uses for profiles but far more cases
of misuse.
We have never used profiles but from watching the forum for 4+years, my
advice is to
The thing is that having the possibility of change a dependency
version during build time would/could sound as a good thing. BUT, you
have to remember that your pom gets deployed to a repo and will be
consumed by other people. If the pom does not have pinned downed
versions but would change
Yes, profiles are evil.
If you think you should be using profiles, think again. If you still
think they are the solution, please think it through once more. If you
still persist, go use Ant.
Profiles are simply very rarely a good solution.
/Anders
On Fri, Mar 16, 2012 at 19:31, Ron Wheeler
to a
dependencies often broke of fixed problems in the child projects. So I
would get a report like EMEA channel load version 2.0.1 was had error foo.
So since often someone would forget to update the child version numbers I
would then have to ask questions like what version the salesforce API
it will choose the version that is closest... with the provisio that ranges
can trim the selection.
keep in mind that
version1.0.0/version is You can select any version but if you can pick
1.0.0
version[1.0.0]/version is You must select 1.0.0 or fail the build
version[1.0.0,2.0.0)/version is You
On Tue, Sep 21, 2010 at 8:16 AM, Anders Hammar and...@hammar.net wrote:
Not sure I understand. But basically, the end user controls the transitive
dependencies. Your artifacts can't do that. So if he wants to use version A
of Clojure, he can do that regardless of the version of your artifacts
IMO dependencies should never be inherited the results are always fuzzy,
consider
Parent P with defines a dependency on A 1.1
and
Parent P' that defines a dependency on A 2.1
And a war project W that depends on two projects one with parent P and the
other parent P'... which version of A
Neat :) Is the plan here to have 61 individual releases/version numbers or
a single release for the entire collection?
I know people have wanted independent cycles for certain things but under
git this isn't really workable ( a) the release plugin b) tagging over the
entire repo ).
Also, under
Neat :) Is the plan here to have 61 individual releases/version numbers or
a single release for the entire collection?
This is up to you. Out of the end user's perspective, every artifact that
you want to control has to be added to the dependencyManagement section.
I know people have
On Tue, Sep 21, 2010 at 7:32 AM, Mark Derricutt m...@talios.com wrote:
Neat :) Is the plan here to have 61 individual releases/version numbers or
a single release for the entire collection?
61 individual versions was my original plan, but now I'm balking at
the complexity of that. I'm open
On Wed, Sep 22, 2010 at 12:16 AM, Anders Hammar and...@hammar.net wrote:
I don't use git, so I don't know. However, having independent release
cycles
will give you more flexibility at the cost of more complexity. I would
suggest try keeping it simple if possible. However, having a separate
On 21/09/2010 3:51 PM, Stuart Sierra wrote:
On Tue, Sep 21, 2010 at 7:32 AM, Mark Derricuttm...@talios.com wrote:
Neat :) Is the plan here to have 61 individual releases/version numbers or
a single release for the entire collection?
61 individual versions was my original plan, but now I'm
On Tue, Sep 21, 2010 at 4:12 PM, Mark Derricutt m...@talios.com wrote:
From my understanding of the clojure-contrib library, there's currently two
project trees for clojure 1.1.0 and 1.2.0 - which differ where there are
incompatibles in clojure library versions.
Not really. There are branches
Hello, Maveners,
I'm managing the build for clojure-contrib, a diverse collection of
libraries for the Clojure programming language.
After several releases as a monolithic JAR, I nudged ;-) the community
into a multi-module build. Now I have 61 sub-modules, all depending
on a single parent
The user of the module can always control this through a dependencyManagemet
section. That's how it should be done. Ranges have all sorts of strange
impact, IMO. One would be that your (and the user's) builds are not
necessarily reproducable; the outcome might change should a new version of
Hey all,
I'm wanting to write a mojo to run as part of my release process ( by
declaring it in the preparationGoals/ element of the release plugin, but I
want to know the release version, and the next-release version as used by
the release plugin.
Are these values stored in any system parameters
On 06/08/2010, at 9:12 PM, Mark Derricutt wrote:
Hey all,
I'm wanting to write a mojo to run as part of my release process ( by
declaring it in the preparationGoals/ element of the release plugin, but I
want to know the release version, and the next-release version as used by
the release
Hi,
I am in doubt regarding what version numbers I should use for my
product. There are two schemes I can think of right now:
1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 -
1.0-rc1-SNAPSHOT - 1.0-rc1 ...
2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT -
1.0-rc1
. You don't know exactly how many milestones you will have.
May be you will need to release 1.0-m1-2, or 1.0-m1-fix.
As to me,
this product won't need to upgrade every time there is a new
milestone release.
more important then,
I can always tell by looking at even the
SNAPSHOT version numbers
will
have. May be you will need to release 1.0-m1-2, or 1.0-m1-fix.
As to me,
this product won't need to upgrade every time there is a new
milestone release.
more important then,
I can always tell by looking at even the
SNAPSHOT version numbers what milestone we are getting towards.
Best
Hi Lóránt,
Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21:
Hi,
I am in doubt regarding what version numbers I should use for my
product. There are two schemes I can think of right now:
1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 -
1.0-rc1-SNAPSHOT - 1.0-rc1 ...
2
going to decide which is the never? Is it important?
Lóránt
On Tue, Mar 23, 2010 at 11:43, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Lóránt,
Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21:
Hi,
I am in doubt regarding what version numbers I should use for my
product
:
Hi Lóránt,
Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21:
Hi,
I am in doubt regarding what version numbers I should use for my
product. There are two schemes I can think of right now:
1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 -
1.0-rc1-SNAPSHOT - 1.0-rc1 ...
2) 1.0
/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26512100.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail
of filtering the build pom with the defined system property?
Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts
about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26507407.html
Sent from the Maven - Users mailing list archive at Nabble.com
for the deployed pom to be
the result of filtering the build pom with the defined system property? Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers
numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version
Sure, you can do this by setting a version number to 'RELEASE' to get the
latest non-snapshot, but IMHO it's a bad practice in general. In any dev
You can also do similar things with version ranges eg [1,2) means
version greater than 1 but less than 2.
If you are making serious (breaking)
Dave Newton wrote:
In other words, use the maven-release-plugin to publish
formal releases of code, and make sure that project A
never depends on a snapshot of project B if you can
possibly avoid it. Use proper version numbers.
Would it be reasonable to say that *released* versions
Rick wrote:
Here's what I'm confused at though. Project A builds a jar. It needs
to be used in Project B. Ideally of course Project A should be tested
in Project B locally, but in reality (unfortunately) the dev
environment often becomes a more 'real' test. Typically the developers
of Project A
this message in context:
http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html
Sent from the Maven - Users mailing list archive at Nabble.com
, and A and C are both involved in another, concurrent feature as well.
We've not yet found a very satisfying procedure for that one... anyone? ;-)
--
View this message in context:
http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29
for that one... anyone? ;-)
--
View this message in context:
http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html
Sent from the Maven - Users mailing list archive at Nabble.com
Rick wrote:
Is it common for the development environment to rely on company
snapshot versions and only in test or later, to define specific
version numbers? I seem weary though to have for example project B
rely on the snapshot version of project A. Maybe project A is working
on a release
--- On Sat, 9/13/08, Graham Leggett wrote:
In other words, use the maven-release-plugin to publish
formal releases of code, and make sure that project A
never depends on a snapshot of project B if you can
possibly avoid it. Use proper version numbers.
Would it be reasonable to say
On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote:
In other words, use the maven-release-plugin to publish formal releases of
code, and make sure that project A never depends on a snapshot of project B
if you can possibly avoid it. Use proper version numbers.
Here's what
On Sat, Sep 13, 2008 at 9:03 PM, Rick [EMAIL PROTECTED] wrote:
On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote:
Here's what I'm confused at though. Project A builds a jar. It needs
to be used in Project B. Ideally of course Project A should be tested
in Project B
version numbers wasn't so tight, and it didn't matter as we were much
better about planning releases as there was less change.
David
--
View this message in context:
http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19250282.html
Sent from the Maven - Users mailing list archive
--
View this message in context:
http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
of using numbers to represent concepts. It makes the
version numbers hard to understand and there is nothing in Maven that says your
versions have to contain only numbers.
-Original Message-
From: kroe [mailto:[EMAIL PROTECTED]
Sent: Wed 8/27/2008 11:02 AM
To: users@maven.apache.org
Subject
the idea of using numbers to represent concepts. It makes
the version numbers hard to understand and there is nothing in Maven that
says your versions have to contain only numbers.
-Original Message-
From: kroe [mailto:[EMAIL PROTECTED]
Sent: Wed 8/27/2008 11:02 AM
To: users
On Sun, Jul 13, 2008 at 2:33 PM, in the [ANN] Maven Site Plugin
2.0-beta-7 Released thread, Dennis Lundberg [EMAIL PROTECTED]
wrote:
Giovanni Azua wrote:
Many thanks! Yes the mvn help:effective-pom shows it is picking up the
2.0-beta-6 under pluginManagement section ...
Then you need to
Hello again,
I am wondering whether my question is:
1. obvious
2. silly
3. too specific
:-)
Isn't this something that lot of people are coping with everyday ? Is
there something I should know about version management in
multi-modules build ? I did already some refactoring using
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my dependencies in each of my modules.
For my modules, That is just manual labor for me.
On Tue, Jun 24, 2008 at 7:44 AM, Insitu [EMAIL PROTECTED] wrote:
Mick,
-Original Message-
From: Mick Knutson [mailto:[EMAIL PROTECTED]
Subject: Re: Best practice for handling multi-modules version numbers
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my
: Mick Knutson [mailto:[EMAIL PROTECTED]
Subject: Re: Best practice for handling multi-modules version numbers
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my dependencies in each of my modules
Hello,
I vaguely remember reading a thread a few months ago on this topic, but
could not find it searching nabble.
The question is: how to minize duplication when setting project version
numbers in a multi-module project ? I assume at that time that the version
number should identical
We have our project constructed using multiple sub-components, each with
their own POM, all of which inherit from a common parent POM.
When we want to update to the next version, we change the parent POM,
and inherit common info into the children. However, we seem to have to
update all of the
On Jan 3, 2008 2:48 PM, Marshall Schor [EMAIL PROTECTED] wrote:
We have our project constructed using multiple sub-components, each with
their own POM, all of which inherit from a common parent POM.
When we want to update to the next version, we change the parent POM,
and inherit common info
-plugin/pom.xml
Baz wrote:
Joerg,
Thanks for your reply.
I know I can use release plug-in. What if i am changing dependency version
numbers?
On 11/12/07, Joerg Hohwiller [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
What is the recommended methods
Hi,
What is the recommended methods to change contents (version numbers)
version within multiple pom.xml? Is there anything like REXML in RUBY?
Thanks.
A.
Hi,
Hi,
What is the recommended methods to change contents (version numbers)
version within multiple pom.xml? Is there anything like REXML in RUBY?
Thanks.
A.
this is normally achieved using the maven-release-plugin. See the
documentation on http://maven.apache.org/plugins/maven-release
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
What is the recommended methods to change contents (version numbers)
version within multiple pom.xml? Is there anything like REXML in RUBY?
You can find an experimental approach that might or might not help you:
http
Joerg,
Thanks for your reply.
I know I can use release plug-in. What if i am changing dependency version
numbers?
On 11/12/07, Joerg Hohwiller [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
What is the recommended methods to change contents
either.
/Anders,
- Message from Huang, Yan [EMAIL PROTECTED] on Wed, 12
Sep 2007 12:10:16 -0700 -
To:
Maven Users List users@maven.apache.org
Subject:
RE: Parametrisizing artifact version numbers
It always puzzles me that maven does not resolve the property when
building
, I'm trying to put the version numbers in properties instead, so I only
have to update the properties of the parent pom in each project.
Here's a few sample poms of two projects, where myotherproject depends on
myproject:
!-- parent pom for myproject --
project xmlns=http://maven.apache.org/POM
?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 8:59 AM
To: Maven Users List
Subject: Re: Parametrisizing artifact version numbers
Have you considered the release plugin?
Wayne
On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi!
I'm
I'm trying to solve the problem where IBM RAD uses project names (and hence
jar file references) without version numbers, but Maven creates its jars
with version numbers.
The main issue I have is with the automatic generation of the Manifest
files. If I let Maven generate them, the resulting
It's the timestamp version of the snapshot. Maven generate always it when it is
deployed to the repository.
In your pom you use -SNAPSHOT and maven will find the latest snapshot available
in the repo with timestamped version
Emmanuel
Wojtek Ciesielski a écrit :
Hi there,
I've noticed that
Hi there,
I've noticed that artifacts deployed by continuum server do have
extended version number... In the POM file the version specified is
1.0-SNAPSHOT but in the repository I'm getting artifacts like
my-module-1.0-20070213.093006-5.jar. It causes that a module from
repository handled by
Hi all,
I've noticed that artifacts deployed by continuum server do have
extended version number... In the POM file the version specified is
1.0-SNAPSHOT but in the repository I'm getting artifacts like
my-module-1.0-20070213.093006-5.jar. It causes that a module from
repository handled by
Updating the version numbers in the pom files can be done by calling the
release goal.
Roald Bankras
Software Engineer
JTeam b.v.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 11:30 PM
To: Maven Users List
Subject: RE: integration builds
Where is this documented? I'd like to read more about this.
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 3:16 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
Updating the version numbers in the pom files
I tried both mvn release and mvn release:release - neither exists.
What is the correct goal?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 9:51 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
Where
Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 4:14 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
I tried both mvn release and mvn release:release - neither exists.
What is the correct goal?
-Original Message-
From: EJ
: Wednesday, June 14, 2006 3:14 PM
Subject: RE: integration builds and version numbers
I tried both mvn release and mvn release:release - neither exists.
What is the correct goal?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 9:51 AM
To: Maven
To: Maven Users List
Subject: RE: integration builds and version numbers
In chapter 7 of the 'better builds with maven' book (downloadable from
www.mergere.com) there is a description on how to use the release
plugin.
The plugin website can be found at
http://maven.apache.org/plugins/maven-release
and version numbers
Ok - got the pdf, but I'm confused. Does this release plugin need to be
configured at the parent or child pom level? What if our scm tool of
choose (perforce) requires passwords?
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14
/settings
I'm talking about passwords to perforce
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 10:55 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
The website mentioned by Kieran Brady shows how you can
]
Sent: Wednesday, June 14, 2006 10:54 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
The only place on that page I see passwords mentioned is in regards to
repositories:
settings
servers
server
idcommons.ucalgary.ca/id
usernamewoodj/username
: Wednesday, June 14, 2006 9:54 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
I'm talking about passwords to perforce
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 10:55 AM
To: Maven Users List
Subject: RE
To: Maven Users List
Subject: RE: integration builds and version numbers
The perforce provider does not handle passwords; it is assumed that you
are already logged in. We have a special build user who is only allowed
to log in from the build server and whose login never expires.
-Original
/configuration
/plugin
/plugins
/build
/project
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 2:48 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
Does anyone know if mvn, when using the perforce scm
but
I've never tried that before.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 1:48 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
Does anyone know if mvn, when using the perforce scm config,
will pull
, 2006 12:12 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
The perforce provider does not handle passwords; it is assumed that you
are already logged in. We have a special build user who is only allowed
to log in from the build server and whose login never expires
1 - 100 of 122 matches
Mail list logo
