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 [mailto:anders.g.ham...@gmai
On Wed, Sep 26, 2012 at 11:21 AM, Ben Caradoc-Davies
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, once downloaded, are not
> c
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 mak
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 Comm
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 th
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"
To:
"Maven Users
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 i
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
app
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.
> 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: users-unsubscr...@maven.apache.o
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
ne
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 GUI
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 javax
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. Howeve
> > 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.
> >>
>
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 deploy
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
(
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 wrote:
> Using mvn 3.0.4, when a SNAPSHOT artifact is resolved from a
18 matches
Mail list logo