AW: install:install - variables in POM are not replaced/filtered during installation in repository
Hi,
Is there no one that can answer my question? Sorry if I annoy anyone, but this
IS a question to the developers list - and I tried it on users, too, but no
answer there, and it may be a bug, or at least a behaviour that needs to be
stated in the user docu.
Cheers,
Frank
-Ursprüngliche Nachricht-
Gesendet: Donnerstag, 14. Juni 2007 14:39
An: Maven Developers List
Betreff: AW: install:install - variables in POM are not replaced/filtered
during installation in repository
Hi,
I still need help für this issue. Why are varibles aren't filtered during
installation in a repository? This sounds like a bug to me, or at least like a
strange behaviour - am I wrong? Please help someone!
Cheers,
Frank
Another example (without dependecy). The POM ist copied 1:1 to the repo,
without any filtering of variables.
-
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactIdaaa/artifactId
packagingjar/packaging
version${buildVersion}/version!-- NOT FILTERED DURING
INSTALL/DEPLOY IN REPO! --
properties
versionNo1.2/versionNo
buildVersion${versionNo}${point}${label}/buildVersion
/properties
/project
-
Settings.xml:
settings xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
profiles
profile
!-- CruiseControl builds should have a name like
aaa-1.2.build-123.jar, locally we use aaa-1.2-SNAPSHOT.jar --
idsetting_label/id
properties
point-/point !-- use . on the build server, -
locally --
labelSNAPSHOT/label !-- label is set automatically by
CruiseControl, use SNAPSHOT locally --
/properties
/profile
/profiles
activeProfiles
activeProfilesetting_label/activeProfile
/activeProfiles
/settings
-
-Ursprüngliche Nachricht-
Gesendet: Mittwoch, 23. Mai 2007 15:39
An: dev@maven.apache.org
Betreff: install:install - variables in POM are not replaced/filtered during
installation in repository
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi module projects for the
intern dependecies (dependencies to other modules) as well. So when Jar
AAA depends on Jar BBB that depends on Jar CCC (all version numbers are
variables), the POM of BBB is loaded, but then the further load of Jar
CCC fails, it tries to load XXX:CCC:jar:1.2${point}${label} or
XXX:CCC:jar:1.2${buildVersion} (the later in the multi module build).
Any suggestions? I'm glad for any assistence, since it cost me already
three days figuring that out
Cheers,
Frank
Example POM for AAA:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdXXX/groupId
artifactIdAAA/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
packagingjar/packaging
properties
versionNo1.2/versionNo
buildVersion${versionNo}${label}/buildVersion !-- label is
set differently in a local build and in the CruiseControl build --
/properties
...
dependencies
dependency
groupIdXXX/groupId
artifactIdBBB/artifactId
version${buildVersion}/version
typejar/type
/dependency
/dependencies
...
/project
Similiar example POM for BBB:
...
artifactIdBBB/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
...
dependency
groupIdXXX/groupId
artifactIdCCC/artifactId
version${buildVersion}/version
typejar/type
/dependency
...
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: install:install - variables in POM are not replaced/filtered during installation in repository
Hi,
I still need help für this issue. Why are varibles aren't filtered during
installation in a repository? This sounds like a bug to me, or at least like a
strange behaviour - am I wrong? Please help someone!
Cheers,
Frank
Another example (without dependecy). The POM ist copied 1:1 to the repo,
without any filtering of variables.
-
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdgroup/groupId
artifactIdaaa/artifactId
packagingjar/packaging
version${buildVersion}/version!-- NOT FILTERED DURING
INSTALL/DEPLOY IN REPO! --
properties
versionNo1.2/versionNo
buildVersion${versionNo}${point}${label}/buildVersion
/properties
/project
-
Settings.xml:
settings xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
profiles
profile
!-- CruiseControl builds should have a name like
aaa-1.2.build-123.jar, locally we use aaa-1.2-SNAPSHOT.jar --
idsetting_label/id
properties
point-/point !-- use . on the build server, -
locally --
labelSNAPSHOT/label !-- label is set automatically by
CruiseControl, use SNAPSHOT locally --
/properties
/profile
/profiles
activeProfiles
activeProfilesetting_label/activeProfile
/activeProfiles
/settings
-
-Ursprüngliche Nachricht-
Von: Steinhauer, Frank [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Mai 2007 15:39
An: dev@maven.apache.org
Betreff: install:install - variables in POM are not replaced/filtered during
installation in repository
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi module projects for the
intern dependecies (dependencies to other modules) as well. So when Jar
AAA depends on Jar BBB that depends on Jar CCC (all version numbers are
variables), the POM of BBB is loaded, but then the further load of Jar
CCC fails, it tries to load XXX:CCC:jar:1.2${point}${label} or
XXX:CCC:jar:1.2${buildVersion} (the later in the multi module build).
Any suggestions? I'm glad for any assistence, since it cost me already
three days figuring that out
Cheers,
Frank
Example POM for AAA:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdXXX/groupId
artifactIdAAA/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
packagingjar/packaging
properties
versionNo1.2/versionNo
buildVersion${versionNo}${label}/buildVersion !-- label is
set differently in a local build and in the CruiseControl build --
/properties
...
dependencies
dependency
groupIdXXX/groupId
artifactIdBBB/artifactId
version${buildVersion}/version
typejar/type
/dependency
/dependencies
...
/project
Similiar example POM for BBB:
...
artifactIdBBB/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
...
dependency
groupIdXXX/groupId
artifactIdCCC/artifactId
version${buildVersion}/version
typejar/type
/dependency
...
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: [VOTE] Release Maven 2.0.7 - surefire problem
I got the same error just some hours ago, using maven 2.0.6 and the surefire-plugin 2.3 . And yes, adding a dependcy to junit solved the problem. Only thing is, I don't use any unit tests in that project (used only to build a Jboss SAR file), so this behaviour seems a bit strange to me It seems the test phase always requires the junit dependency (I don't call it explicitly in the POM). Cheers, Frank -Ursprüngliche Nachricht- Von: Kenney Westerhof [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juni 2007 17:13 An: Maven Developers List Betreff: Re: [VOTE] Release Maven 2.0.7 - surefire problem Mark Donszelmann wrote: Hi Kenney, Hi Mark, I was using 2.1.3 for surefire. Changed it to 2.3, and still get error (slightly different): Hi, this is fixed later on; i think you're missing a dependency on junit. Let me know if this is the case. Can't be due to 2.0.7 though, unless this works in 2.0.6? If there's no released version (2.3) that works for 2.0.7 then we need to release 2.3.1 asap. -- Kenney java.lang.NullPointerException at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) My pom (fragment): plugin artifactIdmaven-surefire-plugin/artifactId version2.3/version configuration forkModepertest/forkMode includes include**/*TestSuite.java/include /includes excludes exclude**/TestSuite.java/exclude /excludes /configuration /plugin Could not test SNAPSHOTs yet. Regards Mark Donszelmann On Jun 13, 2007, at 6:18 AM, Kenney Westerhof wrote: Hi, can you find the surefire plugin version you're using? I've fixed this problem in the latest snapshots. Only the snapshots were faulty, latest release should be fine. If that one is broken too, can you try one of the latest snapshots (2.4-snapshot or 2.3.1-snapshot), so we can determine wheter it's a fault in surefire or in maven 2.0.7? Thanks, Kenney Mark Donszelmann wrote: Hi tried 2.0.7 on FreeHEP, seems to work on most parts, except it tells me following in one case: RUN ABORTED java.lang.LinkageError org.apache.maven.surefire.Runner An exception or error caused a run to abort. Class org/codehaus/plexus/util/xml/Xpp3Dom violates loader constraints running with -e gives me: org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at
AW: install:install - variables in POM are not replaced/filtered during installation in repository
XXX:BBB knows at build time which version it needs of XXX:CCC, the problem is,
that it's POM is copied directly to the local repo, without replacing the
variables (as it should to my opinion). XXX:AAA knows nothing about the XX:BBB
variables, nor should it know.
- Frank
-Ursprüngliche Nachricht-
Von: Evan Worley [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Mai 2007 18:29
An: Maven Developers List
Betreff: Re: install:install - variables in POM are not replaced/filtered
during installation in repository
Maybe someone else can chime in here, but if XXX:AAA is not the parent of
XXX:BBB I don't think XXX:BBB will have the buildVersion property defined.
If that property isn't defined then XXX:BBB will not be able to resolve a
dependency to XXX:CCC because it doesn't know which version you want, since
${buildVersion} isn't defined.
Perhaps I am missing something?
-Evan
On 5/23/07, Steinhauer, Frank [EMAIL PROTECTED] wrote:
Hi Evan,
XXX:AAA is not the parent of XXX:BBB. I've tried two scenarios, one
multi-module project, where 10 JARs are built, and some jars depending on
previous built ones (here I'm using dependencyManagement in the top most
POM, setting the version number for the jar/module dependencies to the same
as used for that POM), and for testing purpose some single projects, that
are depending on each other.
Here's my setting.xml snippet:
profiles
profile
idsetting_label/id
properties
point-/point !-- use . on the CC server, - local
--
labelSNAPSHOT/label!-- is set automatically by CC, use
SNAPSHOT locally --
/properties
/profile
/profiles
activeProfiles
activeProfilesetting_label/activeProfile
/activeProfiles
-Frank
-Ursprüngliche Nachricht-
Von: Evan Worley [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Mai 2007 17:30
An: Maven Developers List
Betreff: Re: install:install - variables in POM are not replaced/filtered
during installation in repository
Hi Frank,
From the information you posted, I have a few questions.
1. Is XXX:AAA the parent of XXX:BBB? If not, I don't believe XXX:BBB
would
not inherit the definition of the ${buildVersion} property.
2. Where do you set ${label}, in your settings.xml? If so can you post
the
relevant snippet?
-Evan
On 5/23/07, Steinhauer, Frank [EMAIL PROTECTED] wrote:
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi module projects for the
intern dependecies (dependencies to other modules) as well. So when Jar
AAA depends on Jar BBB that depends on Jar CCC (all version numbers are
variables), the POM of BBB is loaded, but then the further load of Jar
CCC fails, it tries to load XXX:CCC:jar:1.2${point}${label} or
XXX:CCC:jar:1.2${buildVersion} (the later in the multi module build).
Any suggestions? I'm glad for any assistence, since it cost me already
three days figuring that out
Cheers,
Frank
Example POM for AAA:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdXXX/groupId
artifactIdAAA/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
packagingjar/packaging
properties
versionNo1.2/versionNo
buildVersion${versionNo}${point}${label}/buildVersion
!-- point and label are set differently in a local build and in the
CruiseControl build --
/properties
...
dependencies
dependency
groupIdXXX/groupId
artifactIdBBB/artifactId
version${buildVersion}/version
typejar/type
/dependency
/dependencies
...
/project
Similiar example POM for BBB:
...
artifactIdBBB/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
...
dependency
groupIdXXX/groupId
artifactIdCCC/artifactId
version${buildVersion}/version
typejar/type
/dependency
...
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
install:install - variables in POM are not replaced/filtered during installation in repository
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi module projects for the
intern dependecies (dependencies to other modules) as well. So when Jar
AAA depends on Jar BBB that depends on Jar CCC (all version numbers are
variables), the POM of BBB is loaded, but then the further load of Jar
CCC fails, it tries to load XXX:CCC:jar:1.2${point}${label} or
XXX:CCC:jar:1.2${buildVersion} (the later in the multi module build).
Any suggestions? I'm glad for any assistence, since it cost me already
three days figuring that out
Cheers,
Frank
Example POM for AAA:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdXXX/groupId
artifactIdAAA/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
packagingjar/packaging
properties
versionNo1.2/versionNo
buildVersion${versionNo}${label}/buildVersion !-- label is
set differently in a local build and in the CruiseControl build --
/properties
...
dependencies
dependency
groupIdXXX/groupId
artifactIdBBB/artifactId
version${buildVersion}/version
typejar/type
/dependency
/dependencies
...
/project
Similiar example POM for BBB:
...
artifactIdBBB/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
...
dependency
groupIdXXX/groupId
artifactIdCCC/artifactId
version${buildVersion}/version
typejar/type
/dependency
...
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: install:install - variables in POM are not replaced/filtered during installation in repository
Hi Evan,
XXX:AAA is not the parent of XXX:BBB. I've tried two scenarios, one
multi-module project, where 10 JARs are built, and some jars depending on
previous built ones (here I'm using dependencyManagement in the top most POM,
setting the version number for the jar/module dependencies to the same as used
for that POM), and for testing purpose some single projects, that are depending
on each other.
Here's my setting.xml snippet:
profiles
profile
idsetting_label/id
properties
point-/point !-- use . on the CC server, - local --
labelSNAPSHOT/label!-- is set automatically by CC, use SNAPSHOT
locally --
/properties
/profile
/profiles
activeProfiles
activeProfilesetting_label/activeProfile
/activeProfiles
-Frank
-Ursprüngliche Nachricht-
Von: Evan Worley [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 23. Mai 2007 17:30
An: Maven Developers List
Betreff: Re: install:install - variables in POM are not replaced/filtered
during installation in repository
Hi Frank,
From the information you posted, I have a few questions.
1. Is XXX:AAA the parent of XXX:BBB? If not, I don't believe XXX:BBB would
not inherit the definition of the ${buildVersion} property.
2. Where do you set ${label}, in your settings.xml? If so can you post the
relevant snippet?
-Evan
On 5/23/07, Steinhauer, Frank [EMAIL PROTECTED] wrote:
Hello,
during installation of the POM in the local repository the variables are
not replaced/filtered. Is this a bug or purpose? Or did I a make a
mistake somewhere?
Explanation:
In our POMs we set the version numbers according to local settings and
given CLI parameters, and do this in our multi module projects for the
intern dependecies (dependencies to other modules) as well. So when Jar
AAA depends on Jar BBB that depends on Jar CCC (all version numbers are
variables), the POM of BBB is loaded, but then the further load of Jar
CCC fails, it tries to load XXX:CCC:jar:1.2${point}${label} or
XXX:CCC:jar:1.2${buildVersion} (the later in the multi module build).
Any suggestions? I'm glad for any assistence, since it cost me already
three days figuring that out
Cheers,
Frank
Example POM for AAA:
?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
modelVersion4.0.0/modelVersion
groupIdXXX/groupId
artifactIdAAA/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
packagingjar/packaging
properties
versionNo1.2/versionNo
buildVersion${versionNo}${point}${label}/buildVersion
!-- point and label are set differently in a local build and in the
CruiseControl build --
/properties
...
dependencies
dependency
groupIdXXX/groupId
artifactIdBBB/artifactId
version${buildVersion}/version
typejar/type
/dependency
/dependencies
...
/project
Similiar example POM for BBB:
...
artifactIdBBB/artifactId
version${buildVersion}/version!-- used throughout all of our
projects/modules --
...
dependency
groupIdXXX/groupId
artifactIdCCC/artifactId
version${buildVersion}/version
typejar/type
/dependency
...
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
