Reinhard Poetz pisze:
Technologies for RIA that run within browsers have been around for years
- do you remember, there was something called Java applets long time
ago ;-) - but I think that none of them will become the dominator for
public internet applications because nobody wants to rely on
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Technologies for RIA that run within browsers have been around for years
- do you remember, there was something called Java applets long time
ago ;-) - but I think that none of them will become the dominator for
public internet applications
On 8/30/07, Leszek Gawron [EMAIL PROTECTED] wrote:
Client side javascript has exactly the same problem our flowscript has:
snip/
- debug tools are: print( here I am ) and nothing more (apart from
GWT which uses 'advanced magic').
Not quite: Firebug for FireFox is wonderful for debugging
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=3069projectId=51
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 30 Aug 2007 13:02:18 -0700
Finished at: Thu 30 Aug 2007 13:03:53 -0700
Total time: 1m 35s
Build Trigger: Schedule
Build
[EMAIL PROTECTED] pisze:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) javax.jms:jms:jar:1.1
Grzegorz Kossakowski wrote:
Path to dependency: 1)
org.apache.cocoon:cocoon-spring-configurator:jar:1.0.1-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) javax.jms:jms:jar:1.1
Does anyone know why log4j has this dependencies introduced in minor version
increase?
a quick guess: they
Reinhard Poetz pisze:
Since this dependencies are not on central repository, shouldn't they
be defined as provided, or so?
definitly, but it shouldn't be us to fix this in our pom. It's still a
PITA thatdependencies are not checked if they really exist when
things are deployed to the
Grzegorz Kossakowski pisze:
Hello,
This is a second attempt to resolve problem with inaccurate version
information in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had several drawbacks like
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had
Unfortunately, that is not true of all environments. Many large
organizations such as governments and big corporations will not allow
their users to install ANY plugins to their browsers for security
reasons. A team of testers has to examine every piece of software
installed on the network and
On 30.08.2007 18:57 Uhr, Joerg Heinicke wrote:
EncodeUrlTransformer [1]
[1] http://cocoon.apache.org/2.1/userdocs/encodeurl-transformer.html
When searching for the exact name I tried to use our API, but the
EncodeUrlTransformer is not included. Any idea why?
Joerg
Leszek Gawron pisze:
Ajax is not the Ferrari either. I started to dislike cForms when dojo
was introduced as main ajax engine. The simplest page with cForm takes
300ms more to render than before. Awful...
As for the tools: there are no ajax tools available either. A JS syntax
enabled editor
I assume you mean in the javadoc? My guess is because it doesn't exist
in the normal place. If you'll notice there is a jdk1.3 and jdk1.4
directory under src. There is an EncodeURLTransformer in each of them.
Which one gets compiled depends on the version of the compiler you are
using. The
Ah, that's why. Thanks for the info!
Joerg
On 30.08.2007 21:13 Uhr, Ralph Goers wrote:
I assume you mean in the javadoc? My guess is because it doesn't exist
in the normal place. If you'll notice there is a jdk1.3 and jdk1.4
directory under src. There is an EncodeURLTransformer in each of
14 matches
Mail list logo
