ext-scripting latest commits

[Werner Punz <we...@gmail.com>]

Hello Jan I noticed you checked in your windows path regarding the ext 
scripting scripts in the web.xml.

I know I am at fault here as well having checked in my own path before, 
due to having been the only person working on it.
Anyway, I would recommend to neutralize this problem by simply
doing a commenting on the scripting path parameters before checkin, so 
that the relative default paths are picked up instead.

I will try to keep this in mind in the future and I would advice not to 
check any local paths into the svn server so that others wont get 
startup problems!

Werner

Re: ext-scripting latest commits

[Werner Punz <we...@gmail.com>]

Werner Punz schrieb:
> Jan-Kees van Andel schrieb:
>> Hey,
>>
>> I also commented it in the issue. I don't really know the exact
>> purpose of the paths, but I think another solution is more
>> appropriate, since the web.xml is in the WAR, making an application
>> less portable.
>>
>> If they are optional, removing them seems appropriate.
>>
> for the 1.2 example I put a comment around it. if the parameters are 
> left out the appropriate deployment dirs are picked up as defaults
> webapps/example/WEB-INF/java or webapps/example/WEB-INF/groovy
> 
> the parameters are just a convenience so that you can edit directly in 
> your favorite ide without having to fiddle around with symlinks etc...
> 
> 
Ok finally I was able to spend a full day on the project lots of stuff 
has been done!


I am committing basic groovy annotation support as we speak, I noticed 
however something, the dataList/uiRepeat fail in the current myfaces 
builds, the data is there, but the variable is not filled!

I assume this is a bug in the current myfaces snapshots, because the 
example works and the data is added as well as the list is iterated!

Btw. you can now move annotations from one class to the other also in 
Groovy not only in java!
And all jsf 2 annotations now should work in Groovy as well

I have tested this successfully with the ManagedBeans, it should work on 
the other artefacts as well (I will give this part additional testing on 
friday)


add to that that the qdox dependency from the core code is gone now as 
well as the asm dependency, no more class rewriting and source scanning.
The annotation scans are now binary only! (Note 1-2 bugs might still be 
in since the code change in that part was severe, but nevertheless give 
it a try!)

The NPEs Jan has reported are removed. Btw. thanks Jan for fixing the 
Windows path issues for me! I simply did not have time to setup a 
Windows testing environment to nail the bugs myself!

Now what is left? Bernhard wants to merge his code into the codebase, we 
might get a better class loader bean reloading mechanism that way, he 
has started to work on it.

We still have some concurrency issues in our code which will be resolved 
over time, I am waiting for Bernhard here to finish his merge to tackle 
that area further.
And of course bugfixing and documentation


Other than that I am functionalitywise in my parts mostly done!

On Bernhards side, he wants to add the Spring java reloading stuff to 
the project as well, I guess this is ok for a 1.0.


Werner

Re: ext-scripting latest commits

[Werner Punz <we...@gmail.com>]

Jan-Kees van Andel schrieb:
> Hey,
> 
> I also commented it in the issue. I don't really know the exact
> purpose of the paths, but I think another solution is more
> appropriate, since the web.xml is in the WAR, making an application
> less portable.
> 
> If they are optional, removing them seems appropriate.
> 
for the 1.2 example I put a comment around it. if the parameters are 
left out the appropriate deployment dirs are picked up as defaults
webapps/example/WEB-INF/java or webapps/example/WEB-INF/groovy

the parameters are just a convenience so that you can edit directly in 
your favorite ide without having to fiddle around with symlinks etc...

Re: ext-scripting latest commits

[Jan-Kees van Andel <ja...@gmail.com>]

Hey,

I also commented it in the issue. I don't really know the exact
purpose of the paths, but I think another solution is more
appropriate, since the web.xml is in the WAR, making an application
less portable.

If they are optional, removing them seems appropriate.

/JK


2009/12/16 Werner Punz <we...@gmail.com>:
> Hello Jan I noticed you checked in your windows path regarding the ext
> scripting scripts in the web.xml.
>
> I know I am at fault here as well having checked in my own path before, due
> to having been the only person working on it.
> Anyway, I would recommend to neutralize this problem by simply
> doing a commenting on the scripting path parameters before checkin, so that
> the relative default paths are picked up instead.
>
> I will try to keep this in mind in the future and I would advice not to
> check any local paths into the svn server so that others wont get startup
> problems!
>
> Werner
>
>