is the Maven Way™ to resolve these Artifacts?
For completeness, I also looked at
http://maven.apache.org/guides/introduction/introduction-to-artifact-resolution.htmlbut
this didn't seem to have ever been completed.
Thanks,
Best,
Laird
--
http://about.me/lairdnelson
--
Baptiste Batmat
On Mon, Jan 6, 2014 at 1:05 AM, Baptiste Mathus bmat...@batmat.net wrote:
Does
http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java
help you?
Yes; I see that it uses maven-artifact-resolver. If indeed
On Mon, Jan 6, 2014 at 5:44 AM, Laird Nelson ljnel...@gmail.com wrote:
On Mon, Jan 6, 2014 at 1:05 AM, Baptiste Mathus bmat...@batmat.netwrote:
Does
http://svn.codehaus.org/mojo/trunk/mojo/extra-enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractResolveDependencies.java
Hello; suppose I have a CollectionArtifact in my left hand, all elements
of which are not resolved.
(As it happens, I got these indirectly from a DependencyGraphBuilder
invocation.)
What is the Maven Way™ to resolve these Artifacts?
I know that these Artifacts are unresolved, because each
On Sun, Jan 5, 2014 at 3:56 PM, Laird Nelson ljnel...@gmail.com wrote:
What is the Maven Way™ to resolve these Artifacts?
For completeness, I also looked at
http://maven.apache.org/guides/introduction/introduction-to-artifact-resolution.htmlbut
this didn't seem to have ever been completed
Hi,
also take a look on Arquillian, it can manage containers as well.
Regards,
htfv (Aliaksei Lahachou)
On Fri, Jul 5, 2013 at 10:29 PM, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:
Hello,
now after some trial and error with custom packaging and lifecycles I
ask myself whether I
several times... It feels like a bit of a
siren's call to me...
The most public thing I did down this road is mojo's ship-maven-plugin...
Which does things a, IMHO, more maven way *if* I were to imagine a maven
way for things that take place beyond the (standard) lifecycle
My current thinking
Hello,
now after some trial and error with custom packaging and lifecycles I
ask myself whether I should proceed or do something completely
different.
What I want to achieve:
- We have loads of web-applications (WARs with a homegrown
configuration tooling)
- Some are single module projects, some
Hi Mirko,
Have you looked at the Cargo plugin?
http://cargo.codehaus.org/Functional+testing
- Russ
On Jul 5, 2013, at 4:29 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote:
Hello,
now after some trial and error with custom packaging and lifecycles I
ask myself whether I should
have a hammer and now everything looks like a
nail to me?
I have been down your road several times... It feels like a bit of a
siren's call to me...
The most public thing I did down this road is mojo's ship-maven-plugin...
Which does things a, IMHO, more maven way *if* I were to imagine a maven
Very nice!
Ron
On 30/11/2012 7:12 AM, Stephen Connolly wrote:
It's a tad rough, but I'm fed up writing it, and I think it's useful for
people anyway:
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Just some of my random thoughts
-Stephen
--
Ron Wheeler
Laird, any environment with multiple developers and multiple repositories is
Exhibit 1 for using a repository manager like Nexus.
Once you have that running, one proxies remote repositories from central
administration, not rely on users having the latest information or some
combination of
Maven 3 requires that the artifact have originated from a valid repository,
so putting it in a profile will mean that it will only build with the
profile active. far better to just mandate a mirrorOf* to internal
nexus/artifactory/archiva server
On 22 October 2012 22:37, Laird Nelson
(-PnameOfTheProfileContainingNonCentralRepositoriesForLazyPeopleWhoDoNotSetUpNexus)
It sounds like The Maven Way here is to not even bother with such a hybrid
approach but to fall back on documentation in some other artifact that is
not the pom.xml (because it's not good to put in information about where
On 23/10/2012, at 9:09 AM, Laird Nelson ljnel...@gmail.com wrote:
A user of my jpa-maven-plugin (http://github.com/ljnelson/jpa-maven-plugin)
was complaining that he didn't know what repos to proxy (EclipseLink in
particular staunchly refuses to migrate their stuff to Central; their repo
is
On Tue, Oct 23, 2012 at 8:39 AM, Laird Nelson ljnel...@gmail.com wrote:
[del]
Or, another way to put it: Nexus/Artifactory are effectively runtime
dependencies of Maven (that is, running without them is generally regarded
as awful, so a Maven without them is effectively crippled, so anyone who
On Tue, Oct 23, 2012 at 8:39 AM, Laird Nelson ljnel...@gmail.com wrote:
A user of my jpa-maven-plugin (http://github.com/ljnelson/jpa-maven-plugin)
was complaining that he didn't know what repos to proxy (EclipseLink in
particular staunchly refuses to migrate their stuff to Central; their repo
On 22/10/2012 5:37 PM, Laird Nelson wrote:
I know that it is a Bad Thing to add a repository to your pom.xml.
Is it regarded by the Great Maven Hivemind :-) to be a Bad Thing if you put
a repository in your pom.xml as an (unactivated by default) profile?
I'm sick and tired of having to tell
Hi!
I'm using Maven at work to organize my software projects. I will first of
all describe you my current build process.
-
The typical deployment assembly contains at least:
Hello,
Maven repository may contain anything, you just have to set appropriate
classifier and type/packaging. I never deployed zip archives using Maven
plugins, but I often upload zips to our company Nexus using web-front.
Regards,
htfv (Aliaksei Lahachou)
On Fri, Jul 13, 2012 at 7:56 PM,
Zero configuration? Really?
mwood@mhw ~ $ mkdir testmvn
mwood@mhw ~ $ cd testmvn
mwood@mhw ~/testmvn $ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Default Project
[INFO]
After reading this thread and the embedded references I believe much of
this information should be captured and added to http://maven.apache.org
- in particular under Learning About Maven the very first topic should
be The Maven Way. As well, if you go to
http://maven.apache.org/what
it.
Why aren't there any screenshots in my documentation?
I do not think thousands of documentation variants are clever but pick up
two or three of them. A small example:
- Video tutorial explaining the maven way
- Practical tutorial for maven java projects and the maven way
- Textual explanation
of this information should be captured and added to
http://maven.apache.org - in particular under Learning About Maven
the very first topic should be The Maven Way. As well, if you go to
http://maven.apache.org/what-is-maven.html then one of the first
things you should see is a link to The Maven Way
On Thu, Apr 19, 2012 at 05:49:32PM +0200, martin.eisengardt wrote:
[snip]
Please do think of the target audience before planning this type of
documentation section. And do think of the way they are usually learning
things. The maven way won't be a site full of plain explanations
and the embedded references I believe much
of this information should be captured and added to
http://maven.apache.org - in particular under Learning About Maven
the very first topic should be The Maven Way. As well, if you go to
http://maven.apache.org/what-is-maven.html then one of the first
things you
One thing I would like to add to this discussion is that, in my
experience, a lot of Maven users don't understand that Maven is not
only about building but also about producing something that can be
consumed from a repository. One part of what we often call Maven is
the build tool, but a much more
2: Effective Implementations from Brett
Porter [1], which basically describes the maven way most of the time.
The disadvantage of this book is, that it's quite old and the maven way
sometimes changed over time.
hth,
- martin
[1] http://www.packtpub.com/apache-maven-2-effective-implementation/book
I hope that my comments are not taken as being critical of the person
asking for help.
Our team was in their position when we started and had to learn the
Maven way.
We received a lot of help and got a lot of benefit from the free
resources provided by the community.
We also were working
But yes, documentation about this could be much better. But as someone
very correctly pointed out, there is very likely is a reason for the
lack of this. It's all open source and contributions are gladly
accepted. Even the Sonatype's book are open source (well, Creative
Commons Attribution,
On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote:
Good read.
Documentation can be much better, but I suppose it is up to us as community
members to make that happen. Maven isn't owned by anyone. The guys at
Sonatype have done a good job of posting various blogs. If
On 18/04/2012 9:52 AM, Mark H. Wood wrote:
On Tue, Apr 17, 2012 at 02:40:53PM -0400, Thiessen, Todd (Todd) wrote:
Good read.
Documentation can be much better, but I suppose it is up to us as community
members to make that happen. Maven isn't owned by anyone. The guys at Sonatype
have done a
The Maven site is not the most friendly place to start as a new Maven
user but it is not the only resource.
Perhaps the community should try to come to a consensus about the books
and recommend one as the best starting point for a new user and one as
the best place to find Best Practices.
Hi everyone,
Thanks to all for the robust discussion!
To Ron, I apologize if my comments sounded overly critical of you in
particular. I get that you are trying to help guide people in the right
direction, and it is certainly good for them to question their assumptions,
and to understand the
On 18/04/2012 4:03 PM, Curtis Rueden wrote:
Hi everyone,
Thanks to all for the robust discussion!
To Ron, I apologize if my comments sounded overly critical of you in
particular. I get that you are trying to help guide people in the right
direction, and it is certainly good for them to
On 2012-04-18 1:03 PM, Curtis Rueden wrote:
Hi everyone,
Thanks to all for the robust discussion!
To Ron, I apologize if my comments sounded overly critical of you in
particular. I get that you are trying to help guide people in the right
direction, and it is certainly good for them to
Part of the reason, I believe, is because those conventions are not carved
in stone. There often isn't a hard and fast convention that says when to
make a profile or when to make a module or when to use a classifier to store
a second artifact alongside the primary
And over time these
On Thu, Apr 19, 2012 at 9:02 AM, Barrie Treloar baerr...@gmail.com wrote:
Part of the reason, I believe, is because those conventions are not carved
in stone. There often isn't a hard and fast convention that says when to
make a profile or when to make a module or when to use a classifier to
Eric,
I remember when you first started visiting the forum.
As you described, you came with some pretty strong views about how Maven
should work.
I do remember how carefully and well, you sought out advice from the
people here.
In spite of your strong feelings that you were an experienced
Thanks - it has been one of the more interesting adventures in my
professional life :-)
Cheers, Eric
On 2012-04-18 4:37 PM, Ron Wheeler wrote:
Eric,
I remember when you first started visiting the forum.
As you described, you came with some pretty strong views about how
Maven should work.
I
Hi list,
a simple question with (hopefully) a simple answer:
Is there some coherent documentation of the Maven way?
I'm *not* looking for:
* documentation of the Maven syntax
* documentation of Maven plugins
* Maven reference documentation
* Use the Source, Luke! style of advice
What I'm
question with (hopefully) a simple answer:
Is there some coherent documentation of the Maven way?
I'm *not* looking for:
* documentation of the Maven syntax
* documentation of Maven plugins
* Maven reference documentation
* Use the Source, Luke! style of advice
What I'm looking
I also recommend taking the Sonatype training courses - especially if
you are a software architect.
There is a lot to be said when you can ask question as the instructor is
going over the material.
However, you are right, if someone were to write a book called the The
Maven Way in the style
, if someone were to write a book called the The
Maven Way in the style you suggest, I would certainly be interested in
buying a copy.
You are not alone in that. Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things Maven's way, Maven
.
There is a lot to be said when you can ask question as the instructor is
going over the material.
However, you are right, if someone were to write a book called the The
Maven Way in the style you suggest, I would certainly be interested in
buying a copy.
You are not alone in that. Especially
On 17 April 2012 09:48, Curtis Rueden ctrue...@wisc.edu wrote:
Hi everyone,
Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things Maven's way, Maven will fight you and Maven will win.
I disagree that it is the most valuable single
You are not alone in that. Especially since the most valuable single bit of
advice one can give a new Maven user is: if you don't do things Maven's
way, Maven will fight you and Maven will win.
People extol the virtues of convention over configuration, but where is the
compact definitive
Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things Maven's way, Maven will fight you and Maven will win.
I disagree that it is the most valuable single bit of advice. It is
repeated far
too frequently, often in cases
requirement.
-Original Message-
From: chad.da...@emc.com [mailto:chad.da...@emc.com]
Sent: Tuesday, April 17, 2012 2:32 PM
To: users@maven.apache.org
Subject: RE: The Maven Way
You are not alone in that. Especially since the most valuable single
bit of
advice one can give a new
Good read.
Thanks.
I think it says something that it has not been done yet. While everyone says
it would be great to have, clearly no one has felt strongly enough about it
(yet) to make it happen. It is more of a very nice to have than a hard and
fast
requirement.
I'm tackling the
the The
Maven Way in the style you suggest, I would certainly be interested in
buying a copy.
You are not alone in that. Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things Maven's way, Maven will fight you and Maven will win.
People extol
I'm tackling the topic on my blog in upcoming weeks. The first thing
I'm going to talk about is how Maven expects all dependencies to be
handled via repositories, and how to make non-standard artifact types
work like this, such as custom assemblies, etc.
Good stuff sir. I tip my hat to you.
On 17/04/2012 2:37 PM, chad.da...@emc.com wrote:
Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things Maven's way, Maven will fight you and Maven will win.
I disagree that it is the most valuable single bit of advice. It is repeated
On 17/04/2012 2:47 PM, chad.da...@emc.com wrote:
Good read.
Thanks.
I think it says something that it has not been done yet. While everyone says
it would be great to have, clearly no one has felt strongly enough about it
(yet) to make it happen. It is more of a very nice to have than a
the material.
However, you are right, if someone were to write a book called the The
Maven Way in the style you suggest, I would certainly be interested in
buying a copy.
You are not alone in that. Especially since the most valuable single
bit of advice one can give a new Maven user is: if you
are a software architect.
There is a lot to be said when you can ask question as the instructor is
going over the material.
However, you are right, if someone were to write a book called the The
Maven Way in the style you suggest, I would certainly be interested in
buying a copy.
You are not alone
.
However, you are right, if someone were to write a book called the
The
Maven Way in the style you suggest, I would certainly be
interested in
buying a copy.
You are not alone in that. Especially since the most valuable single
bit of advice one can give a new Maven user is: if you don't do
things
On 18 Apr 2012, at 1:44 AM, Eric Kolotyluk wrote:
Often the wrong foot is simply not knowing how much Maven does for your for
free - because it is not obvious - especially when compared to tools like
Ant. When the free stuff is not obvious, we naively start trying to solve
problems we do
and match, perhaps have different
release cycles for the swf and the jar, multiple modules is certainly
better.
Kalle
On Wed, Dec 2, 2009 at 11:42 PM, Anders Hammar and...@hammar.net wrote:
I'd like to stress that Jesse explains the true Maven way. This is how this
should be done if you want
2, 2009 at 11:42 PM, Anders Hammar and...@hammar.net wrote:
I'd like to stress that Jesse explains the true Maven way. This is how this
should be done if you want to enjoy simple and correct dependency management
through Maven.
Using classifiers will make your two (for instance) artifacts have
Does anyone have any examples or tips about how to handle the
generation of multiple artifacts based on a shared model? For example,
I have a project which needs to produce both Java and ActionScript
code based on a shared UML model. I'm having trouble figuring out how
to best setup and manage
Since the build artifacts are output of the same source, they should
part of the same module. Use classifiers to specify the different
artifacts. If you are using custom scripts to produce the output (i.e.
not plugins that attach additional artifacts automatically), use
buildhelper plugin to
UML model. I'm having trouble figuring out how
to best setup and manage these types of projects, so that a change to
the source project can easily result in the build of all the various
generated outputs. Thanks in advance for the help.
To go the real Maven way, I think that I'd probably put
I'd like to stress that Jesse explains the true Maven way. This is how this
should be done if you want to enjoy simple and correct dependency management
through Maven.
Using classifiers will make your two (for instance) artifacts have the same
dependencies. As I've stated before, classifiers
Hi,
I have a servlet project with WEB-INF in /src/main/webapps/.
The web.xml contains some ${tomcat.servletpath} like variables which are
filtered through maven.
This variables are stored in files in
/src/main/config/
How should I store a configuration which I can use locally within
65 matches
Mail list logo
