RE: Deploy with SFTP tries to cd to parent too many times
I can't help wondering if this entire discussion is continuing because of semantics. I think you are talking about two uses of the word deploy. For a Maven Deploy a standard Maven repository is probably best. For a Production Deploy we must use whatever the production environment provides. If you are 'deploying' an artifact to be acquired by another Maven project then it is a Maven Deploy. If you are 'deploying' a product into a production environment (where it will execute, for example) it is a Production deploy. How can we de-obfuscate the word deploy that was overloaded by the Maven use? Also, consider the other overloaded words: package, install, validate, verify, etc. I suppose, on a Maven forum, the words should be used the Maven way. But ,then how do you ask about the other contexts? !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, September 06, 2010 5:12 PM To: users@maven.apache.org Subject: Re: Deploy with SFTP tries to cd to parent too many times On 06/09/2010 2:19 PM, Trevor Harmon wrote: On Sep 6, 2010, at 6:48 AM, Ron Wheeler wrote: Get Nexus up and running and start to enjoy using Maven. I'm sensing a theme here. Anybody reminded of that old joke? Doctor, it hurts when I move my arm like this. Doctor: Then don't move your arm like that. It is free. It is easy to install and configure. ... We are a small team of 3 but it was well worth the time to get it up and running. That you are a small team of 3 is very likely the reason why you found it easy to install and configure. I'm assuming one of you 3 set up the server yourself, correct? And had root access to it? Correct You probably didn't have to expose Nexus outside the firewall, either. No. We are a distributed operation. These are all advantages I'm lacking. I'm working remotely as an external contractor and have no control over the company's servers. And it doesn't help that I'm the only person using Maven in an all-Microsoft shop. Probably more trouble than its worth. Stick with Ant or use the Microsoft tools They'd have to integrate the Nexus server's user account management with Microsoft Active Directory. (Is that even possible?) And they'd also have to configure their firewall just for me so that I may access Nexus from the outside. They should know how to do this. I am not sure why you would bother with Active Directory for 1 person. Just use Nexus' authentication. This is a company with thousands of employees and a full-time IT security engineer; punching holes in their walls is not something they take lightly. In short, installing Nexus is by no means easy. But the company already happens to have a web server with SFTP access outside the firewall. They've given me an account on it. I'm simply trying to piggyback on this as a repository and use SFTP for deployment, since SFTP is a supported deployment method. So they do know how to expose services safely within their environment. Please correct me if I'm wrong about that. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Multiple profile execution in maven
I have read that any activation of any profile on the command line will disable all profiles that are active by default. Is that still the way Maven works? If it is, perhaps, the first profile 'x' in -Px,y was active by default so the command line setting was ignored and then the second profile 'y' was activated, disabling the first profile. What do you guys think? Could that be it? Perhaps if the order were reversed it would work as desired. !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Thursday, August 26, 2010 9:10 AM To: Maven Users List Subject: Re: Multiple profile execution in maven I checked the docs at maven.apache.org and they say comma list. But as always, there might be bugs...:-) /Anders On Thu, Aug 26, 2010 at 14:42, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I think you use multiple -P's to activate them -Px -Py but that could all just be my imagination ;-) On 26 August 2010 12:33, Anders Hammar and...@hammar.net wrote: It should work. However, I'm not sure if I have ever enabled more than one profile from command line. Just for the heck of it, could you try adding a space between -P and the profiles list (-P x,y)? /Anders On Thu, Aug 26, 2010 at 13:16, Sridhar Laxmipuram Srinivasan sridh...@yahoo-inc.com wrote: Hi, I have 2 profiles which are deactivated by default but at run time I need to execute both of them, I have tried with -Px,y but of no use it always executes the latter, Could you kindly provide me a solution to this. I am using maven 2.2.1 version thnkx sridharl
An alternate lifecycle
I see several other people are also doing projects that are similar to some of mine. - They need to pull artifacts from the Maven repositories. They are referred to as 'dependencies, although, there is nothing in the project that is actually dependent on the those artifacts (for compile, test, execution, etc.). - The files of the artifacts must actually be acquired, not just referenced. This means the use of one or more plugins bound to an arbitrary phase that occurs in the needed sequence. - files need to be 'post-processed' in some way. Some files need to be removed, moved, signed, repackaged, etc. - there is no source code to be compiled or tested. - No Maven install or deploy is performed. - The results of the project are transferred to some distribution or production location. We used to call this deploying or installing. It occurs to me that perhaps, rather than trying to kludge these projects onto the 'default' lifecycle, we should define an alternate lifecycle that better fits this kind of project. In general, I would characterize these projects as getting files from Maven and sending them somewhere else, rather than producing files to be put into Maven repositories. We need one lifecycle to put thing into Maven and another to get them out. Would anyone like to help define and implement such a product? What would we call the lifecycle? How does the 'export' lifecycle sound. What phases would it need to have? Would any default bindings be appropriate? Would we use words other than package, install, deploy to avoid confusion with the default lifecycle phases? frank_gorham-eng...@cable.comcast.com Software Development Infrastructure Specialist Process, Configuration, Tools, Automation, Distribution, Development, Analysis, Design, Architecture Comcast CVS, Radnor, PA; (610)535-4431 →
RE: how to resolve dependency version with newest?
Hi Guys... er, People Just brainstorming here. Perhaps it could be flagged as a build stopping error if a dependency on more than one 'major' version is found and just a warning if multiple version of the same 'major' versions are referenced. Depends found on 3.11 and 4.2 = error. Depends found on 3.2, 3.1.6, 3.2.0.5 = use 3.2, warn (optional) This would reinforce the idea that 'breaking' revisions requires a 'major' version number change. !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Sunday, August 15, 2010 4:13 PM To: Michael Chan Cc: users@maven.apache.org Subject: Re: how to resolve dependency version with newest? I am not sure that I agree with that method of operation. I like to be in control of the dependencies of an application. If we move to a new abc-1.3.jar, I want to know about it and I want to know why we are changing version and what level of testing needs to be done to specifically investigate the new release. Usually it is not a big deal but I want to change versions explicitly since B and C still have to work even tough it they only have been built and tested with the lower version.. The dependency hierarchy will show where conflicts arise so you can deal with it. Practically speaking, this is not too big an issue for us. We depend on 60 or so third party libraries. Ron On 15/08/2010 8:44 AM, Michael Chan wrote: Hi Ron, Thanks for your reply. I know putting the required version in top level in pom will work. But I don't want to hard code any specific version in the top level pom. Let me illustrate by an example what I want to achieve - Suppose my project A depends on project B and project C. And project B and C depend on abc.jar, but different versions B - abc-1.1.jar C - abc-1.2.jar When I build project A, I want to get highest version of abc.jar, in this case, it will be MAX(1,1, 1.2), so it is 1.2. I can put the dependency abc-1.2.jar in my top level pom. The problem is later my project A may depend on extra projects, say project D, that in turns depend on abc-1.3.jar. So I would like Maven to *dynamically* get the highest version of abc.jar in the whole dependency tree (but not necessary the latest one in the respository). How can I achieve this? Thanks. Michael Newest measured how? Highest version? Are you trying to say I don't care what version I get as long as it is the highest/latest available? Just put the version that you want in your top level POM and nearest-wins will get it. What exactly are you trying to achieve? Do you have a lot of different versions of an artifact specified in your dependency tree? Ron On 12/08/2010 11:10 AM, Michael Chan wrote: Hi, I am new to maven and currently using version 2.1. Seems it only supports the nearest-wins policy, how can I use newest-wins? I googled and found this http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers is it already implemented? If no, any other solution? Thanks. Michael -- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: A use case for non-constant artifact ids
Hi Hanno
The Maven provided solution for your situation is 'classifiers'. You are
building a single artifact for multiple classes of compiler.
In the language of Maven, non-constant artifact ids is an oxy-moron. The 'Id'
part of this field label stands for 'identifier'. An identifier is, by nature,
a constant. You don't have a different birthday when you where different shoes.
Your birthday is one piece of identifying information about you. The intention
in Maven is for the GroupId and ArtifactId to be identifiers. This affects the
dependency resolution, storage, acquisition processes that Maven uses.
Notice that 'version' and 'classifier' are not labeled 'Ids'. These are where
your variations can be registered.
!-- Frank Gorham-Engard →
Be kinder than necessary.
Everyone is fighting some kind of battle.
-Original Message-
From: Hanno Braun [mailto:h...@gmx.net]
Sent: Friday, August 06, 2010 9:47 AM
To: Maven Users List
Subject: A use case for non-constant artifact ids
Hi everyone,
when I build my project, Maven tells me the following:
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.hannobraun:scalable-dynamics_2.8.0:jar:0.3-SNAPSHOT
[WARNING] 'artifactId' contains an expression but should be a constant.
@ com.hannobraun:scalable-dynamics_${scala.version}:0.3-SNAPSHOT,
/home/hanno/Projects/ScalableDynamics/pom.xml
[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]
I think the ability to have an expression in the artifactId is very
useful for Scala projects built with Maven.
Due to binary incompatibility between code that was compiled with
different versions of the Scala compiler, Scala projects have adopted
the convention of adding the Scala version used to the artifact id. See
this for example: http://mvnrepository.com/artifact/org.scala-tools.testing
Due to the ability to use an expression in the artifact id I can do
something like this:
properties
scala.version2.8.0/scala.version
/properties
artifactIdscalable-dynamics_${scala.version}/artifactId
...
dependencies
dependency
groupIdorg.scala-lang/groupId
artifactIdscala-library/artifactId
version${scala.version}/version
/dependency
dependency
groupIdorg.scala-tools.testing/groupId
artifactIdspecs_${scala.version}/artifactId
version1.6.5/version
scopetest/scope
/dependency
/dependencies
This approach is pretty much error-proof and low-maintenance. Requiring
a constant artifactId would introduce the possibility of errors every
time I update to another Scala version.
While I understand the notion of wanting to restrict what a user can do
for safety reasons, I think it would be a shame to take power away from
the users. You'll never be able to anticipate what kind of productive
uses people will find for this power.
Regards,
Hanno
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh released dependencies
You could try changing the repository location property on the command line to a fresh empty directory. That will force the download and logging of all SNAPSHOT and release dependencies. mvn ... -Dmaven.repo.local=new-temp-directory !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: Shan Syed [mailto:shan...@gmail.com] Sent: Friday, July 30, 2010 2:21 PM To: Maven Users List Subject: Re: force maven to redownload/refresh released dependencies ok, thanks basically for liability reasons for a certain project, we have to provide specific times of when a project was built and when/where all its dependencies were retrieved at/from we have to ensure a sanitary build for all these JARs and a complete log of going from 0 to 100 for the build; so we are faced with either clearing out the .m2 each time I was wondering if there was a way to force this through maven On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis manos_li...@geekologue.comwrote: On 07/30/2010 07:16 PM, Wayne Fay wrote: is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with released artifacts Absolutely not. Released artifacts MUST NOT CHANGE. +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Running antrun plugin twice in same phase with another plugin in between?
Hello users, I have an alternate suggestion to the phase/goal ordering issues that are often raised here. Allow for the specification of phase to include a 'before-' or 'after-' prefix. Users could specify the phase for a plugin execution to be, for example, 'before-deploy' or 'after-package'. This wouldn't break the life-cycle model while permitting a constrained method for expanding it. Also, any 'after-' phases should be executed when the phase is the target. For example, if I specified a plugin for 'after-deploy' it would be executed (at the end) when the command line was 'mvn deploy'. Perhaps even 'before-before-test' should be allowed as well? But not 'before-after-test', let's not go there! !-- Frank Gorham-Engard → Be kinder than necessary. Everyone you work with is fighting some kind of battle. -Original Message- From: Wim Deblauwe [mailto:wim.debla...@gmail.com] Sent: Tuesday, July 13, 2010 5:10 AM To: Maven Users List Subject: Running antrun plugin twice in same phase with another plugin in between? Hi, I need to run the antrun plugin twice in the packaging phase. I found this on the wiki: http://docs.codehaus.org/display/MAVENUSER/MiniGuide-AntMultiPhase However, it speaks of different lifecycle phases. I tried with the same phase and that works, however, I need to run another plugin in between. Is this possible? I was hoping that all plugins' executions would be sorted by their id. That way, i could use id's like 'step-1-do-something', 'step-2-do-something-else', to force a certain order of plugin execution. regards, Wim
RE: Relationsship pom.xml and build.xml from Ant
Also, if an ant build uses the Ant Maven plugin, for example to access a dependency, the plugin will read the pom file. !-- Frank Gorham-Engard → Be kinder than necessary. Everyone you work here with is fighting some kind of battle. -Original Message- From: Shan Syed [mailto:shan...@gmail.com] Sent: Wednesday, July 14, 2010 1:08 PM To: Maven Users List Subject: Re: Relationsship pom.xml and build.xml from Ant maven/POMs can make use of ant build scripts, so be wary of this scenario; it is fairly common to use ant via maven So if I get a project which contains a pom.xml and a build.xml then the developer offers to use either Ant or Maven. If I select Maven then I can delete build.xml. If I select Ant then I can delete pom.xml without harm. also a project can have various components that build in different ways, so again, I wouldn't make the above assumption there is no way to convert an ant build script into a maven POM, because ant scripts don't have any kind of enforced convention; it would be impossible to write such a converter On Wed, Jul 14, 2010 at 1:02 PM, benxs bxsto...@yahoo.co.uk wrote: Sorry for this Maven newbie question but I want to clarify the relationsship between pom.xml and Ant's build.xml. Are the following statements correct? pom.xml is solely Maven related build.xml is solely Ant related Both do not (never) depend on each other (are e.g. included). So if I get a project which contains a pom.xml and a build.xml then the developer offers to use either Ant or Maven. If I select Maven then I can delete build.xml. If I select Ant then I can delete pom.xml without harm. Is there a way to convert a build.xml into a pom.xml and vice versa? Ok in case of pom.xml - build.xml I would loose some functionality but this should not be the question at this point. Is there such a converter? Thank you Ben -- View this message in context: http://maven.40175.n5.nabble.com/Relationsship-pom-xml-and-build-xml-from-Ant-tp1092912p1092912.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: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Write Maven Books - Packt Publishing
I would like to unsubscribe from the Maven Book Writer's List without leaving the Maven Users List. Is this possible? !-- Frank Gorham-Engard → Be kinder than necessary. Everyone you work here with is fighting some kind of battle. -Original Message- From: Andrew Close [mailto:acl...@gmail.com] Sent: Wednesday, July 07, 2010 9:16 AM To: Maven Users List Subject: Re: Write Maven Books - Packt Publishing On Wed, Jul 7, 2010 at 7:00 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 07/07/2010 5:19 AM, Benjamin Wootton wrote: Would anyone be interested in teaming up on something like this? Have thought about pitching a maven book before but don't have the cycles to go it alone There is a desperate need for a Best Practice book. You see all kinds of strange development practices being discussed here. They show up as complaints about Maven's inability to do some process but when you dig a bit deeper, the person has evolved a development methodology that makes no sense if you have Maven. The lack of this type of information also makes it harder to get started with Maven since there is lots of flexibility in Maven and if you read the documentation, silly ideas and good ones all seem possible. If you look through the last few weeks of forum traffic and try to understand what the person was actually trying to do, you will see: a) odd source and resource structures in a project b) odd release strategies c) odd or missing dependency management and the list goes on. There are clearer best ways to integrate Maven into a development environment. A book on the subject will also have to touch on IDE integration, source management, maven repositories, continuous integration and other development areas. I would like to see a book targeted at the 80% of developers who should be using these tools out of the box with no custom plug-ins or custom setups. Discussing the odd-ball cases would only make Maven more confusing. +10 Best Practices Enterprise Usage ??? -- Andrew Close - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: About Maven3 M2Eclipse plug-in versioning problem
MYMVN.bat:
Preprocess.exe mypom.xml pom.xml
mvn %1 %2 %3 %4 %5 %6 %7
del pom.xml
Remember what happened when they started making C compilers more restrictive?
The C preprocessor was born.
Actually, these days, the above BAT file would probably run an ant script. :-)
The harder you squeeze people into a mold, the more violent and sudden will be
the leap to the next plateau of people getting what they want.
!-- Frank Gorham-Engard →
Be kinder than necessary.
Everyone you work here with is fighting some kind of battle.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Monday, May 17, 2010 5:24 PM
To: Maven Users List
Subject: Re: About Maven3 M2Eclipse plug-in versioning problem
So how do I use my documentation-producing plugin in its own documentation
without a variable version number?
See http://github.com/khuxtable/docbkx-wrapper-plugin/blob/master/pom.xml for
an example. It's in the site profile near the bottom.
-K
On May 17, 2010, at 12:48 PM, Kalpak Gadre wrote:
Yes variable version names are not allowed as of Maven 3. I believe the
reason will be deploying into repositories, as pom with version as some
properties instead of a proper version could get deployed.
A quick fix is to configure Eclipse to use external installation of Maven 2.
But remember that variable versions will not be supported in the future
releases. I personally use version number derived out of properties for our
Continuous Integration server to generate the tick part of version
(1.0.0.[123]). I haven't personally found a solution yet using Maven 3.
Thanks,
Kalpak
Hi,
At first, thanks for your attention and time to read.
In our enterprise applications we use MyEclipse 8.5 with
M2Eclipse maven3 plug-in support. Before begining to use maven3, with maven2
we
could specify a variable for the application version in the parent pom, so
that
in the child poms we could able to specify the version by the same variable.
That helps us saving our time for updating version number in each project
upgrade and for reusability.
I hope I can clearly demonstrate the problem as the
following piece of code for pom.xml’s.
Now the problem is in maven3 (m2eclipse) it gives a warning
that says “version must be a constant instead of a variable”. I have been
trying lots of variations such as moving out theversion tag or
swapping the expressions betweenprojectVersion andversion
tags or the other suggestions from the different forum sites, etc.. However,
the solution never comes up.. Maybe I am doing something wrong, but could not
find out yet.
Any help would be appreciated,
Many thanks in advance,
Bariscan
BTW, you can check the case from here:
PARENT:
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservices/artifactId
namen3gservices Maven
Main/name
packagingpom/packaging
descriptionVersion Alias:
MemberProfitLocalService/description
version${projectVersion}/version
properties
projectVersion2.4/projectVersion
/properties
Child;
project
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.gg.n3gservices/groupId
artifactIdn3gservicesBugfix/artifactId
namen3gservices Bugfix/name
parent
artifactIdn3gservices/artifactId
groupIdcom.gg.n3gservices/groupId
relativePath../n3gservices/pom.xml/relativePath
version${projectVersion}/version
/parent
version${projectVersion}/version
_
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven 2.2.1 on Windows-64 bit
I don't see any other responses so I will jump in and state what appears to be obvious to me. Maven doesn't run on Windows or Mac, it runs on the Java Runtime Engine. As long as your platform has a JRE you are good to go. !-- Frank Gorham-Engard → Be kinder than necessary. Everyone you work here wtih is fighting some kind of battle. -Original Message- From: Vineeth Karkad (vkarkad) [mailto:vkar...@cisco.com] ... Maven - Does it work on 64-bit Windows platform ?
RE: Setting up Distribution Management inside of the pom.xml file
When you hear about a company super pom, some is mixing their references. Yes, the super pom is part of Maven and you wouldn't need to change it. What you want is a parent pom. We have a company parent pom and a program parent that refers to the company parent pom. Then each project refers to the parent pom for its program. When you put in a setting just decide 'do you want it to affect all company projects, only one program or only this project', that tells you where to put it. Just install each as a pom type artifact (and deploy if you have a repository manager). !-- Frank Gorham-Engard → It is a misnomer to label any practice 'a best practice'; a practice is only best in the specific context in which it performs well. -Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: Wednesday, April 07, 2010 1:49 PM To: Maven Users List Subject: Setting up Distribution Management inside of the pom.xml file When you do a mvn deploy, Maven looks for a distributionManagement section of your POM. I would like to be able to move this distributionManagement section out of each project's POM. My developers shouldn't have to worry about it. I'd like to be able to put this in my build user's settings.xml file or in the settings.xml file inside the Maven home directory of my build system. That way, when we change the location of our release repository, I don't have to change all the various project POM files. Is this even possible? What about doing this in the company wide Super POM? I keep hearing about instituting a company wide Super POM, but can't find where this is suppose to go. My understanding is that the Super POM is inside the Maven JAR. Am I suppose to unjar the Maven JAR, modify the Super POM and then rejar the Maven JAR file? Or, is the company'e Super POM suppose to go somewhere else? -- David Weintraub qazw...@gmail.com
RE: Using variables in POM's version field
Would I be right in thinking that the entire purpose of a SNAPSHOT artifact is
so that dependent modules don't have to be edited every time a new artifact is
produced. This makes the developer's job easier as long as they are willing to
accept the risk of having the dependee artifact change at any time.
If so, what would be reason for making an artifact with a build number in the
artifact version string that changes every time the artifact is deployed and
calling it a SNAPSHOT? The dependent developers would have to adjust their
dependencies each time a new dependee artifact is generated. But, that is the
way a release artifact works. Any advantage gained by deploying as a SNAPSHOT
is eliminated by having a different version string each time.
Have I made it clear why doing this is misguided? Just go ahead and deploy a
release artifact with the build number in the version. The result is the same.
One artifact per version string.
Also, the unresolved build number doesn't occur if you create the new build
number before starting Maven and pass it into the build as a property on the
command line. All build systems will support this need. I noticed everyone has
mentioned their favorite build system so I will mention mine, QuickBuild2. A
free version is available that will support a limited number of projects.
Includes a promotion model and configuration inheritance as part of its design.
No plugins needed.
!-- Frank Gorham-Engard →
It is a misnomer to label any practice 'a best practice';
a practice is only best in the specific context in which it performs well.
-Original Message-
From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org]
Sent: Friday, April 02, 2010 7:39 PM
To: Maven Users List
Subject: Re: Using variables in POM's version field
Correct, and it's a bad idea. -K
On Apr 2, 2010, at 6:15 PM, Scott Susslin wrote:
I figured something like this was why it wasn't working. So sounds like,
given Maven 2, it can't work. True?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 4:05:10 PM
Subject: Re: Using variables in POM's version field
Amongst other reasons, allowing runtime variable interpolation in the
coordinates would prevent the reactor from properly calculating a
multi-module build plan. The coordinates at the start of the build
must remain the coordinates throughout the build.
On Apr 2, 2010, at 5:14 PM, Scott Susslin goi...@yahoo.com wrote:
Why?
Also, is it possible?
- Original Message
From: Justin Edelson justinedel...@gmail.com
To: Maven Users List users@maven.apache.org
Sent: Fri, April 2, 2010 12:05:32 PM
Subject: Re: Using variables in POM's version field
This is a bad idea. Don't do it.
On Apr 2, 2010, at 2:21 PM, Scott Susslin goi...@yahoo.com wrote:
I'm trying to use the buildnumber plugin to control the version
field of a POM.
version1.0.${buildNumber}-SNAPSHOT/version
The package phase works fine, creating a file with the parsed
value in the filename. The install and deploy don't seem to
parse the variable. When they run, I get something like the
following:
[INFO] Installing PROJECT/artifact-0.1.334-SNAPSHOT.swc to ~.m2/
repository/PROJECT/artifact/0.1.${buildNumber}-SNAPSHOT/
artifact-0.1.${buildNumber}-SNAPSHOT.swc
Anyone have any experience with this?
Thanks
- Scott
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Running multiple phases on multimodules.
On Windoze: mvn clean mvn install echo profit! (sic) !-- Frank Gorham-Engard → It is a misnomer to label any practice 'a best practice'; a practice is only best in the specific context in which it performs well. -Original Message- From: Wendy Smoak [mailto:wsm...@gmail.com] Sent: Wednesday, March 24, 2010 6:05 PM To: Maven Users List Subject: Re: Running multiple phases on multimodules. On Wed, Mar 24, 2010 at 5:52 PM, Wayne Fay wayne...@gmail.com wrote: $ mvn clean ; mvn install ; echo profit! Did you try Jesse's suggestion on the command line? It does exactly what you requested. ... unless he's on Windows, where there's no way to do it on one line afaik. Happy to be proven wrong though! -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to perform ordered tasks in Maven2 build
Wayne I apologize. I didn't mean to have to going all defensive on me. Sure, everyone knows you are a major contributor here. I was just saying you could have done more to not perpetuate the 'name calling'. The real question in my post still goes unanswered: Where is the evidence that me using Maven will make my customers happier? Information like this would be very useful to me and I expect to others. !-- Frank Gorham-Engard → It is a misnomer to label any practice 'a best practice'; a practice is only best in the specific context in which it performs well. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, March 18, 2010 5:46 PM To: Maven Users List Subject: Re: How to perform ordered tasks in Maven2 build Hey Wayne, We don't need to start name calling here. zealous ant users? Would that be someone who believes that their favorite tool must be best for everybody. Remind you of anyone? Read the posts in this thread from Ronen Perez before making assumptions about me calling anyone names... this is simply incorrect. In the words of Benjamin Franklin it is better to be thought a fool than to open your mouth and remove all doubt. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: How to perform ordered tasks in Maven2 build
Hey Wayne, We don't need to start name calling here. zealous ant users? Would that be someone who believes that their favorite tool must be best for everybody. Remind you of anyone? There are ant users and maven users. And there are zealous users and pragmatic users. You don't have to be a zealous user to believe that the tool you are using is working fine and it would be a lot of work to change. Instead of insisting that people change and complaining (or name calling) if they are reluctant, let's take the approach of trying to supply the information we believe that they are not aware of yet. You know, that information that if they knew it then they would definitely agree with us. So what is it that these zealous ant users should know? I think maybe it is Where is the evidence that me using Maven will make my customers happier? We've all heard of the latest greatest thing that would provide massive long term benefits if only we would accept the short term pain. Pascal, CASE tools, OOD, UML, giving up smoking, losing weight, etc. Some people just want you to try everything they think is good. Other people are naturally resistant. I told the engineers here that management had decided that we would have to change to Maven because it would look so good on everybody's resume. It's odd to have management insisting that we change. After so many years complaining that management only looked at the short term goals, now it's management that is looking at the long term and the engineers still doubt that they know what they're doing. So, even management buy-in isn't the magic pill to success. !-- Frank Gorham-Engard → It is a misnomer to label any practice 'a best practice'; a practice is only best in the specific context in which it performs well. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, March 18, 2010 2:28 PM To: Maven Users List Subject: Re: How to perform ordered tasks in Maven2 build It was key for us that it happened in a grass roots fashion. A meritocrocy approach, while slow, is generally the best way to get buy in. If you force it, everyone will hate it and not be very productive. I agree 100% with the grassroots, meritocracy approach. But it sounded like the OP in this thread has no real power to re-architect his projects/builds and he is working with zealous ant users. We know that is the path to failure. So someone, somewhere needs to give him this power -- ideally its the dev team(s) he is working with, but it could also be the person they report to, depending on the culture of the org and the norms in their locale (Asia vs Europe vs US etc). Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Plugin for updating external XML file content
What do you see as the value of completely eliminating ant use from your Maven project. I see ant as a tool that is supported and may be appropriate for some situations. To have a policy that rules out a useful tool seems counterproductive. !-- Frank Gorham-Engard → -Original Message- From: Ilya Kazakevich [mailto:kazakev...@devexperts.com] Sent: Monday, February 01, 2010 10:57 AM To: 'Maven Users List' Subject: RE: Plugin for updating external XML file content Thanks. Actually, I wanna get rid of ant in our project, ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Plugin for updating external XML file content
Hi Ilya Yes, I agree, keeping it simple is a positive value. Perhaps you haven't noticed that ant is an existing maven plugin. It is possible to run inline ant tasks or external scripts without having an ant installation on your system. Maven will get ant from the Maven repositories for you. I'm just saying that I think starting a new project to create a plugin is not as simple as using a bit of ant script, at least for those who have a little ant exposure. !-- Frank Gorham-Engard → -Original Message- From: Ilya Kazakevich [mailto:kazakev...@devexperts.com] Sent: Monday, February 01, 2010 1:08 PM To: 'Maven Users List' Subject: RE: Plugin for updating external XML file content Hello Frank. Using too many tools could make project too complicated. I saw a project with maven, ant and .bat files. It was tricky:) If something could be solved using maven only -- we should do so. Ant-script at least requires ant to be installed on platform. If something cannt be solved using existing maven plugins -- we should make decision between creating maven plugin and using ant script, because ant script is better than shell script for example (because of its cross-platform nature). But I am sure that 99% of our issues could be solved using maven only. But that’s my imho, and its probably not a best practice. -Original Message- From: Gorham-Engard, Frank [mailto:frank_gorham-eng...@cable.comcast.com] Sent: Monday, February 01, 2010 7:20 PM To: Maven Users List Subject: RE: Plugin for updating external XML file content What do you see as the value of completely eliminating ant use from your Maven project. I see ant as a tool that is supported and may be appropriate for some situations. To have a policy that rules out a useful tool seems counterproductive. !-- Frank Gorham-Engard → -Original Message- From: Ilya Kazakevich [mailto:kazakev...@devexperts.com] Sent: Monday, February 01, 2010 10:57 AM To: 'Maven Users List' Subject: RE: Plugin for updating external XML file content Thanks. Actually, I wanna get rid of ant in our project, ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: mvn deploy:deploy does not work :(
Hi Afkham Azeez The id is the field that connects the server entry to the repository entry. It should be the same in both places. And you need a server entry for each repository. !-- Frank Gorham-Engard → -Original Message- From: Afkham Azeez [mailto:afk...@gmail.com] Sent: Wednesday, January 20, 2010 2:00 PM To: Maven Users List Subject: mvn deploy:deploy does not work :( Hi folks, We are using Maven 2.1.0 and have provided the following settings.xml file: settings xmlns=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/xsd/settings-1.0.0.xsd; localRepository/home/azeez/.m2/repository/localRepository interactiveModefalse/interactiveMode servers server idwso2-snapshot-repository/id usernamesnapshots/username passwordx/password filePermissions664/filePermissions directoryPermissions755/directoryPermissions !--configuration/configuration-- /server /servers /settings In our project's POM file, we have the following distribution management section: distributionManagement repository idwso2-maven2-repository/id nameWSO2 Maven2 Repository/name urlscp://dist.wso2.org/home/httpd/dist.wso2.org/maven2//url /repository snapshotRepository idwso2-snapshot-repository/id nameWSO2 Snapshot Repository/name urlscp://dist.wso2.org/home/httpd/dist.wso2.org/snapshots/maven2//url /snapshotRepository /distributionManagement The maven-deploy-plugin version is 2.3. However, the password provided in the settings.xml file seems to be ignored. We are always getting this error: Error retrieving previous build number for artifact 'org.apache.axis2:axis2-parent:pom': repository metadata for: 'snapshot org.apache.axis2:axis2-parent:SNAPSHOT' could not be retrieved from repository: wso2-snapshot-repository due to an error: Authentication failed: Cannot connect. Reason: Auth fail However, we are able to SSH to that machine using the same username password given in the settings.xml file. Any idea what could be the problem? We also noticed that the keyboard interaction is used even when the password is supplied and this seems to be a bug http://jira.codehaus.org/browse/WAGON-237 -- Thanks Afkham Azeez Blog: http://afkham.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
