Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Where is the variable calculated?

 
Ranch Hand
Posts: 87
Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My EAR project has a .pom file which specifies a dependency version as a variable (which I've now commented and replaced with an absolute value).


When I use the variable, I get a build of version 4.0.0 whereas when I specify 4.0.1-SNAPSHOT I get the build from my .m2 repo which has the extra resources I've built it with.

Thing is, I've checked to see where the version for my-eng-ejb is being evaluated / retrieved from in:
The parent pom
EarContent/META-INF/application.xml
org.eclipse.wst.common.component

And they all specify 4.0.1-SNAPSHOT.

Where is 4.0.0 coming from then?

 
Sheriff
Posts: 4870
317
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your version declaration of ${y.version} will refer to a property defined in your pom.xml with that name

 
Iarla O'Riada
Ranch Hand
Posts: 87
Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's correct Tim Cooke, and it's defined as 4.0.1-SNAPSHOT there too. But the artifact that is built yields 4.0.0.
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Run this from a command line in you basedir and post the result:

mvn dependency:tree

Most likely some other dependency is also referencing the same dependency and Maven is choosing the non-snapshot version over the snapshot version.

The other thing you can do is run mvn with the -v option, redirect the output to a file and examine it looking for reference to that dependency to see how Maven is going about choosing a version to use.
 
Iarla O'Riada
Ranch Hand
Posts: 87
Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Peter Johnson. I tried to attach the output of "mvn dependency:tree", but the forum won't allow it (.txt or .zip). I'm reluctant to put project info from my (newly joined) company online where it can be easily indexed by search engines. I didn't realize this was an issue here and might make it difficult for me to use JavaRanch for more project-specific stuff, but the info you gave me will help me track down the issue I hope. I will rebuild with -v also and see what comes from that when I build next.
 
Peter Johnson
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand the necessity for keeping proprietary company information confidential. You can usually work around that in two ways:
a) come up with a small example that exhibits the same problem but doesn't include any proprietary information
b) obfuscate anything that could be proprietary (such as package names and JAR files name), but make sure that your renaming is consistent

But even with those restrictions, you can often get help here - we can give you hints on what to try and look at (such as the -v suggestion). Often that can be helpful.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic