You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steve Cohen <sc...@javactivity.org> on 2012/01/11 22:13:46 UTC
Re: Howto access project version programatically within application
Thanks for explaining this mysterious result.
I have found that using the pom.properties that Maven creates is a more
straightforward approach and also can be made to work when the program
is not run from the jar (i.e., from Eclipse).
Thanks.
On 01/11/2012 02:30 PM, Rainer Pruy wrote:
> Looks like there are other jar (or classes directories) in classpath.
>
> getRessourceAsStream() will access the first entry (according to current
> classloader logic)
> and this need not be the one from the jar you are interested in.
> You might use getRessources() to get all candidates enumerated.
> (This was what lead me to get an URL from a class that resides with the
> same jar and explicitly read that file as outlined in my previous reply)
>
> Rainer
>
> On 11.01.2012 20:41, Steve Cohen wrote:
>> On 01/11/2012 12:14 PM, Wayne Fay wrote:
>>>> getResourceAsStream("META_INF/MANIFEST.MF") and
>>>> getResourceAsStream("/META_INF/MANIFEST.MF") without success even
>>>> though
>>>> I've verified that the file exists in the jar,
>>>
>>> Uhh that should be META-INF, right?
>>>
>>> Wayne
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>> Duh - that's it.
>>
>> However -- fixing that the code now sees the manifest. However, the
>> manifest it sees is not the one that I see when looking at the file in
>> the jar with WinZip.
>>
>> Here is META-INF/MANIFEST.MF in the jar:
>>
>> Manifest-Version: 1.0
>> Archiver-Version: Plexus Archiver
>> Created-By: Apache Maven
>> Build-Jdk: 1.6.0_23
>> Built-By: Steve
>> Implementation-Title: MyApp
>> Implementation-Version: 0.6.1-SNAPSHOT
>> Implementation-Vendor-Id: com.whatever
>> Main-Class: com.whatever.Main
>> SplashScreen-Image: SplashScreen.jpg
>>
>> Yet when my app reads the manifest
>> ( getResourceAsStream("META_INF/MANIFEST.MF" )
>> and then iterates through the manifest attributes, it sees this:
>>
>> Manifest-Version : 1.0
>> Created-By : 1.4.2 (IBM Corporation)
>>
>> If I specify instead
>> getResourceAsStream("/META_INF/MANIFEST.MF") then the file is not found.
>>
>> I can't make any sense of these symptoms. Manifests are just too
>> weird, it seems.
>>
>> Unless someone can explain this weirdness, I'll try the approach with
>> maven.properties.
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Howto access project version programatically within application
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/11/2012 03:22 PM, Rainer Pruy wrote:
> But beware that reading "pom.properties" might expose similar problem
> as soon as there is a second jar (or some classes directory) with such
> file (name).
>
> This is intrinsic to anything that uses getResource*() family of methods
> (at least under the hood)
> A dirty hack for avoiding that trouble would be to use a file name that
> likely is unique to your application.
>
> Rainer
>
> On 11.01.2012 22:13, Steve Cohen wrote:
>> Thanks for explaining this mysterious result.
>> I have found that using the pom.properties that Maven creates is a
>> more straightforward approach and also can be made to work when the
>> program is not run from the jar (i.e., from Eclipse).
>>
>> Thanks.
>>
Hmm. See my reply to your original post.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Howto access project version programatically within application
Posted by Steve Cohen <sc...@javactivity.org>.
On 01/11/2012 03:22 PM, Rainer Pruy wrote:
> But beware that reading "pom.properties" might expose similar problem
> as soon as there is a second jar (or some classes directory) with such
> file (name).
>
> This is intrinsic to anything that uses getResource*() family of methods
> (at least under the hood)
> A dirty hack for avoiding that trouble would be to use a file name that
> likely is unique to your application.
>
> Rainer
>
Actually, this is not a problem.
The pom.properties is accessed by an URL such as
"META-INF/maven/com.whatever/MyApp/pom.properties", which should be
unique. This is not the case with META-INF/MANIFEST.MF.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Howto access project version programatically within application
Posted by Rainer Pruy <Ra...@Acrys.COM>.
But beware that reading "pom.properties" might expose similar problem
as soon as there is a second jar (or some classes directory) with such
file (name).
This is intrinsic to anything that uses getResource*() family of methods
(at least under the hood)
A dirty hack for avoiding that trouble would be to use a file name that
likely is unique to your application.
Rainer
On 11.01.2012 22:13, Steve Cohen wrote:
> Thanks for explaining this mysterious result.
> I have found that using the pom.properties that Maven creates is a
> more straightforward approach and also can be made to work when the
> program is not run from the jar (i.e., from Eclipse).
>
> Thanks.
>
> On 01/11/2012 02:30 PM, Rainer Pruy wrote:
>> Looks like there are other jar (or classes directories) in classpath.
>>
>> getRessourceAsStream() will access the first entry (according to current
>> classloader logic)
>> and this need not be the one from the jar you are interested in.
>> You might use getRessources() to get all candidates enumerated.
>> (This was what lead me to get an URL from a class that resides with the
>> same jar and explicitly read that file as outlined in my previous reply)
>>
>> Rainer
>>
>> On 11.01.2012 20:41, Steve Cohen wrote:
>>> On 01/11/2012 12:14 PM, Wayne Fay wrote:
>>>>> getResourceAsStream("META_INF/MANIFEST.MF") and
>>>>> getResourceAsStream("/META_INF/MANIFEST.MF") without success even
>>>>> though
>>>>> I've verified that the file exists in the jar,
>>>>
>>>> Uhh that should be META-INF, right?
>>>>
>>>> Wayne
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>> Duh - that's it.
>>>
>>> However -- fixing that the code now sees the manifest. However, the
>>> manifest it sees is not the one that I see when looking at the file in
>>> the jar with WinZip.
>>>
>>> Here is META-INF/MANIFEST.MF in the jar:
>>>
>>> Manifest-Version: 1.0
>>> Archiver-Version: Plexus Archiver
>>> Created-By: Apache Maven
>>> Build-Jdk: 1.6.0_23
>>> Built-By: Steve
>>> Implementation-Title: MyApp
>>> Implementation-Version: 0.6.1-SNAPSHOT
>>> Implementation-Vendor-Id: com.whatever
>>> Main-Class: com.whatever.Main
>>> SplashScreen-Image: SplashScreen.jpg
>>>
>>> Yet when my app reads the manifest
>>> ( getResourceAsStream("META_INF/MANIFEST.MF" )
>>> and then iterates through the manifest attributes, it sees this:
>>>
>>> Manifest-Version : 1.0
>>> Created-By : 1.4.2 (IBM Corporation)
>>>
>>> If I specify instead
>>> getResourceAsStream("/META_INF/MANIFEST.MF") then the file is not
>>> found.
>>>
>>> I can't make any sense of these symptoms. Manifests are just too
>>> weird, it seems.
>>>
>>> Unless someone can explain this weirdness, I'll try the approach with
>>> maven.properties.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org