Hi Stephen,
The organizational pom can prescribe the use of the most recently
released ruleset.
The next version of the ruleset would "technically" be checked against
the previous version, but as rulesets are not java code the check will
not be applied on that artifact.
True.
But its a littl
2010 11:55, Andreas Sewe
wrote:
> Hi Wayne,
>
> thanks for the advice.
>
>>> What's the best way to resolve this kind of chicken-and-egg problem
>>> without introducing too many extra projects just to break the cycle? Any
>>
>> This is exactly wh
Hi Wayne,
thanks for the advice.
What's the best way to resolve this kind of chicken-and-egg problem
without introducing too many extra projects just to break the cycle? Any
This is exactly what you have to do. The rulesets should be packaged
and versioned independent of the project. Id
> What's the best way to resolve this kind of chicken-and-egg problem
> without introducing too many extra projects just to break the cycle? Any
This is exactly what you have to do. The rulesets should be packaged
and versioned independent of the project. Ideally you'd have one
c
Hi all,
I am experiencing a kind of chicken-and-egg problem in my usage of the
m-pmd-p, the m-checkstyle-p, and the m-license-p. All these plugins are
capable of loading their respective configurations (rulesets or license
headers) from the plugin's classpath. As such it seems sensible to
c
FYI: the egg came first:
http://www.cnn.com/2006/TECH/science/05/26/chicken.egg/index.html
Thus, it's not really a chicken and egg problem. :-)
Dan
On Wednesday July 12 2006 2:38 pm, javaguy1974 wrote:
> Hello,
>
> I encountered the following problem (Maven 2.0.4):
>
OK, thanks for explaining this to me!
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a5310059
Sent from the Maven - Users forum at Nabble.com.
-
To
or else the jar do not contain postprocess classes as the
postprocess is made too late)
child pom -> specify the conf of the postprocess (schema )
cordialement
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a530954
pass
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a5307643
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [
On 7/13/06, javaguy1974 <[EMAIL PROTECTED]> wrote:
It would be nice if Maven provided a capability for a child POM to ignore
some inherited stuff like plugins. Otherwise, it is very difficult to design
a truly top-level organizational POM that is shared by all projects. I'm not
sure what you act
o you mean
change the plugin POM so it no longer depends on the parent? This is exactly
what I did by copying and pasting some settings from the parent but again
that is not a desired solution.
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritan
From: javaguy1974 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 1:38 PM
To: users@maven.apache.org
Subject: Chicken and egg problem (disabling inheritance)
Hello,
I encountered the following problem (Maven 2.0.4):
There is a top-level (organizational) POM which is inherited by all
Well, this is still not what I'm looking for. This would require to redeclare
the plugin in many child POMs which inherit from the top-level one (30+).
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a5295755
Sent
Use "pluginManagement" instead?
-Original Message-
From: javaguy1974 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 12, 2006 1:50 PM
To: users@maven.apache.org
Subject: Re: Chicken and egg problem (disabling inheritance)
Actually, the only "solution" that I f
pty
tag in the child POM but it didn't help.
Thanks!
Lukasz
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a5294856
Sent from the Maven - Users forum at Nabble.com.
--
Actually, the only "solution" that I found is to merge top-level POM
(excluding the plugin) to the child POM and not inherit from the top-level
POM.
--
View this message in context:
http://www.nabble.com/Chicken-and-egg-problem-%28disabling-inheritance%29-tf1932757.html#a5295095
Sen
Charles,
>From one of your earlier messages in this thread, you said you need
the jar to package into a war and/or ear. It sounds like either you
are:
1. trying to build multiple artifacts in the same project or
2. using subprojects, but putting your dependencies at the parent
level.
If
<
I'm trying to compile a set of source code X that will be packaged into
jar X. If I don't have an old version of jar X in the classpath, no
problem. If I have old jar X in the classpath, then occasionaly source x
will not compile.
Here's a way to duplicate this problem: Focus on some
"Charles Tassoni" <[EMAIL PROTECTED]> wrote on 24/12/2003
08:04:24 AM:
> Thanks to Charles-Alexandre Sabourdin and dion for their advice.
> The suggestions didn't work for me. When I set
> ${pom.currentVersion} on the jar I'm trying to build
on
> the fly, I got exactly the same result
Thanks to Charles-Alexandre Sabourdin and dion for their advice.
The suggestions didn't work for me. When I set
${pom.currentVersion} on the jar I'm trying to build on
the fly, I got exactly the same result: maven simply resolved
${pom.currentVersion} to "1.0" and put the outdated 1.0 ja
Use SNAPSHOT
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
"Charles Tassoni" <[EMAIL PROTECTED]> wrote on 23/12/2003
02:49:43 AM:
> I've got a chicken-and-egg problem. I need to declare the jars
> created by my
Le Lundi 22 Décembre 2003 16:49, Charles Tassoni a écrit :
> I've got a chicken-and-egg problem. I need to declare the jars
> created by my project inside project.xml-- otherwise I couldn't use maven
> to distribute them to the necessary ears, wars, etc. And that means
I've got a chicken-and-egg problem. I need to declare the jars
created by my project inside project.xml-- otherwise I couldn't use maven to
distribute them to the necessary ears, wars, etc. And that means that when
I build maven will load earlier versions of my jars into the
23 matches
Mail list logo
