ng the same settings.xml with 3.0.4 ? You'd be
> missing
> > the credentials?
> >
> > My 2 cents
> > -- Baptiste
> > Le 16 août 2013 08:57, "Bengt Rodehav" a écrit :
> >
> > > Alan, we have the exact problem that you have. We just
Alan, we have the exact problem that you have. We just upgraded from Maven
2.2.1 to Maven 3.0.4 when this started to happen.
Did you manage to resolve your problem? Do you have any hints as to what is
going on?
/Bengt
2013/7/8 Alan Buck
> I forgot to show the .
>
>
>
> i
Why not full client + some reasonable (small)
> handful of other dependencies?
>
> Wayne
>
> On Fri, Nov 11, 2011 at 5:00 PM, Bengt Rodehav wrote:
> > It works but the full client is not enough for us to be able to build our
> > application.
> >
> > Den 11 nov 20
It works but the full client is not enough for us to be able to build our
application.
Den 11 nov 2011 23:11 skrev "Ryan Connolly" :
>
> Does this no longer work?
> http://docs.oracle.com/cd/E12840_01/wls/docs103/client/t3.html
> On Nov 11, 2011 3:38 PM, "Bengt Rodehav
Stephen and Wayne,
I agree that using system scope is undesirable. However, there is a reason
why maven has had this support - it is needed in real life. In my case, I
use Weblogic. When first trying to migrate our old ant based build system
to maven, I started out by trying to put the Weblogic j
We are using maven 3.0.3 and have problems using property values defined in
our local settings.xml for specifying systemPath values for system-scoped
dependencies. It seems this possibility has been removed in maven 3.
The system-scoped variable is necessary because we depend directly on a
third p
in 30 minute planning session and a 15 minute
> review prior to going into test and a short conference or e-mail when a
> module has to be changed that was not on the original list for the release,
> this appears to work.
>
> Ron
>
>
> On 15/09/2010 6:09 AM, Bengt Rodehav wro
gt; problem at all for us, but we actually hardly need it.
>
> For the dev process, only in my opinion, I think automatically releasing
> every nights isn't a very good pratice. I rather think the release process
> should be actually 100% standalone, but *manually* initiated (giving t
We've had similar questions where I work. The question has been related to
how and when to create tags in CVS (preferrably using the
maven-release-plugin).
Some people advocate tagging every build so that it can be recreated in case
it was fit for delivery. This is a problem when using CVS since h
ram ( mvn -X ) and look at the debug info
> to see what classpath was set up for the features-maven-plugin, and
> insure it has the pax-url-mvn artifact.
>
> And, also, check that the pax-url-mvn artifact does indeed provide the
> "mvn:" protocol implementation.
>
&
No I haven't but it's a good idea - I will do that.
Thanks,
/Bengt
2010/5/9 Justin Edelson :
> Have you posted this to a pax mailing list?
>
> On May 9, 2010, at 5:42 AM, Bengt Rodehav wrote:
>
>> Thanks for you reply Marshal,
>>
>> I've tried
oblem has to do with maven 3, and possibly the class
loading changes that you mentioned. Just can't get it to work though.
Any more ideas?
/Bengt
2010/5/8 Marshall Schor :
>
>
> On 5/8/2010 2:55 AM, Bengt Rodehav wrote:
>> No one has any ideas?
>>
>
> Here'
om the alpha to
the beta version that could break url handlers.
/Bengt
2010/5/7 Bengt Rodehav :
> I'm using the features-maven-plugin included in Apache Felix. It in
> turn uses "pax-url-mvn" (version 1.1.2) to enable the protocol "mvn:".
>
> This works fine i
I'm using the features-maven-plugin included in Apache Felix. It in
turn uses "pax-url-mvn" (version 1.1.2) to enable the protocol "mvn:".
This works fine in maven 2.2.1 and also in maven 3.0-alpha-7. However,
with everything else the same, it fails under maven 3.0-beta-1. I get
"java.net.Malfo
14 matches
Mail list logo