Ivan,
I quickly created this tag provided bellow and it reads the manifest
file. I do deploy to numerous webapps and the deployment directory
differs between tomcat and websphere, I omitted where I handle that
difference.
Using the ant tasks, my manifest looks like this
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.)
Author: admin
Bundle-Name: DemoApp
Bundle-Vendor: ABC Inc
Bundle-Build: 20051123-bp1608
Bundle-Version: 20051123-bp1608.019
Bundle-Date: December 28 2005
My jsp calls <l:manifest attributeName="Bundle-Build"/> to retrieve the
build and <l:manifest attributeName=" Bundle-Date "/> to retrieve the
date.
Still needs more work, but it works.
public class ManifestReaderTag extends TagSupport {
private String _attributeName;
/**
*
*/
public ManifestReaderTag() {
super();
}
/**
* @return Returns the _attributeName.
*/
public String getAttributeName() {
return _attributeName;
}
/**
* @param name The _attributeName to set.
*/
public void setAttributeName(String name) {
_attributeName = name;
}
public int doStartTag() throws JspException {
readManifest();
return SKIP_BODY;
}
/**
* @see javax.servlet.jsp.tagext.Tag#doEndTag()
*/
public int doEndTag() throws JspException {
return super.doEndTag();
}
private void readManifest() {
/* read our manifest and display values */
JarFile jarFile = null;
Attributes jarAttribs = null;
if(getAttributeName() != null) {
try{
Package thePackage = getClass().getPackage();
String theClass = "/"+thePackage.getName().replace('.','/') +
"/ManifestReaderTag.class";
URL turl = getClass().getResource(theClass);
if(turl != null) {
String pathToThisClass = turl.toString();
/* appserver differences exists
code omitted
*/
String manifestPath = pathToThisClass +
"/META-INF/MANIFEST.MF";
//check if jar:file: present (shows up in eclipse)
int pos = manifestPath.indexOf("jar:file:/");
if(pos > -1)
manifestPath = manifestPath.substring(pos+10,
manifestPath.length());
File theFile = new File(manifestPath);
if(theFile != null) {
FileInputStream fis = new FileInputStream(theFile);
//Manifest manifest = new Manifest(new
URL(manifestPath).openStream());
Manifest manifest = new Manifest(fis);
if(manifest != null) {
jarAttribs =
manifest.getMainAttributes();
if(jarAttribs !=null) {
if(jarAttribs.containsKey(getAttributeName()))
pageContext.getOut().write(jarAttribs.getValue(getAttributeName()));
else
pageContext.getOut().write("Missing Attribute in Manifest.MF");
}
fis.close();
}
}
}
}catch (IOException ioe) {
System.err.println("Error reading manifest file for
properties lookup : " + ioe.toString());
} finally {
if(jarFile != null)
try{
jarFile.close();
} catch(java.io.IOException ioe) {
//nothing to do
}
}
}
}
}
-----Original Message-----
From: Ivan Ivanov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 28, 2005 4:57 PM
To: Ant Users List
Subject: Re: using buildnumber effectively
Hello Eric,
Using Alexey's code (I was going to provide similar
one) you can easily build a taglib that will extract
the desired version and show it in your JSPs.
Regards
Ivan
--- "Alexey N. Solofnenko" <[EMAIL PROTECTED]>
wrote:
> 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
>
=== message truncated ===
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/
---------------------------------------------------------------------
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]
