Hi
Ok, I found the problem, and it's my fault :-)
Looks like it's a bad idea to let the plugin run only for the 'test-compile'
goal, especially with my special configuration. So I corrected it to run both
on 'compile' and 'test-compile'.
Best regards,
Eric
-
We have found that SpringJUnit4ClassRunner is not compatible with the
4.5+ versions of JUnit.
I think that you will find that in
private UsuarioFacade usuarioFacade;
that UsuarioFacade must be an interface in order for Spring to do it's
magic. Is this the case?
This does
Sorry taking so long to respond but I have several things happening. I love
the idea of removing Maven from the equation (Though I'd love to also have a
Maven solution). I never thought of self-executable wars with
Jetty/Winstone. Can you give me an example of the packaging for this? Is it
a
We have found that SpringJUnit4ClassRunner is not compatible with the
4.5+ versions of JUnit.
I think that you will find that in
private UsuarioFacade usuarioFacade;
that UsuarioFacade must be an interface in order for Spring to do it's
magic. Is this the case?
This does not
Dear folks, I'm using Maven (and maven-ant-task) to check project
dependencies.
I have a project A-1.0.0 which depends by an artifact B-1.0.0 and C-1.0.1.
At the same time artifact B-1.0.0 depends by artifact C-1.0.0.
Artifacts C-1.0.0 and C-1.0.1 are not interchangeable, so or I use version
Hi,
I guess you could use the enforcer plugin:
http://maven.apache.org/plugins/maven-enforcer-plugin/
I think the bannedDependencies rule could be added to project A (for
C-1.0.0). Haven't tried it though.
/Anders
On Mon, Jul 6, 2009 at 15:27, Paolo.Mosnapaolo.mo...@gmail.com wrote:
Dear
Thanks Anders,
I think your proposed solution would work.
Now I did put the following in the pom.xml of project A:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0-beta-1/version
Thanks Stephen for explaining how the LATEST would have worked against
artifacts. Would it be possible to update the documentation (the definitive
guide) to make it clear that LATEST is meant for plugins? Right now, that
doc contradicts the way LATEST behaves.
--
View this message in context:
I've run into the same problem with Cobertura and Spring - what seemed to
fix it was, in the context file, changing aop:config to aop:config
proxy-target-class=true. I'm not entirely sure *why* that worked (I dealt
with this a couple months ago, and it required a *lot* of googling to get
any kind
Dave,
Thanks a lot for your detailed explaination. I will try this out and let you
know.
one last question. If i want to update the property files, will my jar file
picksup the updates automatically or do i need to build it again?
Thanks,
Sundar
David Weintraub wrote:
There are two issues I
I'm not saying it is the case here, but sometimes the doc/examples (of
any software) isn't 100% correct. Try executing Maven with the -e or
the -X flag to possibly get some more info.
/Anders
On Mon, Jul 6, 2009 at 16:51, Paolo.Mosnapaolo.mo...@gmail.com wrote:
Thanks Anders,
I think your
On Mon, Jul 6, 2009 at 3:29 PM, mavenusrsundarva...@gmail.com wrote:
one last question. If i want to update the property files, will my jar file
picksup the updates automatically or do i need to build it again?
Um... I thought the properties file wasn't in your JAR.
If you put the properties
Hi there,
I have been using the 'maven-archetype-plugin' and the 'create-from-project'
more recently and I wanted to find what best practices others use when
trying to maintain the development of thir own or company archetypes.
So picture this scene, I start my brand new maven project based the
Thanks Stephen for explaining how the LATEST would have worked against
artifacts. Would it be possible to update the documentation (the definitive
guide) to make it clear that LATEST is meant for plugins? Right now, that
doc contradicts the way LATEST behaves.
As that book is a product of
Thanks. Yes. My property files are n't part of the JAR.
so again my question is, if i change the property files, will the JAR
automically pickup the change without the need for rebuilding it?
David Weintraub wrote:
On Mon, Jul 6, 2009 at 3:29 PM, mavenusrsundarva...@gmail.com wrote:
one
If your target class does not implement an interface Spring uses the CGLIB
library to generate a subclass
to the target class
When creating the subclass Spring creates
Advice
delegates calls for subclass to Target class
you will need to deploy all of cglib to lib/cglib folder
if the target
I think Kohsuke was one of the first to implement it - his blog post
on it should help:
http://weblogs.java.net/blog/kohsuke/archive/2007/02/hudson_became_s.html
Kalle
On Mon, Jul 6, 2009 at 6:13 AM, Cliftonclifton.cr...@gmail.com wrote:
Sorry taking so long to respond but I have several
If your target class does not implement an interface Spring uses the CGLIB
library to generate a subclass to the target class
When creating the subclass Spring creates
Advice
delegates calls for subclass to Target class
you will need to deploy all of cglib to lib/cglib folder
if the target
Hey, Tim,
where are you??? One year ago, you wrote and wrote and wrote for The
definitive guide.
Now it's in Version 0.6 and not much if not nothing at all has changed
during the last months.
Also, I can't wait to see the new Maven cookbook! Maybe you got an alpha at
hand?
Just let me know, I
19 matches
Mail list logo
