Anyone for or against this?

Pro: Will provide the version from the MANIFEST.MF in the jar file.
Con: Only provides the correct value when Wicket is running from a JAR.

/Gwyn

On 31/03/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> I suspected that might be the case with the test - could investigate
> running a subset of tests on the jar after it's built, but is it worth
> it?
>
> I didn't think that Class.forName would be an issue, as it was being
> called from a Wicket class itself, but taking that further, as it's
> running within a Wicket class, I think it can simply do this...
>
> public String getVersion()
> {
>         String implVersion = null;
>         Package pkg = getClass().getPackage();
>         if (pkg != null)
>         {
>                 implVersion = pkg.getImplementationVersion();
>         }
>         return Strings.isEmpty(implVersion) ? "n/a" : implVersion;
> }
>
> /Gwyn
>
> On 31/03/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> > This will not work in unit tests, as there is no META-INF/manifest
> > available. That would mean removing the unit test altogether.
> >
> > Also, I just read on the dev list that class.forName() is frowned upon,
> > because of classloader issues.
> >
> > Martijn
> >
> >
> > On 3/31/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> > > Maven already does that (take a bow, Martijn) so this seems to be a
> > > no-cost change.
> > >
> > > The current manifest contains the following...
> > >
> > > Manifest-Version: 1.0
> > > Archiver-Version: Plexus Archiver
> > > Created-By: Apache Maven
> > > Built-By: gwyeva1
> > > Build-Jdk: 1.4.2_09
> > > Extension-Name: wicket
> > > Specification-Title: Wicket is a Java web application framework that t
> > > akes simplicity, separation of concerns and ease of development to a
> > > whole new level. Wicket pages can be mocked up, previewed and later r
> > > evised using standard WYSIWYG HTML design tools. Dynamic content proc
> > > essing and form handling is all handled in Java code using a first-cl
> > > ass component model backed by POJO data beans that can easily be pers
> > > isted using your favourite technology.
> > > Specification-Vendor: Wicket developers
> > > Implementation-Vendor: Wicket developers
> > > Implementation-Title: wicket
> > > Implementation-Version: 1.2-SNAPSHOT
> > >
> > > and a quick/trivial test using
> > >
> > > public String getVersion()
> > > {
> > >         String implVersion = null;
> > >         try
> > >         {
> > >                 Class cls = Class.forName ("wicket.Application");
> > >                 Package pkg = cls.getPackage();
> > >                 if (pkg != null)
> > >                 {
> > >                         implVersion =
> > pkg.getImplementationVersion();
> > >                 }
> > >         }
> > >         catch (ClassNotFoundException e)
> > >         {
> > >                 // ignore the exception
> > >         }
> > >         return Strings.isEmpty(implVersion) ? "n/a" : implVersion;
> > > }
> > >
> > > seemed to work as expected.  Want me to commit the change, although it
> > > might mean that the ApplicationSettingsTest also needs tweaking.
> > >
> > > /Gwyn
> > >
> > > On 31/03/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > > > that we also goed do but who is generating that manifest.mf?
> > > > And we are then depending on that a Package is made. And according to
> > the
> > > > spec a Package object doesn't have to be made.
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > >  On 3/31/06, shumbola < [EMAIL PROTECTED]> wrote:
> > > > > Здравствуйте, Gwyn.
> > > > >
> > > > > Вы писали 31 марта 2006 г., 3:57:26:
> > > > >
> > > > > > I thought we were going to be reading this from the MANIFEST.MF in
> > the
> > > > > > wicket jar?
> > > > >
> > > > > > /Gwyn
> > > > >
> > > > > A while back I provided an example how one can read version and other
> > > > > information from jar file's manifest.
> > > > > IMHO, the version information should be taken from jar file this way,
> > > > > and maven puts apropriate version info from pom.xml into manifest
> > > > > file.
> > > > >
> > > > > Here goes that example again:
> > > > >
> > > > >      Class cls = Class.forName("wicket.Application");
> > > > >      Package pkg = cls.getPackage();
> > > > >
> > > > >      String name = pkg.getName();
> > > > >
> > > > >      String implTitle   = pkg.getImplementationTitle();
> > > > >      String implVendor  = pkg.getImplementationVendor();
> > > > >      String implVersion = pkg.getImplementationVersion();
> > > > >
> > > > > What is wrong with this aproach if any?
> > > > >
> > > > > > On 30/03/06, cowwoc <[EMAIL PROTECTED] > wrote:
> > > > > >>
> > > > > >>         If it is internal, why read it from a property file at all?
> > Why
> > > > isn't
> > > > > >> this hard-coded into the code?
> > > > > >>
> > > > > >> Gili
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > shumbola                          mailto:
> > > > [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > > > >
> > -------------------------------------------------------
> > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > > language
> > > > > that extends applications into web and mobile media. Attend the live
> > > > webcast
> > > > > and join the prime developer group breaking into this new coding
> > > > territory!
> > > > >
> > > >
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > > > > _______________________________________________
> > > > > Wicket-user mailing list
> > > > > Wicket-user@lists.sourceforge.net
> > > > >
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Wicket 1.2 is coming! Write Ajax applications without touching JavaScript!
> >  -- http://wicketframework.org
>

Reply via email to