Re: New date parser in javascript

[Arvid Hülsebus]

We need to replace some JavaScript code in Tobago, which has basically 
the same functionality like the new date.js stuff. I started to work on 
this, too. Perhaps we should join forces. But I definitely don't have as 
much time as Martin -- working on this the whole night...


I pulled together some ends from a nearly abandoned web test tool of 
ours and started to write a JavaScriptTestCase. Now seeing that Martin's 
date parsing and formatting code is far more advanced than my stuff I 
came up with yesterday, I thought my unit testing stuff could be somehow 
useful for you, too. It just some very basic code using Mozilla's Rhino. 
But this way it's easier to test the JavaScript code from your Java IDE 
and at least for Tobago I need to be pretty close to the Java 
implementation of SimpleDateFormat. This way the two implementations can 
be compared pretty easily.


I spotted some problems regarding formats including "MMM" and "". 
But I didn't have the time to look into the JavaScript implementation up 
to now. I hope I can do this, when I got home and something to eat.


I will need a more sophisticated approach for localization, too ;-) I 
will provide some suggestions to this later...


Regards,
Arvid

Martin Marinschek wrote:


Hi *,

I have added the first draft of a javascript date parser - it would be
great if you could check it out, add functionality as needed (should
be pretty straightforward) and (of course) use it!

regards,

Martin
 

import org.mozilla.javascript.JavaScriptException;

import java.io.FileReader;
import java.io.IOException;
import java.text.SimpleDateFormat;
import java.util.Date;

public class DateConverterTest extends JavaScriptTestCase {

  public void testCalendar() throws IOException, JavaScriptException {
loadScriptFile("js/dateConverter.js");

String format = "MMdd";
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(format);
assertEquals(simpleDateFormat.format(new Date()), eval("formatDate(new 
Date(), \"" + format + "\")"));
  }

}
import junit.framework.TestCase;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.Scriptable;
import org.mozilla.javascript.JavaScriptException;

import java.io.IOException;
import java.io.FileReader;

public class JavaScriptTestCase extends TestCase {

  protected Context cx;
  protected Scriptable scope;

  protected void setUp() throws Exception {
super.setUp();
cx = Context.enter();
scope = cx.initStandardObjects(null);
  }

  protected void tearDown() throws Exception {
Context.exit();
  }

  protected Object eval(String script) throws JavaScriptException {
return cx.evaluateString(scope, script, "test", 1, null);
  }

  protected int evalInt(String script) throws JavaScriptException {
Object o = eval(script);
if (o instanceof Number) {
  return ((Number) o).intValue();
}
throw new JavaScriptException(null, "invalid return type "
+ o.getClass().getName() + " with value " + o, 0);
  }

  protected boolean evalBoolean(String script) throws JavaScriptException {
Object o = eval(script);
if (o instanceof Boolean) {
  return ((Boolean) o).booleanValue();
}
throw new JavaScriptException(null, "invalid return type "
+ o.getClass().getName() + " with value " + o, 0);
  }

  // XXX directory handling
  protected void loadScriptFile(String jsFile)
  throws IOException, JavaScriptException {
cx.evaluateReader(scope, new FileReader(jsFile), jsFile, 0, null);
  }
}
var Class = {
  create: function() {
return function() {
  this.initialize.apply(this, arguments);
}
  }
}

Re: New date parser in javascript

[Arvid Hülsebus]

Dang... sent the wrong unit test. This was were I started to test the 
script, which we are currently using in Tobago. My test for


https://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/src/java/org/apache/myfaces/custom/calendar/resource/date.js

looks something like the attached file.

Regards,
Arvid
import org.mozilla.javascript.JavaScriptException;

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
import java.io.IOException;

public class DateTest extends JavaScriptTestCase {

  public void testDateScript() throws IOException, JavaScriptException {
// loadScriptFile("debug.js");
loadScriptFile("prototype-basics.js");
loadScriptFile("date.js");

String format = "MMdd";
SimpleDateFormat simpleDateFormat = new SimpleDateFormat(format, 
Locale.ENGLISH);
assertEquals(simpleDateFormat.format(new Date()), evalDate(format));

format = "";
simpleDateFormat = new SimpleDateFormat(format, Locale.ENGLISH);
System.out.println(simpleDateFormat.format(new Date()));
assertEquals(simpleDateFormat.format(new Date()), evalDate(format));

format = "MMMdd";
simpleDateFormat = new SimpleDateFormat(format, Locale.ENGLISH);
System.out.println(simpleDateFormat.format(new Date()));
assertEquals(simpleDateFormat.format(new Date()), evalDate(format));
  }

  private Object evalDate(String format) {
return eval("new SimpleDateFormat(\"" + format + "\").format(new Date())");
  }
}

Re: New date parser in javascript

[Arvid Hülsebus]

I started to look into the formatting of MMM, , EEE, and ... 
just a start. Hope it helps.


Regards,
Arvid
/*
 * Copyright 2004 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

var DateFormatSymbols = Class.create();
DateFormatSymbols.prototype = {
initialize: function()
{
this.eras = new Array('BC', 'AD');
this.months = new Array('January', 'February', 'March', 'April',
'May', 'June', 'July', 'August', 'September', 'October',
'November', 'December', 'Undecimber');
this.shortMonths = new Array('Jan', 'Feb', 'Mar', 'Apr',
'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct',
'Nov', 'Dec', 'Und');
this.weekdays = new Array('Sunday', 'Monday', 'Tuesday',
'Wednesday', 'Thursday', 'Friday', 'Saturday');
this.shortWeekdays = new Array('Sun', 'Mon', 'Tue',
'Wed', 'Thu', 'Fri', 'Sat');
this.ampms = new Array('AM', 'PM');
this.zoneStrings = new Array(new Array(0, 'long-name', 'short-name'));
},
}

var SimpleDateFormatParserContext = Class.create();
SimpleDateFormatParserContext.prototype = {
initialize: function()
{
this.newIndex=0;
this.retValue=0;
this.year=0;
this.month=0;
this.day=0;
this.dayOfWeek=0;
this.hour=0;
this.min=0;
this.sec=0;
this.ampm=0;
this.dateStr="";
},
}

var SimpleDateFormat = Class.create();
SimpleDateFormat.prototype = {
initialize: function(pattern, dateFormatSymbols)
{
this.pattern = pattern;
this.dateFormatSymbols = dateFormatSymbols ? dateFormatSymbols : new 
DateFormatSymbols();
},


_handle: function(dateStr, date, parse)
{
var patternIndex = 0;
var dateIndex = 0;
var commentMode = false;
var lastChar = 0;
var currentChar=0;
var nextChar=0;
var patternSub = null;

var context = new SimpleDateFormatParserContext();

if(date != null)
{
var yearStr = date.getYear()+"";

if (yearStr.length < 4)
{
  yearStr=(parseInt(yearStr, 10)+1900)+"";
}

context.year = parseInt(yearStr, 10);
context.month = date.getMonth();
context.day = date.getDate();
context.dayOfWeek = date.getDay();
context.hour = date.getHours();
context.min = date.getMinutes();
context.sec = date.getSeconds();
}

while (patternIndex < this.pattern.length)
{
currentChar = this.pattern.charAt(patternIndex);

if(patternIndex<(this.pattern.length-1))
{
nextChar = this.pattern.charAt(patternIndex+1);
}
else
{
nextChar = 0;
}


if (currentChar == '\'' && lastChar!='\\')
{
commentMode = !commentMode;
patternIndex++;
}
else
{
if(!commentMode)
{
if (currentChar == '\\' && lastChar!='\\')
{
patternIndex++;
}
else
{
if(patternSub == null)
patternSub = "";

patternSub+=currentChar;

if(currentChar != nextChar)
{
this._handlePatternSub(context, patternSub,
dateStr, dateIndex, parse);

patternSub = null;

if(context.newIndex<0)
break;

dateIndex = context.newIndex;
}

patternIndex++;
}
}
else
{
if(parse)
{

if(this.pattern.charAt(patternIndex)!=dateStr.charAt(dateIndex))
{
//invalid character in dateString
return null;
}
}
else
{
context.dateStr+=this

Re: New date parser in javascript

[Arvid Hülsebus]

Looks like I'm ending up spending as much time on date parsing as Martin...

Parsing of MMM and  starts to work now, too. Additionally I looked 
into parsing and formatting of yy vs. .


Regards,
Arvid
/*
 * Copyright 2004 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

var DateFormatSymbols = Class.create();
DateFormatSymbols.prototype = {
initialize: function()
{
this.eras = new Array('BC', 'AD');
this.months = new Array('January', 'February', 'March', 'April',
'May', 'June', 'July', 'August', 'September', 'October',
'November', 'December', 'Undecimber');
this.shortMonths = new Array('Jan', 'Feb', 'Mar', 'Apr',
'May', 'Jun', 'Jul', 'Aug', 'Sep', 'Oct',
'Nov', 'Dec', 'Und');
this.weekdays = new Array('Sunday', 'Monday', 'Tuesday',
'Wednesday', 'Thursday', 'Friday', 'Saturday');
this.shortWeekdays = new Array('Sun', 'Mon', 'Tue',
'Wed', 'Thu', 'Fri', 'Sat');
this.ampms = new Array('AM', 'PM');
this.zoneStrings = new Array(new Array(0, 'long-name', 'short-name'));
},
}

var SimpleDateFormatParserContext = Class.create();
SimpleDateFormatParserContext.prototype = {
initialize: function()
{
this.newIndex=0;
this.retValue=0;
this.year=0;
this.month=0;
this.day=0;
this.dayOfWeek=0;
this.hour=0;
this.min=0;
this.sec=0;
this.ampm=0;
this.dateStr="";
},
}

var SimpleDateFormat = Class.create();
SimpleDateFormat.prototype = {
initialize: function(pattern, dateFormatSymbols)
{
this.pattern = pattern;
this.dateFormatSymbols = dateFormatSymbols ? dateFormatSymbols : new 
DateFormatSymbols();
},


_handle: function(dateStr, date, parse)
{
var patternIndex = 0;
var dateIndex = 0;
var commentMode = false;
var lastChar = 0;
var currentChar=0;
var nextChar=0;
var patternSub = null;

var context = new SimpleDateFormatParserContext();

if(date != null)
{
var yearStr = date.getYear()+"";

if (yearStr.length < 4)
{
  yearStr=(parseInt(yearStr, 10)+1900)+"";
}

context.year = parseInt(yearStr, 10);
context.month = date.getMonth();
context.day = date.getDate();
context.dayOfWeek = date.getDay();
context.hour = date.getHours();
context.min = date.getMinutes();
context.sec = date.getSeconds();
}

while (patternIndex < this.pattern.length)
{
currentChar = this.pattern.charAt(patternIndex);

if(patternIndex<(this.pattern.length-1))
{
nextChar = this.pattern.charAt(patternIndex+1);
}
else
{
nextChar = 0;
}


if (currentChar == '\'' && lastChar!='\\')
{
commentMode = !commentMode;
patternIndex++;
}
else
{
if(!commentMode)
{
if (currentChar == '\\' && lastChar!='\\')
{
patternIndex++;
}
else
{
if(patternSub == null)
patternSub = "";

patternSub+=currentChar;

if(currentChar != nextChar)
{
this._handlePatternSub(context, patternSub,
dateStr, dateIndex, parse);

patternSub = null;

if(context.newIndex<0)
break;

dateIndex = context.newIndex;
}

patternIndex++;
}
}
else
{
if(parse)
{

if(this.pattern.charAt(patternIndex)!=dateStr.charAt(dateIndex))
{
//invalid character in dateString
return null;
}
   

Re: [VOTE] Release Tobago 1.0.13

[Arvid Hülsebus]

+1

I tested 2 of my small apps... everything looks fine.

Regards,
Arvid

Udo Schnurpfeil wrote:

+1

Gegards

Udo

Martin Marinschek schrieb:

+1

regards,

Martin

On Dec 13, 2007 9:19 AM, Volker Weber <[EMAIL PROTECTED]> wrote:
 

Hi,

+1


Regards,
Volker

2007/12/12, Grant Smith <[EMAIL PROTECTED]>:

   

+1


On 12/11/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
 

Hello,

I would like to release Tobago 1.0.13,

This release contains 30 changes.
For a detail list please consult the release notes:



http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312766 

 

The version is available at the staging location and the
revision number of the release is 603390 and tagged as tobago-1.0.13.

Staging distribution:

http://people.apache.org/~bommel/repo/

Staging repository:

http://people.apache.org/~bommel/repo/

Regards

Bernd


The Vote is open for 72h.

[ ] +1
[ ] +0
[ ] -1




--
Grant Smith

  




  

[Tobago] Introduction of Dojo

[Arvid Hülsebus]

Hello,

Do we really need all the Dojo sources in the standard theme? The jar is 
now a whopping 4717 kb.


We even package the Dojo unit tests. Now you can run them from your 
favorite Tobago app -- like in the address book:


http://localhost:8080/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/dojo/dojo/tests/runTests.html

Do we need much more than dojo.js and stuff below resources?

Thanks in advance,
Arvid

Re: [Tobago] Rewriting Components for disabling JavaScript

[Arvid Hülsebus]

Hello!

Here some rather unsorted stuff which comes to my mind...

It should be possible, but not very easy... there are even some basic 
features in HTML which don't really work without JavaScript. The IE 6 
submits all submit buttons with the inner HTML as value instead of just 
the active button (the one which was clicked) with the value attribute 
as value. But you can use input fields of type submit instead with the 
limitations for styling the label (like drawing an underscore below the 
access key.)


And a lot of Tobago features of Speyside -- for example Ajax related 
things -- wouldn't be possible anymore. Doing stuff like menus without 
JavaScript will be pretty hard, too.


At the very beginning the Scarborough theme was meant to be an HTML only 
theme. But that changed pretty soon. Perhaps for an accessible theme a 
theme without JavaScript would be nice basis to build upon.


Regards
Arvid

Re: [VOTE] Release Tobago 1.0.15

[Arvid Hülsebus]

+1

I don't mind releasing the sandbox. It is called 'sandbox' so nobody 
will expect something stable.


BTW, I don't think we can introduce the sandbox tree in a 1.0.x release 
as a replacement of the current tree, since there are API changes AFAIK, 
which is not feasible for a micro release.


Regards,
Arvid

Re: Author tags in source files

[Arvid Hülsebus]

And there is always the possibility to run "svn blame" to retrieve more 
concrete information.


Regards,
Arvid

Re: [VOTE] Release Tobago 1.0.17

[Arvid Hülsebus]

+1

Regards
Arvid

Bernd Bohmann wrote:

Hello,

I would like to release Tobago 1.0.17,

For a detail list please consult the release notes:

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12313084

The version is available at the staging location and the
revision number of the release is 656789 and tagged as tobago-1.0.17.

Staging distribution:

http://people.apache.org/~bommel/repo

Staging repository:

http://people.apache.org/~bommel/repo


The Vote is open for 72h.

[ ] +1
[ ] +0
[ ] -1


  

Re: [VOTE] Release Tobago 1.0.10

[Arvid Hülsebus]

+1

Best regards,
Arvid

Volker Weber wrote:

Hi,

+1

Regards,
 Volker

2007/3/8, Bernd Bohmann <[EMAIL PROTECTED]>:

Hello,

I would like to release Tobago 1.0.10,

This release contains over 80 changes.
For a detail list please consult the release notes:

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312204 



The version is available at the staging location and the revision number
of the release is 515806 and tagged as tobago-1.0.10.

Staging distribution:

http://people.apache.org/~bommel

Staging repository:

http://people.apache.org/~bommel/repo


The Vote is open for 72h.

[ ] +1
[ ] +0
[ ] -1

Regards

Bernd

Re: [TOBAGO] addressbook demo crashes on phone number validation

[Arvid Hülsebus]

Hello Mike,

We are currently in the process to overhaul the address book demo. We 
merged it with an older variant based on Faclets and added a DB back-end 
instead of the former file based implementation. I still have a list of 
about 20 issues we still have to fix.


But I didn't notice the missing resource up to now. This should be fixed 
now. Although the validator is very simplistic and the error message is 
pretty cryptic. You have to enter something like "+111 111 ".


Thanks and best regards,
Arvid

Mike Kienenberger wrote:

Just going through the Tobago addressbook demo.

Grabbed it from svn, and then ran this command:

C:\workspaces\myfaces\addressbook-1.0.10>mvn jetty:run-exploded

I created a new address, and put in a phone number in this format
111-111- and I got the following error (which is probably
unrelated to the actual data input).

Looks like the root cause is:

java.util.MissingResourceException: Can't find resource for bundle
java.util.PropertyResourceBundle, key validator_phone

=

HTTP ERROR: 500

Exception while invoking expression #{controller.validatePhoneNumber}

RequestURI=/tobago-example-addressbook/faces/editor.jsp
Caused by:

javax.faces.el.EvaluationException: Exception while invoking
expression #{controller.validatePhoneNumber}
at 
org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:156) 

at 
javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:181) 


at javax.faces.component.UIInput.validateValue(UIInput.java:313)
at javax.faces.component.UIInput.validate(UIInput.java:354)
at javax.faces.component.UIInput.processValidators(UIInput.java:184)
at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
org.apache.myfaces.tobago.component.UITabGroup.processValidators(UITabGroup.java:172) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
org.apache.myfaces.tobago.component.UIForm.processValidators(UIForm.java:71) 

at 
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627) 

at 
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:149)
at 
org.apache.myfaces.tobago.component.UIViewRoot.processValidators(UIViewRoot.java:175) 

at 
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) 

at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) 

at 
org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter.doFilter(TobagoMultipartFormdataFilter.java:130) 

at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) 

at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) 

at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at 
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) 

at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) 

at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) 


at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329) 

at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) 


Caused by: java.util.MissingResourceException: Can't find resource for
bundle java.util.PropertyResourceBundle, key validator_phone
at java.util.ResourceBun

Re: [TOBAGO] addressbook demo crashes on address list header clicks

[Arvid Hülsebus]

I wasn't able to reproduce this problem. Can you try to explain what you 
were doing in more detail?


I run "mvn clean" and started the address book again. Sorting the empty 
address list didn't produce an error. Then I added a simple address 
(first name and last name) and sorting still didn't produce an error. 
After adding a second address the sorting actually caused an visible effect.


Perhaps it's "machine" dependent ;-). On my box storing of an uploaded 
portrait doesn't work, but Bernd doesn't seem to any problems with that.


Thanks in advance,
Arvid

Mike Kienenberger wrote:

Clicking on the last name or first name header gives the following
message.  This is when there is one item in the list.

Server Error: unable to serve request. Probably a session timeout!


Looks like it's caused by this error:

[ERROR] PhaseListenerManager - Exception in PhaseListener
APPLY_REQUEST_VALUES(2) afterPhase
java.lang.UnsupportedOperationException: Result lists are
read-only.
   at 
org.apache.openjpa.lib.rop.AbstractListIterator.set(AbstractListIterator.java:39) 

   at 
org.apache.openjpa.kernel.DelegatingResultList$DelegatingListIterator.set(DelegatingResultList.java:420) 


   at java.util.Collections.sort(Collections.java:163)
   at 
org.apache.myfaces.tobago.component.Sorter.invoke(Sorter.java:127)
   at 
org.apache.myfaces.tobago.component.UIData.invokeMethodBinding(UIData.java:599) 

   at 
org.apache.myfaces.tobago.component.UIData.broadcast(UIData.java:591)


   at 
org.apache.myfaces.tobago.component.UIViewRoot.broadcastForPhase(UIViewRoot.java:128) 

   at 
org.apache.myfaces.tobago.component.UIViewRoot.processApplication(UIViewRoot.java:197) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processActiveAjaxComponent(AjaxUtils.java:137) 

   at 
org.apache.myfaces.tobago.component.UIData.processAjax(UIData.java:661)
   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjax(AjaxUtils.java:107) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjaxOnChildren(AjaxUtils.java:155) 

   at 
org.apache.myfaces.tobago.component.UIPanel.processAjax(UIPanel.java:60)
   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjax(AjaxUtils.java:107) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjaxOnChildren(AjaxUtils.java:155) 

   at 
org.apache.myfaces.tobago.component.UIPanel.processAjax(UIPanel.java:60)
   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjax(AjaxUtils.java:107) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjaxOnChildren(AjaxUtils.java:155) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjax(AjaxUtils.java:109) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjaxOnChildren(AjaxUtils.java:155) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxUtils.processAjax(AjaxUtils.java:109) 

   at 
org.apache.myfaces.tobago.ajax.api.AjaxPhaseListener.afterPhase(AjaxPhaseListener.java:114) 

   at 
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:92) 

   at 
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:99) 

   at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)

   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
   at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)
   at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) 

   at 
org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter.doFilter(TobagoMultipartFormdataFilter.java:130) 

   at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) 

   at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
   at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185) 

   at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
   at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
   at 
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)


   at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146) 

   at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) 

   at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

   at org.mortbay.jetty.Server.handle(Server.java:285)
   at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
   at 
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:765) 


   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
   at 
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)
   at 
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
   at 
org.mortbay.io.nio.S

Restart of Continuum Server

[Arvid Hülsebus]

Hello,

Since the Continuum Server doesn't respond anymore, we are going to 
restart it.


Best Regards,
Bernd and Arvid

[Tobago] Preparing the next release 1.0.11

[Arvid Hülsebus]

Hello,

We are preparing the next release of Tobago. The vote will be started in 
the next days. Please check the issues in JIRA and close the remaining 
bugs or move them to a different release.


If you have a productive Tobago application, please check if it works 
with the current snapshot.


Best regards,
Arvid

Re: [VOTE] Release Tobago 1.0.11

[Arvid Hülsebus]

+1, if the following 2 minor issues are resolved

- Markup "strong" for tc:out doesn't work in Speyside (I will check in 
the necessary change in the trunk; for the release see the attached 
patch file)
- If you switch to the Richmond theme in the address book demo, you will 
get superfluous scroll bars in the address editor. I didn't look into 
this one up to now.


Regards,
Arvid

Matthias Wessendorf wrote:

+1

On 5/20/07, Grant Smith <[EMAIL PROTECTED]> wrote:

+1


On 5/20/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like to release Tobago 1.0.11,
>
> This release contains over 50 changes.
> For a detail list please consult the release notes:
>
>
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312376 


>
> The version is available at the staging location and the revision 
number

> of the release is 539876 and tagged as tobago-1.0.11.
>
> Staging distribution:
>
> http://people.apache.org/~bommel
>
> Staging repository:
>
> http://people.apache.org/~bommel/repo
>
>
> The Vote is open for 72h.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Regards
>
> Bernd
>
>



--
Grant Smith




Index: 
theme/speyside/src/main/resources/org/apache/myfaces/tobago/renderkit/html/speyside/standard/style/style.css
===
--- 
theme/speyside/src/main/resources/org/apache/myfaces/tobago/renderkit/html/speyside/standard/style/style.css
(revision 539937)
+++ 
theme/speyside/src/main/resources/org/apache/myfaces/tobago/renderkit/html/speyside/standard/style/style.css
(working copy)
@@ -483,7 +483,8 @@
 /* text  */
 
 .tobago-out-default  {
-  font: 12px arial, helvetica, sans-serif;
+  font-family: arial, helvetica, sans-serif;
+  font-size: 12px;
 }
 
 /* textArea  */

Re: [VOTE] Release Tobago 1.0.11

[Arvid Hülsebus]

And here is the patch to make the scrollbars go away. I somehow don't 
have the right to commit on the tag folder. Bernd, can you please apply 
the patch? I already checked in the changes on the trunk


Regards,
Arvid

Arvid Hülsebus wrote:

+1, if the following 2 minor issues are resolved

- Markup "strong" for tc:out doesn't work in Speyside (I will check in 
the necessary change in the trunk; for the release see the attached 
patch file)
- If you switch to the Richmond theme in the address book demo, you 
will get superfluous scroll bars in the address editor. I didn't look 
into this one up to now.


Regards,
Arvid

Matthias Wessendorf wrote:

+1

On 5/20/07, Grant Smith <[EMAIL PROTECTED]> wrote:

+1


On 5/20/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like to release Tobago 1.0.11,
>
> This release contains over 50 changes.
> For a detail list please consult the release notes:
>
>
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312376 


>
> The version is available at the staging location and the revision 
number

> of the release is 539876 and tagged as tobago-1.0.11.
>
> Staging distribution:
>
> http://people.apache.org/~bommel
>
> Staging repository:
>
> http://people.apache.org/~bommel/repo
>
>
> The Vote is open for 72h.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Regards
>
> Bernd
>
>



--
Grant Smith




--- example/demo/src/main/webapp/overview/tab.jsp   (revision 539937)
+++ example/demo/src/main/webapp/overview/tab.jsp   Wed May 23 11:35:50 
CEST 2007
@@ -34,102 +34,90 @@
   
 
 
-
+  
   
 
-  
-
-
-
-
-
+  
+  
+  
+  
+  
-  
 
 
-  
-
-
-
-
-
+  
+  
+  
+  
+  
-  
 
 
-  
-
-
-  
-
-  
-  
-
-  
-  
-
-  
-  
-
-  
-
+  
+  
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
-  
 
   
 
 
 
 
-
+  
   
 
 
 
 
-  
-
-
-
-
-
+  
+  
+  
+  
+  
-  
 
 
-  
-
-
-
-
-
+  
+  
+  
+  
+  
-  
 
 
-  
-
-
-  
-
-  
-  
-
-  
-  
-
-  
-  
-
-  
-
+  
+  
+
+  
+
+
+  
+
+
+  
+
+
+  
+
+  
-  
 
   
 
--- 
theme/richmond/src/main/resources/org/apache/myfaces/tobago/renderkit/html/richmond/standard/property/tobago-theme-config.properties
(revision 539937)
+++ 
theme/richmond/src/main/resources/org/apache/myfaces/tobago/renderkit/html/richmond/standard/property/tobago-theme-config.properties
Wed May 23 11:26:32 CEST 2007
@@ -17,6 +17,6 @@
 
 
 # padding-top + padding-bottom + border-top + border-bottom
-TabGroup.paddingHeight=27
+TabGroup.paddingHeight=28
 # padding-left + padding-right + border-left + border-right
 TabGroup.paddingWidth=25

Re: [VOTE] Release Tobago 1.0.11

[Arvid Hülsebus]

Perhaps there is some special handling for the tag folder? Or the way 
how the Maven release plugin created the folder. Normally one wouldn't 
want to check-in in the tag folder. I still get:


Error: MKACTIVITY of 
'/repos/asf/!svn/act/0dfb3f90-8cee-3146-888d-c31017d0d682': 403 
Forbidden (http://svn.apache.org) 


Bernd can check in... strange.

Regards,
Arvid

Manfred Geiler wrote:

Arvid,
I just checked your svn permissions.
You SHOULD be able to commit with your username "idus".
Please try again.

--Manfred


On 5/23/07, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:

And here is the patch to make the scrollbars go away. I somehow don't
have the right to commit on the tag folder. Bernd, can you please apply
the patch? I already checked in the changes on the trunk

Regards,
Arvid

Arvid Hülsebus wrote:
> +1, if the following 2 minor issues are resolved
>
> - Markup "strong" for tc:out doesn't work in Speyside (I will check in
> the necessary change in the trunk; for the release see the attached
> patch file)
> - If you switch to the Richmond theme in the address book demo, you
> will get superfluous scroll bars in the address editor. I didn't look
> into this one up to now.
>
> Regards,
> Arvid
>
> Matthias Wessendorf wrote:
>> +1
>>
>> On 5/20/07, Grant Smith <[EMAIL PROTECTED]> wrote:
>>> +1
>>>
>>>
>>> On 5/20/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>> > Hello,
>>> >
>>> > I would like to release Tobago 1.0.11,
>>> >
>>> > This release contains over 50 changes.
>>> > For a detail list please consult the release notes:
>>> >
>>> >
>>> 
http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312376 


>>>
>>> >
>>> > The version is available at the staging location and the revision
>>> number
>>> > of the release is 539876 and tagged as tobago-1.0.11.
>>> >
>>> > Staging distribution:
>>> >
>>> > http://people.apache.org/~bommel
>>> >
>>> > Staging repository:
>>> >
>>> > http://people.apache.org/~bommel/repo
>>> >
>>> >
>>> > The Vote is open for 72h.
>>> >
>>> > [ ] +1
>>> > [ ] +0
>>> > [ ] -1
>>> >
>>> > Regards
>>> >
>>> > Bernd
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Grant Smith
>>>
>>
>>

--- example/demo/src/main/webapp/overview/tab.jsp   (revision 
539937)
+++ example/demo/src/main/webapp/overview/tab.jsp   Wed May 23 
11:35:50 CEST 2007

@@ -34,102 +34,90 @@
   

 
-
+  
   state="#{demo.tabState1}" >

 
-  
-rows="1*;fixed;fixed;1*" />

-
-
-
-
+  rows="1*;fixed;fixed;1*" />

+  
+  
+  
+  
-  
 
 
-  
-rows="1*;fixed;fixed;1*" />

-
-
-value="#{demo.solar.planets[0].timeOfCirculation}"
-   
label="#{overviewBundle.solarPlanetTimeOfCirculation}" />

-
+  rows="1*;fixed;fixed;1*" />

+  
+  
+  + 
label="#{overviewBundle.solarPlanetTimeOfCirculation}" />

+  
-  
 
 
-  
-
-
-  label="#{overviewBundle.solarArrayName}" id="name" sortable="true">

-
-  
-  label="#{overviewBundle.solarArrayNumber}" id="number" 
sortable="false" align="center" >

-
-  
-  label="#{overviewBundle.solarArrayDistance}" sortable="true" 
align="right" >

-
-  
-  label="#{overviewBundle.solarArrayPeriod}" sortable="true" 
align="right" >

-
-  
-
+  
+  
+id="name" sortable="true">

+   

Re: SVN / ISSUES

[Arvid Hülsebus]

Where do you want the link? Do you think about something like Tortoise 
SVN handles it, when viewing the commit comment?


http://tortoisesvn.tigris.org/issuetrackers.html
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html

Regards,
Arvid

Matthias Wessendorf wrote:

Hi,

when committing, 99% we are using the proper Jira issue, like TRINIDAD-XY

is it possible to generate a link to the particular jira issue ?

would be very convenient, IMO

-Matthias

Re: SVN / ISSUES

[Arvid Hülsebus]

Like a post-commit hook, which replaces \b[A-Z]+-\d+\b with the link to 
the bug in the commit message. You cold write something like that 
yourself ;-) But I'm not sure, if we can install such a hook on our SVN 
server.


Like I said, Tortoise SVN does this on the client side. Perhaps plugins 
like IDEA Jira Browser and Eclipse Mylyn can do this too...


Regards,
Arvid

Matthias Wessendorf wrote:

I want the link to Jira, generated, when somebody does

MYFACES-12345 bla bla bla

that in the svn messages it is

http://issues.../MYFACES-12345

Greetings

On 6/27/07, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:

Where do you want the link? Do you think about something like Tortoise
SVN handles it, when viewing the commit comment?

http://tortoisesvn.tigris.org/issuetrackers.html
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html 



Regards,
Arvid

Matthias Wessendorf wrote:
> Hi,
>
> when committing, 99% we are using the proper Jira issue, like 
TRINIDAD-XY

>
> is it possible to generate a link to the particular jira issue ?
>
> would be very convenient, IMO
>
> -Matthias
>

Re: [VOTE] Release Tobago 1.0.12

[Arvid Hülsebus]

I found a small issue with date popups in IE6, which can be observed in 
the basic controls page by opening the date popup.


+1, if my patch is backported to the release candidate -- see TOBAGO-517

Regards,
Arvid

Udo Schnurpfeil wrote:
I've updated http://tobago.atanion.net/tobago-example-demo/ with this 
Version.


Regards

Udo

Grant Smith schrieb:

+1

On 10/16/07, *Udo Schnurpfeil* <[EMAIL PROTECTED] 
> wrote:


Here is my

+1

Regards

Udo

Bernd Bohmann schrieb:
> Hello,
>
> I would like to release Tobago 1.0.12.
>
> This release contains over 60 changes.
> For a detail list please consult the release notes:
>
>

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12312498 


 


>
>
> The version is available at the staging location and the
> revision number of the release is 584843 and tagged as
tobago-1.0.12.
>
> Staging distribution:
>
> http://people.apache.org/~bommel/repo/

>
> Staging repository:
>
> http://people.apache.org/~bommel/repo/

>
> Regards
>
> Bernd
>
>
> The Vote is open for 72h.
>
> [ ] +1
> [ ] +0
> [ ] -1
>




--
Grant Smith

Re: common maven build targets

[Arvid Hülsebus]

I think these plugins are Maven 1 only -- like the Raven Plugin...

Regards,
Arvid

Travis Reeder wrote:
> Hey all,
>
> Would someone be kind enough to post and describe all the common maven
> targets on the wiki?  Being a maven newb, this would mucho helpful. 
>
> Also, has anyone tried the maven plugins for intellij?  I've tried the
> ConsoleMavenPlugin and the Mavenide one, but they don't appear to
> pickup the "Goals" in our pom's. 
>
> Thanks in advance.
>
> Travis
>

Re: Refactor Commons to org.apache.myfaces.commons ?

[Arvid Hülsebus]

Normally it does, but there are some limitations. I will ask Udo when he 
is back -- in about 30 minutes. He gained some experience restructuring 
our repository for the donation of the Tobago source.


Regards,
Arvid

Manfred Geiler wrote:

pps. Use svn move to do this so we don't lose our history



Does anyone know if IntelliJ does "svn move" behind the scenes when
moving (refactoring) classes?

Thanks,
Manfred

  

Re: Refactor Commons to org.apache.myfaces.commons ?

[Arvid Hülsebus]

It looks like he had only problems with older versions of IDEA or the 
Subversion client. We can't report any problems with IDEA 5.1.


Regards,
Arvid

Martin Marinschek wrote:

+1 from me. definitely.

regards,

Martin

On 2/17/06, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:
  

Normally it does, but there are some limitations. I will ask Udo when he
is back -- in about 30 minutes. He gained some experience restructuring
our repository for the donation of the Tobago source.

Regards,
Arvid

Manfred Geiler wrote:


pps. Use svn move to do this so we don't lose our history



Does anyone know if IntelliJ does "svn move" behind the scenes when
moving (refactoring) classes?

Thanks,
Manfred


  



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

  

Re: New JIRA: Tobago

[Arvid Hülsebus]

Wow, cool! Thank you!

I'm going to update the issue tracker URL in our POM as soon as I am home.

Regards,
Arvid

Sean Schofield wrote:

I also added a new JIRA instance for Tobago.  I moved all of the
Tobago issues over from the original JIRA.  I believe committers can
change the versions and add components so the Tobago team should have
everything they need to manage this.  Let me or Manfred know if you
need JIRA admin help.

Sean

  

Re: JIRA Changes

[Arvid Hülsebus]

Just click on "Edit this issue" in the sidebar under Operations and 
assign a new component.


Regards,
Arvid

Matthias Wessendorf wrote:

may be a silly question,
but how to change / move a bug to a special component
e.g. from other -> tree2

Thanks,
Matthias

On 2/21/06, Bruno Aranda <[EMAIL PROTECTED]> wrote:
  

Thanks Sean for the hard work,

+1 from me to put sandox under tomahawk.

Regards,

Bruno

On 2/21/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:


Thanks Sean!

  

I have moved all of the tomahawk issues (at least the ones marked
tomahawk in the original jira) to the new JIRA project.  JIRA is also
smart enough to map the old issue numbers with new issue numbers.  So
if you try to navigate to MYFACES-975[1], JIRA knows enough to
redirect you to TOMAHAWK-96.


this is cool :-)

  

I have not moved the sandbox stuff yet.  My thinking is that sandbox
components should be part of the Tomahawk JIRA since they are part of
the same maven subproject and they will eventually be promoted to
Tomahawk.  They will also always have the same versions as Tomahawk.
If I get some +1's I will move these also.


I am +1 on having sandox stuff under tomahawk. for the reasons you pointed out
-maven subproject
-promotion

Sounds reasonable to me

-Matthias

  

I haven't changed the permissions or notification at all.  We can talk
about that at a future point once we get everything into the right
spot.  Take a look and let me know what you think.

Sean

[1] https://issues.apache.org/jira/browse/MYFACES-975



--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

  



--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

  

acceptcharset vs. acceptCharset

[Arvid Hülsebus]

Hello,

is it intended that the acceptCharset attribute of  is written
in mixed case in MyFaces 1.1.1 and lower case in the Sun RI 1.1.01?

Thanks in advance,
Arvid

[tobago] release procedure

[Arvid Hülsebus]

Hello,

We managed to fix all (but one -- the fix is still tested) issues
scheduled for 1.0.7. We expect to have a release candidate soon. After
some more testing I would propose to have a vote to decide if we can
release the candidate.

Are there any suggestions to improve this?

Regards,
Arvid

Re: [VOTE] Tobago Release 1.0.7

[Arvid Hülsebus]

I checked my two test applications and found no problems up to now.

+1

Regards,
Arvid

[tobago] announcement preparations

[Arvid Hülsebus]

Hello Manfred,

Since there were no -1 votes, we thought the release was accepted. We
prepared everything and wrote an announcement email (see below). Can I
send it to the user list or would you prefer to do it yourself -- or
anyone else from the PMC?

Thanks in advance,
Arvid

The MyFaces Tobago team is pleased to announce the release of MyFaces
Tobago 1.0.7.

MyFaces Tobago 1.0.7 is available for download from:

  http://myfaces.apache.org/tobago/download.html

This is the first release of Tobago under the wings of MyFaces and the
ASF. The version 1.0.7 is meant as a first stable release to build upon.
The changes include:

Bugs

- Font of  was not correct, if disabled="true"
- Tab panel in Richmond-Theme had scrollbars
- Exception when submitting form without actionId
- UITree lost config when rerendering view
- Could not set focus to text input in sheet
  control (Internet Explorer only)
- SelectManyRendererBase could not handle setters
- JavaScript error in  when showHeader="false"

Improvements

- Extended the tx taglib, so the label attribute of
  the tc taglib is no longer been used
- Combined the attributes label, labelWithAccessKey and accessKey
  to a single attribute label
- Visual indicator for marked nodes in 
- Simplified the theme handling
- Toolbar button should open drop down menu
- No exception, but warning in logfile, when using wrong count
  of columns in 
- Sheet supports paging in DataModel if getRowCount() returns -1

New Features

- Facelets integration
- Support for sheet sorting by application

For a complete list please see:

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310273&fixfor=12310824

Enjoy,

Arvid Hülsebus

Re: [VOTE] Release Apache Tobago 1.0.8

[Arvid Hülsebus]

+1

Looks good -- my small test application works.

Best regards,

Arvid

Bernd Bohmann wrote:

Hello,

Please vote on releasing Apache Tobago 1.0.8.

The current nightly build should be the 1.0.8 release.

http://people.apache.org/builds/myfaces/nightly/

[+1] Make the 1.0.8 release of Tobago
[+0] I don't care
[-1] No... and this is why...


Current release notes

http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273&styleName=Html&version=12310900 



Regards

Bernd

Re: [VOTE] Release Apache Tobago 1.0.8

[Arvid Hülsebus]

Hello,

It looks like we need to talk about what compatibility could mean for 
Tobago. We are compatible to JSF since Tobago runs on top of  MyFaces 
and the Sun RI. We invested some time to be compatible to Facelets. Most 
of the Shale stuff works with Tobago, too.


Other compatibility issues are:

- using Tobago controls on Tomahawk pages (an HTML page with Tomahawk 
and standard HTML controls)
In general there are issues with renderkit ids if I remember correctly. 
Tobago is not (only) a HTML renderkit. On a normal JSF page a Tobago 
control is missing its layout and theme context. It should be possible 
to provide this -- using a theme which fits to the rest of the page and 
giving Tobago a rectangular area to layout within.


- using Tomahawk controls (or controls from other renderkits) on Tobago 
pages
Again I think we have problems with different renderkit ids. 
Additionally Tobago needs to know about the size of the control and 
needs some means to adapt the size for layouting. And the page developer 
needs to customize the CSS of the control which fits to the Tobago 
theme. Making the included control respond to theme changes might be 
pretty complicated.


Best regards,
Arvid

Martin Marinschek wrote:

+1 from me for a release of Tobago.

In any case - are there any new efforts to make Tobago more compatible
to the rest of the JSF world?

We've all put a bit of effort into compatibility in tomahawk and impl,
and I'd like to see some effort in the tobago code base as well...

regards,

Martin

On 9/13/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:

Is this intended to be a Java 1.5-only release for examples?

I get this error when trying to run the examples under java 1.4.2.

java.lang.UnsupportedClassVersionError:
org/apache/myfaces/tobago/webapp/TobagoServletContextListener
(Unsupported major.minor version 49.0)


On 9/13/06, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> you can download the tobago examples from
>
> 
http://people.apache.org/builds/myfaces/nightly/myfaces-tobago-example-1.0.8-SNAPSHOT-bin.tar.gz 


>
> the 1.0.8-SNAPSHOT is the next release
>
> Mike Kienenberger wrote:
> > See this thread:
> >
> > 
http://mail-archives.apache.org/mod_mbox/myfaces-users/200604.mbox/[EMAIL PROTECTED] 


> >
> >
> > On 9/13/06, L Frohman <[EMAIL PROTECTED]> wrote:
> >> I was wondering the same thing, why isn't Tobago being "merged" 
into

> >> Tomahawk?
> >>
> >> -Original Message-
> >> From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, September 13, 2006 8:34 AM
> >> To: MyFaces Development
> >> Subject: Re: [VOTE] Release Apache Tobago 1.0.8
> >>
> >> On 9/13/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> >> > FWIW, this is the kind of thing that motivates "a MyFaces 
committer is
> >> > a MyFaces committer", as opposed to trying to segregate folks 
only
> >> > interested in Tobago.  On the other hand, the fact that only a 
small
> >> > number of folks in the MyFaces committer community seem 
interested in

> >> > Tobago is a danger signal.
> >>
> >> I wasn't around with Tobago joined up, but my experience so far is
> >> that it's
> >> almost impossible to be both a Tobago and a Tomahawk 
user/developer.

> >>
> >> I can't speak for anyone else, but I don't have time to work 
with two

> >> incompatible frameworks.
> >>
> >> I tried to start a dialog a while back on merging Tobago and 
Tomahawk

> >> (or at
> >> least making them more compatible) but nothing really came of it.
> >>
> >> If Tobago and Tomahawk aren't going to be made compatible with each
> >> other, I
> >> think perhaps that Tobago should become its own top-level project.
> >>
> >> Yes, there are some parts that overlap (like the proposed 
commons jar for

> >> non-rendering code), but not enough that I feel qualified as a PMC
> >> member to
> >> vote on a Tobago release.
> >>
> >>
> >
>

Re: Tobago release announcement

[Arvid Hülsebus]

Hello,

After the Core is officially released now, I am going to send the 
announcement for Tobago, too. Last time I sent it to:


announce@myfaces.apache.org, announce@apache.org, users@myfaces.apache.org

Are these still the appropriate recipients?

We are going to add the major changes in the notes, too -- similar to 
the last Core announcement.


Regards,
Arvid


Wendy Smoak wrote:

There is a draft release announcement on the wiki:

  http://wiki.apache.org/myfaces/TobagoRelease108

Any further changes?  Who is going to send it?

Re: Tobago release announcement

[Arvid Hülsebus]

I think I will skip announce@apache.org this time. The description of 
the mailing list says "major releases", which 1.0.8 is definitely not.


Regards,
Arvid

Re: [OT] Any Tobago developers going to Apache Con San Diego?

[Arvid Hülsebus]

Currently none of us atanion guys made plans to attend to the Apache Con 
San Diego. We already went to the Apache Con Europe this year. Although 
it would be a great chance to get to know each other. But now it would 
be a little terse to make it possible.


Regards,
Arvid

Sean Schofield wrote:


I have been meaning to learn more about this incubator project.  I'd
love to talk in person if you are planning on going.

sean

 

Re: Volunteers Needed

[Arvid Hülsebus]

Hello!

No, Maven 2 doesn't require JDK 1.5.

I played around with a small XSLT to convert the MyFaces/Forrest XDoc
documents into Maven XDoc documents. The DTD


http://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk/xdoc/src/dtd/maven-xdoc.dtd

is slightly different. You can the attached files into 
http://svn.apache.org/repos/asf/myfaces/forrest/trunk/content/ plus
the 'dtd' and 'entity' from 
http://svn.apache.org/repos/asf/forrest/trunk/main/webapp/resources/schema/ 
into a local temporary 'resource' directory and run ant. See the 
xmlcatalog element in the build file. (I failed to either disable DTD 
checking or attach an archive with the necessary files)


This will create a 'converted' directory with the new files. For testing
purposes I just copied these files into
http://atanion.net/repos/asf/tobago/trunk/tobago-core/src/site/xdoc and run

  mvn site

inside the tobago-core directory. Currently, generating the site inside
the Tobago root directory doesn't work due to

  http://jira.codehaus.org/browse/MNG-1455

The generated files will end up inside the 'target/site' directory. Far
from perfect but a starting point...

Regards,
Arvid





  


  
  

  

  


http://www.w3.org/1999/XSL/Transform"; version="1.0">
  

  

  


  

  

  

  
  

  

  

  

  

  
  

  

  

  
  

  

  

  


  

  

  

  

  
  
  

  

  

  

  

  

  

  

Tobago vs. Maven2: The wrecked Dependency

[Arvid Hülsebus]

Hello,

while preparing the svn dump for Tobago, we encountered a problem with 
deploying the Tobago demo app from a fresh system. It turned out that 
this was due to fetching the most recent version of the 'jstl-1.1.0' 
POM. This POM was recently changed on Ibiblio and now points to a 
relocated version of the JSTL with the new group id 'javax.servlet'. If 
you where lucky you already had a cached version of the older version of 
the POM in your local repository. Otherwise the updated JSTL POM has a 
new dependency to 'jsp-api', which ends up inside the WAR. Thus 
disabling the demo app.


We fixed the POMs of Tobago. If you had problems building Tobago lately, 
this may solve your problem.


Regards,
Arvid

Re: [Tobago] Change the groupId of Tobago to follow the naming conventions of maven

[Arvid Hülsebus]

+1

Regards,
Arvid

Bernd Bohmann wrote:


Hello,

I would like to change the groupId of Tobago to follow the naming
convention of maven.

Change from

tobago

to

org.apache.myfaces.tobago

See http://maven.apache.org/guides/mini/guide-naming-conventions.html

I think myfaces should follow this naming convention in a future
release, too.

Here is my +1

Best Regards

Bernd

Re: [tobago] URI Names of the Taglib

[Arvid Hülsebus]

+1

Arvid

Re: svn commit: r356552 - in /incubator/tobago/trunk: src/site/fml/faq.fml tobago-theme/tobago-theme-richmond/pom.xml

[Arvid Hülsebus]

We didn't have the time to really check out Facelets up to now. We 
removed the according FAQ entry and will take some time to look closer 
at Facelets. From the documentation of Facelets we just saw the 
"Tapestry-like views" aspect and this doesn't seem to make sense for Tobago.


Regards,
Arvid

Adam Winer wrote:


Mike is entirely correct.  There's no reason why any decent
JSF component library shouldn't work with Facelets,
and [EMAIL PROTECTED] doesn't understand Facelets.
ADF Faces, for example, abstracts away from HTML too;
Facelets makes awesome sense with ADF Faces, just as
it would with Tobago.

The whole "Tapestry-like views" aspect of Facelets is just
one small bit of it;  the major value is providing a much, much
better environment for JSF than JSPs are.

Honestly, anyone who uses Facelets after JSPs will
never want to go back.  I don't quite get why MyFaces hasn't
embraced Facelets fully.

-- Adam Winer

On 12/13/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
 


I think there's some misunderstanding here about facelets.   Facelets
isn't tied to any particular view technology (ie, html).

"Facelets are based on HTML-designed JSP source code" is untrue.
Facelets doesn't use tld files or (jsp)Tag classes.   Facelets works
directly on the component class.

There shouldn't be any reason why you can't use facelets with tobago,
providing you're writing clean components.


On 12/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
   


Author: bommel
Date: Tue Dec 13 09:35:51 2005
New Revision: 356552

URL: http://svn.apache.org/viewcvs?rev=356552&view=rev
Log:
added faq for facelets

Modified:
   incubator/tobago/trunk/src/site/fml/faq.fml
   incubator/tobago/trunk/tobago-theme/tobago-theme-richmond/pom.xml

Modified: incubator/tobago/trunk/src/site/fml/faq.fml
URL: 
http://svn.apache.org/viewcvs/incubator/tobago/trunk/src/site/fml/faq.fml?rev=356552&r1=356551&r2=356552&view=diff
==
--- incubator/tobago/trunk/src/site/fml/faq.fml (original)
+++ incubator/tobago/trunk/src/site/fml/faq.fml Tue Dec 13 09:35:51 2005
@@ -22,6 +22,16 @@
  components that need a renderer.
   

+
+  It is possible to combine tobago with facelets?
+  
+It doesn't make sense.
+Facelets are based on HTML-designed JSP source code.
+Tobago on the other side abstracts from HTML. There are no 
HTML-Tags in the JSP source code.
+   There are only abstract tags. The Renderkit converts it to HTML or 
any other ML.
+   The idea of Tobago is: The theme controls the look-and-feel of the 
page.
+  
+

  Can tobago replace tiles? Can I ignore tiles and sitemesh in 
the favor of tobago or not?
  

Modified: incubator/tobago/trunk/tobago-theme/tobago-theme-richmond/pom.xml
URL: 
http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-theme/tobago-theme-richmond/pom.xml?rev=356552&r1=356551&r2=356552&view=diff
==
--- incubator/tobago/trunk/tobago-theme/tobago-theme-richmond/pom.xml (original)
+++ incubator/tobago/trunk/tobago-theme/tobago-theme-richmond/pom.xml Tue Dec 
13 09:35:51 2005
@@ -26,7 +26,7 @@
  
  tobago-theme-richmond
  jar
-  Tobago theme richmond
+  Tobago theme Richmond
  

  
@@ -75,7 +75,7 @@
  


-   javax.servlet
+  javax.servlet
  servlet-api
  2.3
  provided



 



 

Re: svn commit: r365935 - /incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js

[Arvid Hülsebus]

Hello Volker,

the log function was used in the unit test to track down my localization 
problems --  i.e. invoking JavaScript per Rhino. I doubt that currently 
the LOG from Tobago will work inside this limited environment. Perhaps 
something like HttpUnit will provide enough DOM Level 0 and higher 
support to make this work. I will check this...


Regards,
Arvid

Volker Weber wrote:


Arvid,

if you removed this because log() is undefined:

In tobago javascript you can use LOG.debug(), LOG.info(), LOG.warn(),
and LOG.error() for logging on client side.

Currently the error level mades no difference, but this is a todo.

If the client is in debug mode (to force this add a accepted language of
'to_ba_go' in your browser config) a normaly hidden logging panel is
rendered which can be opened by LOG.show() eg. type
"javascript:LOG.show()" in the address bar.

@Udo: This is the place where the debug output goes which i removed last
week from the created html source.

Regards,
 Volker

[EMAIL PROTECTED] wrote:
 


Author: idus
Date: Wed Jan  4 08:33:08 2006
New Revision: 365935

URL: http://svn.apache.org/viewcvs?rev=365935&view=rev
Log:
removed debug stuff

Modified:
   
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js

Modified: 
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
URL: 
http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js?rev=365935&r1=365934&r2=365935&view=diff
==
--- 
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
 (original)
+++ 
incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/script/dateConverter.js
 Wed Jan  4 08:33:08 2006
@@ -241,9 +241,6 @@
  if (patternSub.length == 3) {
var fragment = dateStr.substr(dateIndex, 3);
var index = this._indexOf(this.dateFormatSymbols.shortMonths, fragment);
-log("shortMonths: " + this.dateFormatSymbols.shortMonths);
-log("fragment: " + fragment);
-log("index: " + index);
if (index != -1) {
  context.month = index;
  context.newIndex = dateIndex + 3;
@@ -260,7 +257,6 @@
this._parseNum(context, dateStr, 2, dateIndex);
context.month = context.retValue - 1;
  }
-  log("month: " + context.month);
} else {
  if (patternSub.length == 3) {
context.dateStr += this.dateFormatSymbols.shortMonths[context.month];


   



 

Re: [maven] Revised Reorg Proposal --> Was: [maven] Latest maven changes

[Arvid Hülsebus]

Sean Schofield wrote:


Does this mean that if you build the child, it asks the parent to build?  If 
so, then that is interesting (not a problem - just unexpected.)
 

As far as I understand it Maven only builds "child" projects if the POM 
includes a module entry for that "child". In general it applies a goal 
on all included modules. These child modules won't even need a parent 
entry. Maven just changes into the directory with name in the module entry.


The parent entry is more or less for inheriting common stuff. But it 
won't instruct Maven to build the parent.


Regards,
Arvid

Re: maven build fails

[Arvid Hülsebus]

Hello Volker,

I just tried the same. It works for me -- out of the box.

By 'uncommenting' you mean disabling the 
maven-project-info-reports-plugin by comments? Because there aren't any 
comments in these sections right now.


Perhaps you can try to force the update of the plugin by -U or try to 
remove the whole ~/.m2/repository/org/apache/maven/plugins directory.


Regards,
Arvid

Volker Weber wrote:


Hi,

i just followed the instructions on:

http://wiki.apache.org/myfaces/Building_With_Maven

to build a snapshot, but the build fails.

i got a NullPointerException [1].

after uncommenting the 'maven-project-info-reports-plugin' plugin in
reporting section of:
 api/pom.xml, tomahawk/tomahawk/pom.xml and sandbox/sandbox/pom.xml
the build runs through.

Regards,
 Volker

[1]:
 


[EMAIL PROTECTED]:~/java/myfaces/current/build$ mvn install
[INFO] Scanning for projects...
[INFO] 

[ERROR] FATAL ERROR
[INFO] 

[INFO] null
[INFO] 

[INFO] Trace
java.lang.NullPointerException
   at java.util.TreeMap.compare(TreeMap.java:1093)
   at java.util.TreeMap.getEntry(TreeMap.java:347)
   at java.util.TreeMap.containsKey(TreeMap.java:204)
   at 
org.apache.maven.project.ModelUtils.mergeReportPluginDefinitions(ModelUtils.java:324)
   at 
org.apache.maven.project.ModelUtils.mergeReportPluginLists(ModelUtils.java:156)
   at 
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleReportingInheritance(DefaultModelInheritanceAssembler.java:277)
   at 
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:170)
   at 
org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:56)
   at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:605)
   at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298)
   at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276)
   at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509)
   at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441)
   at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485)
   at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485)
   at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) 
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 

[INFO] Total time: 1 second
[INFO] Finished at: Sun Jan 08 12:40:26 CET 2006
[INFO] Final Memory: 1M/3M
[INFO] 

[EMAIL PROTECTED]:~/java/myfaces/current/build$ 
   




 

Re: test failed

[Arvid Hülsebus]

Hello!

I just updated the sources and run a 'mvn clean install' and everything
worked out fine. The tests didn't fail. Did you try a clean? Are you
using Maven 2.0.1?

Regards,
Arvid

Mario Ivankovits wrote:
> Hi!
>
> Could someone please confirm that the tests against the current svn head
> fail?
>
> Currently I try to implement the "commandLink submit script" but after
> an "svn update" the following exception occurs during "mvn install".
> I cant see any class I changed being involved ... so I am not sure if
> its my fault or if the current svn is somewhat unstable.
>
> junit.framework.AssertionFailedError:
>   Unexpected method call
> getValue([EMAIL PROTECTED]):
> getValue([EMAIL PROTECTED]):
> expected: 0, actual: 1
> getValue(null): expected: 1, actual: 0
> at
> org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
> at
> org.easymock.classextension.MockClassControl$2.intercept(MockClassControl.java:67)
> at
> $javax.faces.el.ValueBinding$$EnhancerByCGLIB$$a458a51c.getValue()
> at
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1151)
> at
> javax.faces.component.UIComponentBaseTest.testIsRenderedBinding(UIComponentBaseTest.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
>
> Thanks!
> Mario
>   

Re: [maven] Need help with the nightly builds

[Arvid Hülsebus]

Hello!

Which Apache projects do not ship required dependencies in their
binaries? I just checked a few projects, which do:

velocity-1.4.tar.gz
turbine-2.3.2.tar.gz
jakarta-cactus-12-1.7.1.zip
struts-1.2.8-bin.zip
jakarta-jmeter-2.1.1.zip
axis-bin-1_3.zip
fop-0.20.5-bin.zip
xmlbeans-2.1.0.zip
xalan-j_2_7_0-bin.zip
...

Regards,
Arvid

Sean Schofield wrote:
>> -1
>>
>> If you have a dependency to a snapshot version you should/must include
>> the transitive dependencies in the bin assembly.
>> But we can create two assemblies one with all dependencies and one
>> without. What is the problem about this.
>> We should provide a simple solution for the normal user.
>> 
>
> If this is "the Maven way" then I respectfully disagree.  It's certain
> not "the Apache way."  I can't think of many ASF projects that ship
> the transitive dependencies in their nightly or release builds.
>
> Its also a waste of bandwidth IMO.  Maven is for managing your
> dependencies but nothing about Maven requires that you include the
> depedencies in your final product.
>
>   
>> Bernd
>> 
>
> Sean
>
>   

Re: [maven] Need help with the nightly builds

[Arvid Hülsebus]

Independent of how Maven does things, I would like to have at least the
"required" dependencies in a binary assembly. With "required"
dependencies I mean dependencies which are required to run the core
functionality. Perhaps we can compare the situation for the binary
assembly with Ant, where you have optional tasks. If you want to use
these, you have to install additional optional JARs.

Maven supports the notion of optional, too. But I never used it up to
now. Here is an example from the Spring POM:


  log4j
  log4j
  true


For release candidates or development snapshots which rely on snapshot
dependencies I would definitely like to have those included in a binary
assembly. Otherwise I might have problems to get the correct snapshot
versions.

If you use Maven or another build tool which makes use of the Maven
project metadata all you need to do is to specify the dependency. In
this case there is no need to do download the binary assembly anymore.
Additionally Maven makes sure dependencies are only downloaded once --
saving bandwidth. In this scenario you wouldn't need to download
sources, too. Eclipse users can run something like this:

mvn eclipse:eclipse -Declipse.downloadSources=true

BTW, I prepared a patch for the maven-idea-plugin to have the same for
Idea. As soon as I have proper unit tests I will add the patch to the
Maven Jira.

Regards,
Arvid


Sean Schofield wrote:
> Arvid,
>
> You are right.  I guess many of the ASF projects do in fact ship with
> the dependencies.  I didn't think Struts did but I guess I forgot.  Of
> course these days I just build Struts from the source ...
>
> In the past MyFaces has *not* shipped with all of these dependencies. 
> Most people have them already.  If our release notes contain the list
> of dependencies (as generated by maven) do we really need to include
> them?  One of the dependencies for tomahawk is struts.jar.  Until
> there is a standalone tiles released do you think we should
> redistribute the entire Struts jar just because its a dependency?
>
> Sean
>
> On 1/20/06, Arvid Hülsebus <[EMAIL PROTECTED]> wrote:
>   
>> Hello!
>>
>> Which Apache projects do not ship required dependencies in their
>> binaries? I just checked a few projects, which do:
>>
>> velocity-1.4.tar.gz
>> turbine-2.3.2.tar.gz
>> jakarta-cactus-12-1.7.1.zip
>> struts-1.2.8-bin.zip
>> jakarta-jmeter-2.1.1.zip
>> axis-bin-1_3.zip
>> fop-0.20.5-bin.zip
>> xmlbeans-2.1.0.zip
>> xalan-j_2_7_0-bin.zip
>> ...
>>
>> Regards,
>> Arvid
>>
>> Sean Schofield wrote:
>> 
>>>> -1
>>>>
>>>> If you have a dependency to a snapshot version you should/must include
>>>> the transitive dependencies in the bin assembly.
>>>> But we can create two assemblies one with all dependencies and one
>>>> without. What is the problem about this.
>>>> We should provide a simple solution for the normal user.
>>>>
>>>> 
>>> If this is "the Maven way" then I respectfully disagree.  It's certain
>>> not "the Apache way."  I can't think of many ASF projects that ship
>>> the transitive dependencies in their nightly or release builds.
>>>
>>> Its also a waste of bandwidth IMO.  Maven is for managing your
>>> dependencies but nothing about Maven requires that you include the
>>> depedencies in your final product.
>>>
>>>
>>>   
>>>> Bernd
>>>>
>>>> 
>>> Sean
>>>
>>>
>>>   
>> 
>
>   

Re: Site now includes Tobago and ADF Faces

[Arvid Hülsebus]

And its Maven 2.0(.x). Maven 2.1 is not released yet ;-)

Arvid

Volker Weber wrote:


Hi,

someone should correct the date on line 36 in file
site/src/site/apt/index.apt

 


November 7, 2006 - MyFaces Switches to Maven 2.1.
   



I think it should be 2005, but is november the 7. the right date?
Was it realy so long ago?

Regards,
 Volker


Sean Schofield wrote:
 


The future site has been tweaked to include a mention of Tobago and
ADF Faces.  I took most of the wording from the incubator proposals. 
People should look it over and let a committer know if changes need to

be made.

As usual you can build the site using maven.  Eventually the changes
should also replicate to the site experimentation area.[1]  We'll try
to roll the site out as the official MyFaces site this weekend.

Sean

[1] http://people.apache.org/~schof/myfaces.apache.org/.

   



 

Re: [continuum] Site deploy problem

[Arvid Hülsebus]

BTW, Internet Explorer has problems rendering transparent PNGs... 



Regards,
Arvid

Re: [continuum] Site deploy problem

[Arvid Hülsebus]

But there is a workaround via an IE specific filter:
progid:DXImageTransform.Microsoft.AlphaImageLoader

Regards,
Arvid

Re: [continuum] Site deploy problem

[Arvid Hülsebus]

Adding the following to style.css

#banner img {
  behavior: url(css/png-fix.htc);
}

and placing the other attachements like this:

site/src/site/resources/css/
  png-fix.htc
site/src/site/resources/images/
  transparent.gif

solves the problem for the top level HTML files...  perhaps the banner
generation from the Maven template can be overwritten resulting in a
more robust solution.  Here I have problems with loading the behaviour
via the CSS file from other directories.

Regards,
Arvid



/*
 * Based on 
 * http://www.mongus.net/pngInfo/
 * and
 * http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
 *
 */

var gNeedFix = needFix();

var transparentImage = "transparent.gif";

pngFix();

function propertyChanged() {
if (event.propertyName == "src") {
pngFix();
  }
}

function pngFix() {
if (!gNeedFix) {
return;
}

var src = element.src;

if (src.indexOf(transparentImage) != -1) {
return;
}

if (src.indexOf(".png") == -1) {
return;
}

var w = element.width;
var h = element.height;
element.src = src.substring(0, src.lastIndexOf('/') + 1)  + 
transparentImage;
element.width = w;
element.height = h;
element.runtimeStyle.filter = 
"progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + src + 
"',sizingMethod='scale')";
}

function needFix() {
var pos = navigator.userAgent.indexOf("MSIE ");
if (pos == -1) {
return false;
}
var version = navigator.userAgent.substring(pos + 5);
return (((version.indexOf("5.5") == 0) || (version.indexOf("6") 
== 0)) && (navigator.platform == ("Win32")));
}




body {
background-color: #fff;
	font-family: Verdana, Helvetica, Arial, sans-serif;
	margin-left: auto;
	margin-right: auto;
	background-repeat: repeat-y;
	font-size: 13px;
	padding: 0px;
}
td, select, input, li{
	font-family: Verdana, Helvetica, Arial, sans-serif;
	font-size: 12px;
	color:#33;
}
code{
  font-size: 12px;
}
a {
  text-decoration: none;
}
a:link {
  color:#47a;
}
a:visited  {
  color:#66;
}
a:active, a:hover {
  color:#99;
}
#legend li.externalLink {
  background: url(../images/external.png) left top no-repeat;
  padding-left: 18px;
}
a.externalLink, a.externalLink:link, a.externalLink:visited, a.externalLink:active, a.externalLink:hover {
  background: url(../images/external.png) right center no-repeat;
  padding-right: 18px;
}
#legend li.newWindow {
  background: url(../images/newwindow.png) left top no-repeat;
  padding-left: 18px;
}
a.newWindow, a.newWindow:link, a.newWindow:visited, a.newWindow:active, a.newWindow:hover {
  background: url(../images/newwindow.png) right center no-repeat;
  padding-right: 18px;
}
h2 {
	font-size: 17px;
	color: #33;  
}
h3 {
	padding: 4px 4px 4px 24px;
	color: #66;
	background-color: #CECECE;
	font-weight: bold;
	font-size: 14px;
	background-image: url(../images/h3.jpg);
	background-repeat: no-repeat;
	background-position: left bottom;
}
p {
  line-height: 1.3em;
  font-size: 12px;
  color: #000;
}
#breadcrumbs {
	color: #DD;
	padding: 5px 5px 5px 5px;
}

* html #breadcrumbs {
	padding-bottom: 8px;
}
#leftColumn {
  background-color: #B2C4E0;
}
#navcolumn h5 {
	font-size: smaller;
	border-bottom: 1px solid #aa;
	padding-top: 2px;
	padding-left: 9px;
	color: #49635a;
	background-image: url(../images/h5.gif);
	background-repeat: no-repeat;
	background-position: left bottom;
}

table.bodyTable th {
  color: white;
  background-color: #99;
  text-align: left;
  font-weight: bold;
}

table.bodyTable th, table.bodyTable td {
  font-size: 11px;
}

table.bodyTable tr.a {
  background-color: #ddd;
}

table.bodyTable tr.b {
  background-color: #eee;
}

.source {
  border: 1px solid #999;
  overflow:auto
}
dt {
	padding: 4px 4px 4px 24px;
	color: #33;
	background-color: #ccc;
	font-weight: bold;
	font-size: 14px;
	background-image: url(../images/h3.jpg);
	background-repeat: no-repeat;
	background-position: left bottom;
}
.subsectionTitle {
	font-size: 13px;
	font-weight: bold;
	color: #666;

}

table {
	font-size: 10px;
}
.xright a:link, .xright a:visited, .xright a:active {
  color: #666;
}
.xright a:hover {
  color: #003300;
}
#banner {
	background-color: #B5C8CF;
	border-bottom: 1px solid #B5C8CF;
}
#navcolumn ul {
	margin: 5px 0 15px -0em;
}
#navcolumn ul a {
	color: #33;
}
#navcolumn ul a:hover {
	color: red;
}
#intro {
	border: solid #ccc 1px;
	margin: 6px 0px 0px 0px;
	padding: 10px 40px 10px 40px;
}
.subsection {
	margin-left: 3

Re: [proposal] Split Up JIRA Projects

[Arvid Hülsebus]

You can just move the bug. No real problem.

Regards,
Arvid

Jesse Alexander (KBSA 21) wrote:

How easy will it be to move an item reported (erronously) against
MyFaces-core to MyFaces-Tomahawk? It is one of the worst-case
scenarios for the community-support, when a user gets the 
bug-report answer: "wrong project, please resubmit against ...".

That would be the easiest way to scare off users..

regards
Alexander 

  

-Original Message-
From: Mike Kienenberger [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 14, 2006 3:00 PM

To: MyFaces Development
Subject: Re: [proposal] Split Up JIRA Projects

I'm concerned with the impacts of this proposal.

I strongly suspect that we're going to start seeing issues filed
against MYFACES instead of the relevent subproject if you split them
out like this.

However, I don't know if there's a reasonable way to handle separate
releases in JIRA otherwise.  I know that Velocity split Velocity-tools
out into a separate jira issue, and I think it was for the same
reason.

I also wonder what the eventual impact of splitting out sub projects
for each project apache-wide are going to be, but that's probably
outside of the discussion.

Maybe Apache should request a JIRA enhancement to make this kind of
reorganization unnecessary.  Browsing through the JIRA system,
possibly it's already mitigated somewhat by the "category" property of
JIRA, and we only need to make sure that things are categorized
properly (I see that VELTOOLS and XERCESP seem to be uncategorized).  
However, it seems to be that it'd be better if JIRA supported separate

releases based on components.

Could we consider prefixing the names with MYFACES to at least keep
them all grouped together in JIRA?   MYFACES, MYFACESTOMAHAWK,
MYFACESTOBAGO, etc.

As for reporting bugs against commons, I think it'd be more
appropriate for them to go against TOMAHAWK by default.Think of
the use cases.   If it's a commons bug that manifests itself against
the IMPL, then the user is already likely to post the bug against
MYFACES.   If it's a use case such that the user knows it's a commons
problem, the user is probably creating components using the shared
coded and using TOMAHAWK rather than IMPL as the build target.

On 2/13/06, Sean Schofield <[EMAIL PROTECTED]> wrote:

I propose we split up some of the JIRA projects.  Right now 
  

everything

is lumped under MYFACES.  I haven't though through all the 
  

details but


I thought I would throw out a starter proposal to get the discussion
going.  I think we should try to act on this soon and then publish
more instructions on the website about how to report issues.

I propose we have the following projects: MYFACES, TOMAHAWK, TOBAGO.
The current MYFACES instance will be just for the core.  We move all
of the tomahawk (and sandbox) stuff into the new TOMAHAWK one.  The
TOBAGO one will be all of the stuff that's in their 
  

incubator section


now.

My thinking is that we do NOT have a separate project for commons.
Ultimately I think this will confuse the users.  We can 
  

report them in


MYFACES instead.

Also in the TOMAHAWK project we could add the actual components as
JIRA components and start reporting the bugs against the specific
components.  I think that will be helpful also.

Finally, we should start using 1.1.2-SNAPSHOT, etc. as 
  

version numbers


instead of nightly.  Then when releasing we add a 1.1.X version and
change the resolved in 1.1.X-SNAPSHOT to resolved in 1.1.X.

We'll have to clear it with INFRA (about having two extra projects)
but I don't really see the big deal.

Thoughts?

Sean