Other than the ApplicationSettingsTest.testFrameworkVersion test that does
assertFalse("n/a".equalsIgnoreCase(settings.getVersion()));
they seem unaffected.
/Gwyn
On 13/04/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> Most users, probably except the core developers and a few other users,
Most users, probably except the core developers and a few other users,
are using wicket.jar. Replying "n/a" if not using the jar is ok for
me. And as long as unit tests don't suffer, and I think they don't,
than
+1 for MANIFEST.MF
Juergen
On 4/13/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
> Anyon
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
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
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.
MartijnOn 3/31/06, Gwyn Evans <[EMAIL PROTECTED]> wrote:
Maven alrea
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: Wic
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 though
Çäðàâñòâóéòå, 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 shoul
Çäðàâñòâóéòå, 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 shoul
Çäðàâñòâóéòå, 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 shoul
+1
Gili
Gwyn Evans wrote:
> I thought we were going to be reading this from the MANIFEST.MF in the
> wicket jar?
>
> /Gwyn
>
> 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 cod
I thought we were going to be reading this from the MANIFEST.MF in the
wicket jar?
/Gwyn
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
---
(Probably?) because that way we can copy the version info from the
maven definition file and thus do not do things double.
Eelco
On 3/30/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?
>
> Gil
yeah if we ask getResource("wicket/Application.properties") that should be enough. the main thing to keep in mind is we have toeither ask for a properties file that is in our package or we have to use unique if it is on the classpath.
or what we can do is make maven filter the version numbers into
If it is internal, why read it from a property file at all? Why isn't
this hard-coded into the code?
Gili
Igor Vaynberg wrote:
> i dont see a problem with having a wicket-internal.properties. this can
> be used for all the internal things we use, version now, and maybe some
> other stuff
i dont see a problem with having a wicket-internal.properties. this can be used for all the internal things we use, version now, and maybe some other stuff. this will only be used by wicket so we can be guaranteed no collissions. lets keep
wicket.properties for more general things.-IgorOn 3/30/06,
We ask for all the wicket properties file there are. And execute there initilalizer what is specificed in all of themBut are you really wanting to walk over every possible file and then look when you encounter the one that suddenly
has wicket.version it it??Then we really should change the method t
So how do we process the wicket.properties files for getting the initializers?That does work for the initializers for all the new jar file, why not for wicket.version?Martijn
On 3/30/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
yes exactly like igors says,.Because we are looking up for a wicket p
No not application properties.That one is kind of reserved if it was me.Because that is the name of the properties file that i want to have for all the default messges (in english)I hope that we can also give that in
1.2 So that as last the wicket.Application.properties is loaded to lookup for mes
yes exactly like igors says,.Because we are looking up for a wicket properties file (and only one) which one does it return?? It could be the one from the extentionsor the one users do provide. We don't have control of that.
We need one single unique properties file for that. Else we can't load it
What about Application.properties as the internal one. It is (should)
already be search for.
Juergen
On 3/30/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> but the problem with wicket.properties is that it is also used by our users!
> what we need is a unique property file that our users wont hav
but the problem with wicket.properties is that it is also used by our users! what we need is a unique property file that our users wont have in their classpath - so that we can be sure we are reading the proper one.
call it wicket-internal.properties or some such.-IgorOn 3/30/06, Martijn Dashorst <
So you propose that for every property we want to put into Wicket we should add a new property file? wicket.properties is already there. Why introduce another file?MartijnOn 3/30/06,
Johan Compagner <[EMAIL PROTECTED]> wrote:
yes i think i already did mention that beforeit should be looking for an
yes i think i already did mention that beforeit should be looking for an unique text file. like wicket-version.properties.Can maven generate that file martijn? So that we look for this?johan
On 3/30/06, jan_bar <[EMAIL PROTECTED]> wrote:
Hi,I tried FrameworkSettings.getVersion(), but it seems to re
Hi,
I tried FrameworkSettings.getVersion(), but it seems to read
wicket.properties of my application instead from wicketXX.jar. Does it work
for you?
Thanks, Jan
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting languag
25 matches
Mail list logo
