I would recommend that you use Aether in that non-maven code to
interact with remote and local repo. This is what Maven does and it
will then ensure you don't run into issues.
/Anders
On Tue, Sep 25, 2012 at 12:13 AM, Tim Eck t...@terracottatech.com wrote:
Using mvn 3.0.4, when a SNAPSHOT
Well, okay, I read that instruction.
But I may also need to have a WAR artifact including all dependent EJBs in
case I want to deploy it as WAR only, no EAR.
In this case I still need to preserve original WAR dependencies.
And I need m-ear-p to strip them if they're a listed as EAR dependencies
In that case WAR Overlays[1] come into picture.
Markku
[1] http://maven.apache.org/plugins/maven-war-plugin/overlays.html
On 09/25/2012 05:57 PM, nskmda wrote:
Well, okay, I read that instruction.
But I may also need to have a WAR artifact including all dependent EJBs in
case I want to
I did never suggest to modify the POM and said no word about any
future form of the POM, so I skip your comments about that and right
go on with the idea of a Platform:
I like some of your idea about the concept of a platform but this is
not as trivial as you think.
There is the
Markus,
If you want to join in on the fun of the development community, please
join us on the dev list. As you've heard on this thread, your
particular concern smacks into a messy conundrum about our desire to
avoid breaking other people's tools that read poms -- no matter how
poorly coded.
I did not read through the whole thread, so maybe I missed (sorry for that).
Afaik maven plugins use a different ClassLoader hierarchy than you might expect.
Most frameworks use ParentClassLoaderFirst, but maven afaik uses
ClientClassLoaderFirst.
Which means it's perfectly fine to to put a
Let's say I wanted to automate the process of promoting daily snapshots to
the nexus repository, and then configuring the project to always utilize the
latest version in the repo.
Is there a way to automate incrementing the version number and deploy to
nexus?
Specifically: I've used the nexus
On 25/09/2012 3:59 PM, mlandman99 wrote:
Let's say I wanted to automate the process of promoting daily snapshots to
the nexus repository, and then configuring the project to always utilize the
latest version in the repo.
Is there a way to automate incrementing the version number and deploy to
Is there a way to automate incrementing the version number and deploy to
nexus?
versions plugin @ codehaus mojo
deploy plugin @ apache maven (deploy-file mojo)
Wayne
-
To unsubscribe, e-mail:
Not sure what you mean.
A brief sample config?
--
View this message in context:
http://maven.40175.n5.nabble.com/Ear-Plugin-skinnyWars-EJB-problem-tp563p5723651.html
Sent from the Maven - Users mailing list archive at Nabble.com.
Hi -
I'm working on my first Maven project and find it great but we have run
into a small issue.
We are using a snap-shot version of the geotoolkit (
http://www.geotoolkit.org/) because of a bug in the current release.
We are in testing and am concerned that we could introduce bugs into our
On Tue, September 25, 2012 2:17 pm, Doug Kunzman wrote:
Hi -
I'm working on my first Maven project and find it great but we have run
into a small issue.
We are using a snap-shot version of the geotoolkit (
http://www.geotoolkit.org/) because of a bug in the current release.
We are in
The networking issues are more contractual than performance and
availability.
The hours available for network administrator support are somewhat
limited.
Douglas Kunzman
12201 Sunrise Valley Drive
Reston, VA 20192
Phone: 703 648-4234
dkunz...@usgs.gov
From:
Manfred Moser
On Tue, September 25, 2012 3:32 pm, Doug Kunzman wrote:
The networking issues are more contractual than performance and
availability.
The hours available for network administrator support are somewhat
limited.
Even more a reason to look at running a repo manager.
In either case.. are these
On 25/09/2012 6:32 PM, Doug Kunzman wrote:
The networking issues are more contractual than performance and
availability.
The hours available for network administrator support are somewhat
limited.
That is all the more reason to use an internal repository manager.
We have been running Nexus
Are you using any other snapshots? If this is your only snapshot
dependency, or the only one you are not building), you could use the new
-nsu flag (no snapshot updates) in Maven 3.0.4 so that snapshots, once
downloaded, are not checked for updates.
A better alternative is to ask Martin to
On Wed, Sep 26, 2012 at 11:21 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Are you using any other snapshots? If this is your only snapshot dependency,
or the only one you are not building), you could use the new -nsu flag (no
snapshot updates) in Maven 3.0.4 so that snapshots,
Thanks, that is the most reasonable thing to do. Brining in a dependency
on aether a great choice for my usage(s) though. Fortunately it should be
pretty obvious in my case if this hack/assumption ever breaks.
-Original Message-
From: anders.g.ham...@gmail.com
18 matches
Mail list logo
