This is RTFM:
Package pkg = clazz.getPackage(); // there are classes without packages
String version=(pkg==null ? null : pkg.getImplementationVersion());
- Alexey.
Ferrer, Eric wrote:
I had tried that with a version.html and that works great. Has anyone
successfully tried using the manifest.mf as a source for storing
build/release/version information and successfully reading it at
run-time to display in a jsp?
-----Original Message-----
From: Ivan Ivanov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 28, 2005 4:14 PM
To: Ant Users List
Subject: RE: using buildnumber effectively
Hello,
You can add a token in your web pages, says
@BUILD_NUMBER@ and either replace it with <replace> or
with <copy> and <filterchain>.
Regards
Ivan
--- "Ferrer, Eric" <[EMAIL PROTECTED]> wrote:
Maybe this should be a new thread, but once you
increment your build
number, what is the best practice to show this
build/release in your
applications?
For instance, I would want to see the build/release
number on the footer
of my website.
-----Original Message-----
From: Mark Lybarger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 20, 2005 5:53 AM
To: Ant Users List
Subject: Re: using buildnumber effectively
that's definately a great idea. how do i get the
branch name of cvs
from within ant? basically, which cvs branch is
this?
On 12/19/05, Anderson, Rob (Global Trade)
<[EMAIL PROTECTED]> wrote:
Now, suppose I branch the project to create
REL_4_1.
Development is still occuring in the head,
but REL_4_1 is
gearing
towards production.
The version number would get bumped in this
branch, and not
reflected back into the head. Is there a way
to do the
CVS merging
from the ant checkin?
Not sure I understand what you are asking
here. It is OK to
release
REL_4_1 to production and have the main branch
at say build
REL_5 or
REL_6. When you merge the changes in REL_4_1
to main, just bump
the
main buildnumber again. So your production
system may see REL_4,
REL_4_1, and then REL_7. The sequence of
buildnumbers does not
necessarily need to be contiguious.
there seems to be a break in the process, or at
least some
manual intervention required. say the
buildnumber in the
head is sitting at
10, and i create a branch REL_1_1. The
buildnumber in this branch
is
incremented to 20 through various releases to
test, and
finally production. Meanwhile, the head branch
never gets
released, and the version number is still
sitting at 10.
My question/confusion is regarding where / how
the merging of
the version number back into the head occur?
When the next
project comes along and wants to go to test,
they'll branch
from the head, and create a branch called
REL_1_2. If the
version number is never merged back into the
head. This
seems to be a manual process that must occur
"every so often"
or rather when ever an application goes to
production, the
version in the head needs to be evaluated.
How do i keep the version number in the head in
sync with the
version number in the branches?
OK. So if the build number on main is 10, then
your buildnumber file
would contain the number 10 in it. When you
branch, I would recommend
naming the branch based on the build number it is
branched from, in
this
case build 10, or perhaps REL_10 as tagged in cvs.
So name the branch
REL_10 or REL_branch_10. Then on the branch reset
the buildnumber to
0.
Then builds from the branch will be named
REL_branch_10_1,
REL_branch_10_2, REL_branch_10_3, ect. On main,
you continue with the
naming convention REL_10, REL_11, REL_12, etc.
When you decide to
branch
from main again, you follow the same standard. Say
you wish to branch
off of REL_12, a branch named REL_branch_12 is
created and builds from
that branch are called REL_branch_12_1,
REL_branch_12_2,
REL_branch_12_3, etc. Bassically my recommendation
is to somehow
include
the branch name into the build name (or cvs tag)
and use buildnumber
to
increment the number on each branch. Initial setup
of a branch would
include reseting the buildnumber file to 0. With
the branch name in
the
build name (cvs tag), you don't need to have the
buildnumber is sync
between main and any branches.
I hope this helps.
-Rob Anderson
---------------------------------------------------------------------
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]
__________________________________________
Yahoo! DSL - Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
---------------------------------------------------------------------
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]
