From simon at 333.ch  Thu Apr  1 00:47:37 2010
From: simon at 333.ch (simon)
Date: Thu Apr  1 01:00:52 2010
Subject: [Yanel-dev] Re: [Yanel-commits] rev 48424
	-	public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt
In-Reply-To: <201003312158.o2VLwxB3010652@cvs-extra.wyona.com>
References: <201003312158.o2VLwxB3010652@cvs-extra.wyona.com>
Message-ID: <4BB3D109.4070209@333.ch>

michi@wyona.com schrieb:
> Author: michi
> Date: 2010-03-31 23:58:59 +0200 (Wed, 31 Mar 2010)
> New Revision: 48424
>
> Modified:
>    public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl
> Log:
> login zone added
>
> Modified: public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl
> ===================================================================
> --- public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl	2010-03-31 21:58:36 UTC (rev 48423)
> +++ public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl	2010-03-31 21:58:59 UTC (rev 48424)
> @@ -43,8 +43,51 @@
>          <title>
>            <xsl:value-of select="/xhtml:html/xhtml:head/xhtml:title"/>
>          </title>
> +
> +        <!-- JQuery inclusion -->
> +        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
> [...]
are you sure you want to use the jquery from the internet. doesn't this 
mean one has to be online to use it?

simon

From michael.wechner at wyona.com  Thu Apr  1 00:48:10 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr  1 01:01:28 2010
Subject: [Yanel-dev] Login Zone Link
Message-ID: <4BB3D12A.3000702@wyona.com>

Hi

I have added a login-zone-link to the from scratch realm, which means if 
you hover with the mouse at
the upper right corner of your browser, then an image will appear saying 
"Login" and allows the user
to click in order to get to the login screen.

I think this is a very nice for people familiar with Yanel to find the 
login page without having to make
a link available or remember some hidden URL.

Please give it a try and let me know what you think

Thanks

Michi
From michael.wechner at wyona.com  Thu Apr  1 00:57:01 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr  1 01:10:34 2010
Subject: [Yanel-dev] Re: [Yanel-commits] rev
	48424	-	public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt
In-Reply-To: <4BB3D109.4070209@333.ch>
References: <201003312158.o2VLwxB3010652@cvs-extra.wyona.com>
	<4BB3D109.4070209@333.ch>
Message-ID: <4BB3D33D.10501@wyona.com>

simon wrote:
> michi@wyona.com schrieb:
>> Author: michi
>> Date: 2010-03-31 23:58:59 +0200 (Wed, 31 Mar 2010)
>> New Revision: 48424
>>
>> Modified:
>>    
>> public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl 
>>
>> Log:
>> login zone added
>>
>> Modified: 
>> public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl 
>>
>> ===================================================================
>> --- 
>> public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl    
>> 2010-03-31 21:58:36 UTC (rev 48423)
>> +++ 
>> public/yanel/trunk/src/realms/from-scratch-realm-template/data-repo/data/app1/xslt/global.xsl    
>> 2010-03-31 21:58:59 UTC (rev 48424)
>> @@ -43,8 +43,51 @@
>>          <title>
>>            <xsl:value-of select="/xhtml:html/xhtml:head/xhtml:title"/>
>>          </title>
>> +
>> +        <!-- JQuery inclusion -->
>> +        <script type="text/javascript" 
>> src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script> 
>>
>> [...]
> are you sure you want to use the jquery from the internet. doesn't 
> this mean one has to be online to use it?

good catch, thanks very much for pointing this out. I have changed it now

svn ci -m "jquery moved here instead from the web" .
Adding         app1/js
Adding         app1/js/jquery
Adding         app1/js/jquery/1.2.6
Adding         app1/js/jquery/1.2.6/jquery.min.js
Sending        app1/xslt/global.xsl
Transmitting file data ..
Committed revision 48425.

whereas this should be fine license wise, because it's dual licensed 
also using the MIT license.

At least I hope ;-)

Thanks

Michi
>
> simon
>

From guillaume.deflache at wyona.com  Thu Apr  1 10:21:20 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Thu Apr  1 10:34:30 2010
Subject: [Yanel-dev] GWT 2.0 IE7 caveat: do not use
	com.google.gwt.xml.client.Element.getElementsByTagName("*")
Message-ID: <4BB45780.2000100@wyona.com>

Hi!

I had a hard time diagnosing this, so I'd better share it:

At least on GWT 2.0 and IE7, 
com.google.gwt.xml.client.Element.getElementsByTagName("*") always 
returns an empty NodeList on IE, whereas it behaves as expected on e.g. 
Firefox, i.e. it return all child elements of the given element as per 
the DOM spec.

One would have though GWT would have isolated us from the browser 
peculiarities in their API as many JS libraries do, but apparently not! :/

HTH,
    Guillaume
From michael.wechner at wyona.com  Thu Apr  1 10:41:40 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr  1 10:54:54 2010
Subject: [Yanel-dev] GWT 2.0 IE7 caveat: do not
	use	com.google.gwt.xml.client.Element.getElementsByTagName("*")
In-Reply-To: <4BB45780.2000100@wyona.com>
References: <4BB45780.2000100@wyona.com>
Message-ID: <4BB45C44.6080409@wyona.com>

Guillaume D?flache wrote:
> Hi!
>
> I had a hard time diagnosing this, so I'd better share it:
>
> At least on GWT 2.0 and IE7, 
> com.google.gwt.xml.client.Element.getElementsByTagName("*") always 
> returns an empty NodeList on IE, whereas it behaves as expected on 
> e.g. Firefox, i.e. it return all child elements of the given element 
> as per the DOM spec.

thanks very much for sharing this
>
> One would have though GWT would have isolated us from the browser 
> peculiarities in their API as many JS libraries do, but apparently 
> not! :/

I think GWT does try hard to make it work independently of the browser 
and IIRC the GWT docs says sometimes explicitely
if something does not behave the same on every browser and I think it's 
up to each of us to test our code as soon as possible,
such that we can recognize such issues from the very beginning. The 
earlier we recognize issues, then easier the analysis
becomes at large.

Thanks

Michi


>
> HTH,
>    Guillaume

From mehmet.birgi at wyona.com  Thu Apr  1 11:56:08 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr  1 12:09:30 2010
Subject: [Yanel-dev] Re: [Dev] Maven repo dupes
In-Reply-To: <4BB34541.6020405@wyona.com>
References: <z2g5bf1397d1003302359h52bfc490z97c9071298cd978a@mail.gmail.com>
	<4BB3072F.40207@wyona.com>
	<v2i5bf1397d1003310528v5d4c74fbuc48bd7515b152586@mail.gmail.com>
	<4BB34541.6020405@wyona.com>
Message-ID: <g2r5bf1397d1004010256gb4e6f95lb4c6850ceb9796c6@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part -----=
---------
A non-text attachment was scrubbed...
Name: build.log
Type: application/octet-stream
Size: 243684 bytes
Desc: not available
Url : http://lists.wyona.org/pipermail/yanel-development/attachments/201004=
01/2e92b74a/build-0001.obj
From mehmet.birgi at wyona.com  Thu Apr  1 12:01:18 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr  1 12:18:24 2010
Subject: [Yanel-dev] Re: [Dev] Maven repo dupes
In-Reply-To: <g2r5bf1397d1004010256gb4e6f95lb4c6850ceb9796c6@mail.gmail.com>
References: <z2g5bf1397d1003302359h52bfc490z97c9071298cd978a@mail.gmail.com>
	<4BB3072F.40207@wyona.com>
	<v2i5bf1397d1003310528v5d4c74fbuc48bd7515b152586@mail.gmail.com>
	<4BB34541.6020405@wyona.com>
	<g2r5bf1397d1004010256gb4e6f95lb4c6850ceb9796c6@mail.gmail.com>
Message-ID: <v2h5bf1397d1004010301y901e638es68be989e96c1c131@mail.gmail.com>

sorry, here is the wholw dependencies block, might make more sense:

dependencies:
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.pom from central
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-=
commons-discovery-0.2.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-j=
akarta-commons-id-0.1-dev-lcr357257.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-=
commons-logging-1.0.4.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons=
-io-1.2.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.jar from wyona.remote.repository
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.jar from central
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-=
commons-discovery-0.2.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 70K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-j=
akarta-commons-id-0.1-dev-lcr357257.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 53K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-=
commons-logging-1.0.4.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 37K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons=
-io-1.2.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 64K from wyona.remote.repository




On Thu, Apr 1, 2010 at 11:56 AM, Mehmet Birgi <mehmet.birgi@wyona.com>wrote:

> OK, I have attached the build.log, and the important lines seem to be
> those:
>
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.pom from central
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commo=
ns-io-1.2.pom
> from wyona.remote.repository
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.jar from wyona.remote.repository
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.jar from central
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commo=
ns-io-1.2.jar
> from wyona.remote.repository
>
> can anybody tell what the problem is?
>
>
>
>
> On Wed, Mar 31, 2010 at 2:51 PM, Michael Wechner <
> michael.wechner@wyona.com> wrote:
>
>> Mehmet Birgi wrote:
>>
>>> Thanks for all the feedback. As this is low priority, I might get back =
to
>>> it later, but I will not pursue this issue at the moment.
>>>
>>
>> I would like you to spend 15 minutes on this. Please give the debugging
>> approach as I suggested a try and also please
>> add a bugzilla entry, because these ambiguities can lead to problems and
>> hence we better get it documented it at least.
>>
>> Thanks
>>
>> Michi
>>
>>>
>>> Cheers,
>>>
>>> Memo
>>>
>>>
>>>
>>> 2010/3/31 Guillaume D=E9flache <guillaume.deflache@wyona.com <mailto:
>>> guillaume.deflache@wyona.com>>
>>>
>>>
>>>    [This message just came on one internal Wyona mailing-lists,
>>>    answering it here as it is of general interest: ]
>>>
>>>    Mehmet Birgi schrieb:
>>>
>>>    > Yesterday, while we were looking for the jakarta-commons-io lib
>>>    to use, Guillaume noticed that this library is included twice,
>>>    namely in:
>>>    >
>>>    >
>>>
>>>  /Users/memo/.m2/repository/apache-jakarta-commons/apache-jakarta-commo=
ns-io/1.2/apache-jakarta-commons-io-1.2.jar
>>>    >
>>>
>>>  /Users/memo/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
>>>
>>>    I previously found a statement in the jakarta-commons mailing-list
>>>    about what is the now recommended form (I do not really remember
>>>    which one so I won't risk a guess) and a rationale for it, I'll
>>>    try to dig it up at home.
>>>
>>>
>>>
>>>    > As they are both the same version, one of them should be enough.
>>>    There may be other dupes, we didn't search for them. The bug
>>>    http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7006
>>>    also seems to be remotely related to this. Would it be worth the
>>>    effort to
>>>
>>>    It is indeed related to this. The cleanup explained below is made
>>>    as part of
>>>    http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D6896
>>>
>>>
>>>
>>>    > try to clean out the maven repository? Or should I just enter a
>>>    new P2
>>>
>>>    To sum it up is not really our or Maven's central repositories
>>>    that are "dirty", it's rather the dependencies metadata that do
>>>    not cater for renames of the groupId/artifactId couples during the
>>>    life of a library.
>>>    Cleaning that would probably remove all "duplicate librairies",
>>>    but it is a long term task and not a very high priority ATM I think.
>>>
>>>
>>>
>>>    > bug and "forget about it" for now?
>>>
>>>    No need to enter another bug.
>>>    You can forget about it for now as an application developer as the
>>>    only real way to try to fix this is to clean up the dependency
>>>    tree starting from its "leaves".
>>>    For now only wyona-commons has been cleaned up (see r45585 on
>>>    <http://svn.wyona.com/repos/public/>), next target up the tree is
>>>    yarep.
>>>    I had already started on that so please coordinate with us on this
>>>    list if you want to work on that.
>>>
>>>
>>>    HTH,
>>>      Guillaume
>>>    --     Yanel-development mailing list Yanel-development@wyona.com
>>>    <mailto:Yanel-development@wyona.com>
>>>
>>>    http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>> --
>>> Mehmet Birgi
>>> www.wyona.com <http://www.wyona.com>
>>>
>>>
>> --
>> Yanel-development mailing list Yanel-development@wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
> --
> Mehmet Birgi
> www.wyona.com
>
>


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
1/fceddaaf/attachment.htm
From guillaume.deflache at wyona.com  Thu Apr  1 14:00:43 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Thu Apr  1 14:13:56 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
Message-ID: <4BB48AEB.9070907@wyona.com>

Hi!

AFAIK this is all that is needed to make Vim behave WRT indentation to 
meet Yanel coding conventions.
This is the most safe and straightforward way I found, but it can 
probably be done differently/better:
---8<---
set expandtab " never add TAB characters
set tabstop=2 shiftwidth=2 " by default indentation is 2, e.g. for HTML 
and XML-based syntaxes like XHTML, XSLT, etc.
au BufNewFile,BufRead *.java,*.js,*.css set tabstop=4 shiftwidth=4 " 
indentation is 4 for languages using braces for nesting like Java, 
Javascript, CSS. etc.
---8<---

Of course you may want to use an IDE like Eclipse or IntelliJ IntelliJ 
IDEA instead! :P

HTH,
    Guillaume
From michael.wechner at wyona.com  Thu Apr  1 14:01:27 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr  1 14:14:40 2010
Subject: [Yanel-dev] Capturing data by Eclipse
Message-ID: <4BB48B17.4000407@wyona.com>

Hi

I have just noticed that Eclipse is capturing data as described

http://www.eclipse.org/org/usagedata/faq.php

I guess/hope they use it to improve to Eclipse.

Maybe some food for thought ;-)

Thanks

Michi
From mehmet.birgi at wyona.com  Thu Apr  1 14:34:23 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr  1 14:47:44 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
In-Reply-To: <4BB48AEB.9070907@wyona.com>
References: <4BB48AEB.9070907@wyona.com>
Message-ID: <i2v5bf1397d1004010534idd1ed15cz33cbdcd5c1d31a0d@mail.gmail.com>

Thanks, Guillaume.

I had to make a small adaptation to make it work, because I am using "set
softtabstop=3DX". Now it seems to work nicely.

Here is the part of my .vimrc concerning tabs:

set autoindent
set softtabstop=3D2
set shiftwidth=3D2
set expandtab
"indentation for languages using braces for nesting like Java, Javascript,
CSS. etc.
au BufNewFile,BufRead *.java,*.js,*.css set softtabstop=3D4 shiftwidth=3D4

Also, there is more information on that subject at
http://vim.wikia.com/wiki/Indenting_source_code




2010/4/1 Guillaume D=E9flache <guillaume.deflache@wyona.com>

> Hi!
>
> AFAIK this is all that is needed to make Vim behave WRT indentation to me=
et
> Yanel coding conventions.
> This is the most safe and straightforward way I found, but it can probably
> be done differently/better:
> ---8<---
> set expandtab " never add TAB characters
> set tabstop=3D2 shiftwidth=3D2 " by default indentation is 2, e.g. for HT=
ML and
> XML-based syntaxes like XHTML, XSLT, etc.
> au BufNewFile,BufRead *.java,*.js,*.css set tabstop=3D4 shiftwidth=3D4 "
> indentation is 4 for languages using braces for nesting like Java,
> Javascript, CSS. etc.
> ---8<---
>
> Of course you may want to use an IDE like Eclipse or IntelliJ IntelliJ ID=
EA
> instead! :P
>
> HTH,
>   Guillaume
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
1/da70c9bc/attachment.htm
From michael.wechner at wyona.com  Thu Apr  1 14:34:40 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr  1 14:47:54 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
In-Reply-To: <4BB48AEB.9070907@wyona.com>
References: <4BB48AEB.9070907@wyona.com>
Message-ID: <4BB492E0.5090600@wyona.com>

Dear Guillaume

Thanks very much for sharing this.

Just being curious, but did I as a vi(m) user do anything wrong? Or is 
just a general hint/pointer?

I think we should add these notes to our coding standards:

http://www.yanel.org/en/development/processes/index.html
http://www.yanel.org/en/documentation/index.html


Thanks

Michi

Guillaume D?flache wrote:
> Hi!
>
> AFAIK this is all that is needed to make Vim behave WRT indentation to 
> meet Yanel coding conventions.
> This is the most safe and straightforward way I found, but it can 
> probably be done differently/better:
> ---8<---
> set expandtab " never add TAB characters
> set tabstop=2 shiftwidth=2 " by default indentation is 2, e.g. for 
> HTML and XML-based syntaxes like XHTML, XSLT, etc.
> au BufNewFile,BufRead *.java,*.js,*.css set tabstop=4 shiftwidth=4 " 
> indentation is 4 for languages using braces for nesting like Java, 
> Javascript, CSS. etc.
> ---8<---
>
> Of course you may want to use an IDE like Eclipse or IntelliJ IntelliJ 
> IDEA instead! :P
>
> HTH,
>    Guillaume

From guillaume.deflache at wyona.com  Thu Apr  1 15:35:23 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Thu Apr  1 15:48:34 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
In-Reply-To: <4BB492E0.5090600@wyona.com>
References: <4BB48AEB.9070907@wyona.com> <4BB492E0.5090600@wyona.com>
Message-ID: <4BB4A11B.9010905@wyona.com>

Michael Wechner schrieb:
> Dear Guillaume
> 
> Thanks very much for sharing this.
> 
> Just being curious, but did I as a vi(m) user do anything wrong? Or is 
> just a general hint/pointer?

Oh no, sorry for the confusion: memo could not quite find how to do it, 
so I dug it up from my configuration files.


BTW any idea if there is an option to stop Vim from always adding a line 
ending for the last line of a file when it is missing?

For example:
$ echo -n foo > bar
$ vim bar # just save it as baz, i.e. :wq baz
$ env LANG=C diff -u bar baz
--- bar	2010-04-01 15:26:58.000000000 +0200
+++ baz	2010-04-01 15:29:20.000000000 +0200
@@ -1 +1 @@
-foo
\ No newline at end of file
+foo
$

This is the single thing I do not know how to control that makes Vim 
produces unwanted differences.
So all in all Vim is very fine for cooperative development indeed! :)
From mehmet.birgi at wyona.com  Thu Apr  1 16:00:45 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr  1 16:14:43 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
In-Reply-To: <4BB4A11B.9010905@wyona.com>
References: <4BB48AEB.9070907@wyona.com> <4BB492E0.5090600@wyona.com>
	<4BB4A11B.9010905@wyona.com>
Message-ID: <p2j5bf1397d1004010700x27eb2819ha78990d2c48d5751@mail.gmail.com>

I did a little research on the web, and apparently the " \ No newline at end
of file" message is not really a bug, but more of a feature :-)

C compilers (and maybe others) expect each file to be terminated with a \n,
and will object otherwise. This seems to be the reason why Vim always adds
this character if it is not present already. For more reasons for having a
\n at the end of files, see:
http://stackoverflow.com/questions/729692/why-should-files-end-with-a-newli=
ne

Unfortunately, I couldn't find a simple way to change this behaviour.

cheers,

memo



2010/4/1 Guillaume D=E9flache <guillaume.deflache@wyona.com>

> Michael Wechner schrieb:
>
>  Dear Guillaume
>>
>> Thanks very much for sharing this.
>>
>> Just being curious, but did I as a vi(m) user do anything wrong? Or is
>> just a general hint/pointer?
>>
>
> Oh no, sorry for the confusion: memo could not quite find how to do it, so
> I dug it up from my configuration files.
>
>
> BTW any idea if there is an option to stop Vim from always adding a line
> ending for the last line of a file when it is missing?
>
> For example:
> $ echo -n foo > bar
> $ vim bar # just save it as baz, i.e. :wq baz
> $ env LANG=3DC diff -u bar baz
> --- bar 2010-04-01 15:26:58.000000000 +0200
> +++ baz 2010-04-01 15:29:20.000000000 +0200
> @@ -1 +1 @@
> -foo
> \ No newline at end of file
> +foo
> $
>
> This is the single thing I do not know how to control that makes Vim
> produces unwanted differences.
> So all in all Vim is very fine for cooperative development indeed! :)
>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
1/e3091f70/attachment.htm
From mehmet.birgi at wyona.com  Tue Apr  6 09:37:17 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr  6 09:57:45 2010
Subject: [Yanel-dev] Login Zone Link
In-Reply-To: <4BB3D12A.3000702@wyona.com>
References: <4BB3D12A.3000702@wyona.com>
Message-ID: <o2z5bf1397d1004060037s7fa0d81dia95b1e2b68e005b9@mail.gmail.com>

Good idea!

The only improvement I can think of is to anti-alias the "LOGIN" text for a
white background, that would look a bit better.

Cheers,

Memo



On Thu, Apr 1, 2010 at 12:48 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Hi
>
> I have added a login-zone-link to the from scratch realm, which means if
> you hover with the mouse at
> the upper right corner of your browser, then an image will appear saying
> "Login" and allows the user
> to click in order to get to the login screen.
>
> I think this is a very nice for people familiar with Yanel to find the
> login page without having to make
> a link available or remember some hidden URL.
>
> Please give it a try and let me know what you think
>
> Thanks
>
> Michi
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
6/4a7ddf95/attachment.htm
From michael.wechner at wyona.com  Tue Apr  6 10:26:59 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr  6 10:41:13 2010
Subject: [Yanel-dev] Login Zone Link
In-Reply-To: <o2z5bf1397d1004060037s7fa0d81dia95b1e2b68e005b9@mail.gmail.com>
References: <4BB3D12A.3000702@wyona.com>
	<o2z5bf1397d1004060037s7fa0d81dia95b1e2b68e005b9@mail.gmail.com>
Message-ID: <4BBAF053.9040302@wyona.com>

Mehmet Birgi wrote:
> Good idea!
>
> The only improvement I can think of is to anti-alias the "LOGIN" text 
> for a white background, that would look a bit better.

I have exchanged the image now by the new kangaroo logo.

Cheers

Michi
>
> Cheers,
>
> Memo
>
>
>
> On Thu, Apr 1, 2010 at 12:48 AM, Michael Wechner 
> <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>     Hi
>
>     I have added a login-zone-link to the from scratch realm, which
>     means if you hover with the mouse at
>     the upper right corner of your browser, then an image will appear
>     saying "Login" and allows the user
>     to click in order to get to the login screen.
>
>     I think this is a very nice for people familiar with Yanel to find
>     the login page without having to make
>     a link available or remember some hidden URL.
>
>     Please give it a try and let me know what you think
>
>     Thanks
>
>     Michi
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From mehmet.birgi at wyona.com  Tue Apr  6 14:52:13 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr  6 15:11:28 2010
Subject: [Yanel-dev] Vim configuration for Yanel development
In-Reply-To: <i2v5bf1397d1004010534idd1ed15cz33cbdcd5c1d31a0d@mail.gmail.com>
References: <4BB48AEB.9070907@wyona.com>
	<i2v5bf1397d1004010534idd1ed15cz33cbdcd5c1d31a0d@mail.gmail.com>
Message-ID: <j2y5bf1397d1004060552zab900c09qa94817c58e4d7178@mail.gmail.com>

Update: the version with softtabstop (below) doesn't seem to work as
expected, so I have reverted to Guillaume's proposal (using "set
tabstop=3D2"), which seems to work. Next I will document this in our
documentation.

Cheers,

Memo



On Thu, Apr 1, 2010 at 2:34 PM, Mehmet Birgi <mehmet.birgi@wyona.com> wrote:

> Thanks, Guillaume.
>
> I had to make a small adaptation to make it work, because I am using "set
> softtabstop=3DX". Now it seems to work nicely.
>
> Here is the part of my .vimrc concerning tabs:
>
> set autoindent
> set softtabstop=3D2
> set shiftwidth=3D2
> set expandtab
> "indentation for languages using braces for nesting like Java, Javascript,
> CSS. etc.
> au BufNewFile,BufRead *.java,*.js,*.css set softtabstop=3D4 shiftwidth=3D4
>
> Also, there is more information on that subject at
> http://vim.wikia.com/wiki/Indenting_source_code
>
>
>
>
> 2010/4/1 Guillaume D=E9flache <guillaume.deflache@wyona.com>
>
> Hi!
>>
>> AFAIK this is all that is needed to make Vim behave WRT indentation to
>> meet Yanel coding conventions.
>> This is the most safe and straightforward way I found, but it can probab=
ly
>> be done differently/better:
>> ---8<---
>> set expandtab " never add TAB characters
>> set tabstop=3D2 shiftwidth=3D2 " by default indentation is 2, e.g. for H=
TML
>> and XML-based syntaxes like XHTML, XSLT, etc.
>> au BufNewFile,BufRead *.java,*.js,*.css set tabstop=3D4 shiftwidth=3D4 "
>> indentation is 4 for languages using braces for nesting like Java,
>> Javascript, CSS. etc.
>> ---8<---
>>
>> Of course you may want to use an IDE like Eclipse or IntelliJ IntelliJ
>> IDEA instead! :P
>>
>> HTH,
>>   Guillaume
>> --
>> Yanel-development mailing list Yanel-development@wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
> --
> Mehmet Birgi
> www.wyona.com
>
>


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
6/e4d12a31/attachment.htm
From bugzilla at wyona.com  Tue Apr  6 15:41:15 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Tue Apr  6 15:41:16 2010
Subject: [Yanel-dev] [Bug 7551] New: Duplicate Apache commons-io in .m2
Message-ID: <20100406134115.0C22A10CA7F@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551

           Summary: Duplicate Apache commons-io in .m2
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: General
        AssignedTo: michael.wechner@wyona.org
        ReportedBy: mehmet.birgi@wyona.com
         QAContact: yanel-development@wyona.com


The library Apache commons-io is included twice in the maven repository,
probably due to an inconsistency in the dependencies tree.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Tue Apr  6 15:43:03 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Tue Apr  6 15:43:05 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
Message-ID: <20100406134303.2F0FD10CA7F@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551





------- Comment #1 from mehmet.birgi@wyona.com  2010-04-06 14:39 -------
Here is the related output from the build.log:

-----

dependencies:

[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.pom from central
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository

[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.pom
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository

[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.jar from wyona.remote.repository
[artifact:dependencies] Downloading:
commons-io/commons-io/1.2/commons-io-1.2.jar from central
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 70K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 53K from wyona.remote.repository
[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 37K from wyona.remote.repository

[artifact:dependencies] Downloading:
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
from wyona.remote.repository
[artifact:dependencies] Transferring 64K from wyona.remote.repository


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Tue Apr  6 15:46:02 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Tue Apr  6 15:46:04 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
Message-ID: <20100406134602.1BB2210CA7F@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551





------- Comment #2 from mehmet.birgi@wyona.com  2010-04-06 14:42 -------
This bug is also related to the following bugs:
http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6896
http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7006


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Tue Apr  6 15:52:19 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Tue Apr  6 15:52:22 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
Message-ID: <20100406135219.5908310CAB7@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551


michael.wechner@wyona.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|michael.wechner@wyona.org   |mehmet.birgi@wyona.com




------- Comment #3 from michael.wechner@wyona.org  2010-04-06 14:48 -------
It would be important that you add the piece of the log file where one can see
from where the Maven download is actually started. Right now one can only see,
that it is downloaded, but not which resource or realm or component is actually
triggering the download


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From mehmet.birgi at wyona.com  Tue Apr  6 15:44:12 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr  6 15:57:58 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <20100406135219.5908310CAB7@server1.example.com>
References: <20100406135219.5908310CAB7@server1.example.com>
Message-ID: <j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part -----=
---------
A non-text attachment was scrubbed...
Name: build.log
Type: application/octet-stream
Size: 243684 bytes
Desc: not available
Url : http://lists.wyona.org/pipermail/yanel-development/attachments/201004=
06/f6580e94/build-0001.obj
From michael.wechner at wyona.com  Tue Apr  6 16:39:48 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr  6 16:53:10 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
Message-ID: <4BBB47B4.8020302@wyona.com>

 From your log-file it seems that these libraries are downloaded at the 
very beginning of the build:

Apache Ant version 1.7.1 compiled on June 27 2008
INFO: Building Yanel...
Buildfile: src/build/build.xml

init:
     [echo] INFO: Building with Apache Ant version 1.7.1 compiled on 
June 27 2008 and Java version 1.6
     [echo] Yanel Home Dir: /Users/memo/Wyona/Work/Yanel/src/build/../../

probe-proxy:
     [echo] Check if proxy has been set ...

proxy:

dependencies:
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.pom from central
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom 
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom 
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom 
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.pom 
from wyona.remote.repository
[artifact:dependencies] Transferring 0K from wyona.remote.repository
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.jar from wyona.remote.repository
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.jar from central
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 70K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 53K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 37K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 64K from wyona.remote.repository
    [unzip] Expanding: 
/Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into 
/Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2


Now one has to analyze why. I guess the easiest is to delete the whole 
local Maven repo and build/log again and then analyze it again. (I 
assume you just deleted this libs instead the whole local repo, right?)

Thanks

Michi

Mehmet Birgi wrote:
> Hi Michael
>
> On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com 
> <mailto:bugzilla@wyona.com>> wrote:
>
>     http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551
>
>
>     michael.wechner@wyona.org <mailto:michael.wechner@wyona.org> changed:
>
>               What    |Removed                     |Added
>     ----------------------------------------------------------------------------
>             AssignedTo|michael.wechner@wyona.org
>     <mailto:michael.wechner@wyona.org>   |mehmet.birgi@wyona.com
>     <mailto:mehmet.birgi@wyona.com>
>
>
>
>
>     ------- Comment #3 from michael.wechner@wyona.org
>     <mailto:michael.wechner@wyona.org>  2010-04-06 14:48 -------
>     It would be important that you add the piece of the log file where
>     one can see
>     from where the Maven download is actually started. Right now one
>     can only see,
>     that it is downloaded, but not which resource or realm or
>     component is actually
>     triggering the download
>
>
> I am not sure I understand what you mean, I have attached the whole 
> log file, can you point me to the proper entries? Maybe this 
> information is not logged?
>
> Thanks,
>
> Memo
>
>
>  
>
>
>
>     --
>     Configure bugmail:
>     http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
>     ------- You are receiving this mail because: -------
>     You are the QA contact for the bug, or are watching the QA contact.
>     --
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From mehmet.birgi at wyona.com  Tue Apr  6 23:23:14 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr  6 23:36:46 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <4BBB47B4.8020302@wyona.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
Message-ID: <w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>

Skipped content of type multipart/alternative-------------- next part -----=
---------
A non-text attachment was scrubbed...
Name: build.log
Type: application/octet-stream
Size: 258799 bytes
Desc: not available
Url : http://lists.wyona.org/pipermail/yanel-development/attachments/201004=
06/ea636df5/build-0001.obj
From michael.wechner at wyona.com  Wed Apr  7 09:21:31 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 09:34:54 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
Message-ID: <4BBC327B.1070305@wyona.com>

Dear Memo

 From your log file I can see

[artifact:dependencies] Downloading: 
wyona-org-commons/wyona-org-commons/1.0-dev-r48003/wyona-org-commons-1.0-dev-r48003.pom 
from wyona.remote.repo
sitory
[artifact:dependencies] Transferring 1K from wyona.remote.repository
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
[artifact:dependencies] Downloading: 
commons-io/commons-io/1.2/commons-io-1.2.pom from central

and checking on

/Users/michaelwechner/.m2/repository/wyona-org-commons/wyona-org-commons/1.0-dev-r48003/wyona-org-commons-1.0-dev-r48003.pom

shows that commons-io-1.2 us referenced there or rather in

https://svn.wyona.com/repos/public/commons/trunk/build.xml

Also I can see

[artifact:dependencies] Downloading: 
wyona-org-security/wyona-org-security-core/0.2-dev-r48408/wyona-org-security-core-0.2-dev-r48408.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 17K from wyona.remote.repository
[artifact:dependencies] Downloading: 
avalon-framework/avalon-framework-api/4.3/avalon-framework-api-4.3.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 31K from wyona.remote.repository
[artifact:dependencies] Downloading: 
avalon-framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 58K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 70K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 53K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar 
from wyona.remote.repository
[artifact:dependencies] Transferring 37K from wyona.remote.repository
[artifact:dependencies] Downloading: 
apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar 
from wyona.remote.repository

which means apache-jakarta-commons-io-1.2 is referenced from within

https://svn.wyona.com/repos/public/security/trunk/dependencies.xml

Now we can start cleaning, whereas the question is which one we want to 
clean and I am concerned that there will be more
such cases ...

Cheers

Michi

Mehmet Birgi wrote:
> What I could find out so far:
>
> 1. The correct artifact-id is "commons-io", according to the Maven 
> docs, that point to ibiblio.org/maven2 <http://ibiblio.org/maven2> as 
> the reference 
> (http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/maven-metadata.xml)
>
> 2. I have found a reference to the "incorrect" artifact-id, 
> "apache-jakarta-commons-io", but there seem to be several others too:
>
> memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI 
> apache-jakarta-commons-io src | grep -v '/\.svn/' | grep -v '\.yarep/'
> src/build/dependencies.xml:      <dependency 
> groupId="apache-jakarta-commons" artifactId="apache-jakarta-commons-io"
> src/contributions/resources/xinha/src/build/dependencies.xml:      
> <dependency groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/realms/welcome-admin/yanel/resources/update-webapp/src/build/dependencies.xml:      
> <dependency groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/resources/add-realm/src/build/dependencies.xml:      <dependency 
> groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/resources/testing-control/src/build/dependencies.xml:      
> <dependency groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/resources/tinymce/src/build/dependencies.xml:      <dependency 
> groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/resources/xml/src/build/dependencies.xml:      <dependency 
> groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
> src/test/build.xml:      <dependency groupId="apache-jakarta-commons" 
> artifactId="apache-jakarta-commons-io" version="1.2"/>
>
>
> I am attaching the new build.log after deleting ~/.m2 to this mail, I 
> couldn't gain any new insights from it, but I will gladly pursue any 
> further hints.
>
> That's it for now, cheers & good night
>
> Memo
>
>
>
>
>
> On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner 
> <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>     From your log-file it seems that these libraries are downloaded at
>     the very beginning of the build:
>
>     Apache Ant version 1.7.1 compiled on June 27 2008
>     INFO: Building Yanel...
>     Buildfile: src/build/build.xml
>
>     init:
>        [echo] INFO: Building with Apache Ant version 1.7.1 compiled on
>     June 27 2008 and Java version 1.6
>        [echo] Yanel Home Dir:
>     /Users/memo/Wyona/Work/Yanel/src/build/../../
>
>     probe-proxy:
>        [echo] Check if proxy has been set ...
>
>     proxy:
>
>
>     dependencies:
>     [artifact:dependencies] Downloading:
>     commons-io/commons-io/1.2/commons-io-1.2.pom from
>     wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     commons-io/commons-io/1.2/commons-io-1.2.pom from central
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 0K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 0K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 0K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.pom
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 0K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     commons-io/commons-io/1.2/commons-io-1.2.jar from
>     wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     commons-io/commons-io/1.2/commons-io-1.2.jar from central
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 70K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 53K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 37K from wyona.remote.repository
>     [artifact:dependencies] Downloading:
>     apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>     from wyona.remote.repository
>     [artifact:dependencies] Transferring 64K from wyona.remote.repository
>       [unzip] Expanding:
>     /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into
>     /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>
>
>     Now one has to analyze why. I guess the easiest is to delete the
>     whole local Maven repo and build/log again and then analyze it
>     again. (I assume you just deleted this libs instead the whole
>     local repo, right?)
>
>     Thanks
>
>     Michi
>
>     Mehmet Birgi wrote:
>
>         Hi Michael
>
>
>         On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com
>         <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>         <mailto:bugzilla@wyona.com>>> wrote:
>
>            http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551
>
>
>            michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>         <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>> changed:
>
>
>                      What    |Removed                     |Added
>          
>          ----------------------------------------------------------------------------
>                    AssignedTo|michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>            <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>   |mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>
>            <mailto:mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>>
>
>
>
>
>
>            ------- Comment #3 from michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>            <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>  2010-04-06 14:48 -------
>
>            It would be important that you add the piece of the log
>         file where
>            one can see
>            from where the Maven download is actually started. Right
>         now one
>            can only see,
>            that it is downloaded, but not which resource or realm or
>            component is actually
>            triggering the download
>
>
>         I am not sure I understand what you mean, I have attached the
>         whole log file, can you point me to the proper entries? Maybe
>         this information is not logged?
>
>         Thanks,
>
>         Memo
>
>
>          
>
>
>            --
>            Configure bugmail:
>          
>          http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
>            ------- You are receiving this mail because: -------
>            You are the QA contact for the bug, or are watching the QA
>         contact.
>            --
>            Yanel-development mailing list Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>
>            <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>>
>
>          
>          http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>         -- 
>         Mehmet Birgi
>         www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From michael.wechner at wyona.com  Wed Apr  7 10:36:35 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 10:50:05 2010
Subject: [Yanel-dev] Login Zone Link
In-Reply-To: <4BB3D12A.3000702@wyona.com>
References: <4BB3D12A.3000702@wyona.com>
Message-ID: <4BBC4413.6090305@wyona.com>

Hi

 I have slightly improved this by moving the code into various 
core-webapp files such that it can be re-used more easier.
In order to use it within your own website/realm one can reference it 
from the XHTML head


<head>
        <!-- Yanel toolbar zone -->
        <script type="text/javascript" 
src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/jquery/1.2.6/jquery.min.js"></script>
        <script type="text/javascript" 
src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/toolbar-zone.js"></script>
        <link media="screen" type="text/css" 
href="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-css/toolbar-zone.css" 
rel="stylesheet"/>

      </head>

and add it to the body as

      <body>
<xsl:if test="$yanel.toolbar-status = 'off'">
<div id="yanelToolbarZone">
  <div id="yanelToolbarZoneLink" style="display: none; height: 60px; 
width: 60px;">
    <a href="?yanel.toolbar=on" title="Turn on Toolbar" alt="Turn on 
Toolbar"><img style="position: absolute; right:5px; top:5px;" 
src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-img/yanel_kangaroo.png" 
height="48" width="109" border="0"/></a>
  </div>
</div>
</xsl:if>

Also we have added a new smaller logo displaying our new kangaroo.

Cheers

Michi

Michael Wechner wrote:
> Hi
>
> I have added a login-zone-link to the from scratch realm, which means 
> if you hover with the mouse at
> the upper right corner of your browser, then an image will appear 
> saying "Login" and allows the user
> to click in order to get to the login screen.
>
> I think this is a very nice for people familiar with Yanel to find the 
> login page without having to make
> a link available or remember some hidden URL.
>
> Please give it a try and let me know what you think
>
> Thanks
>
> Michi

From mehmet.birgi at wyona.com  Wed Apr  7 10:39:42 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr  7 10:53:11 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <4BBC327B.1070305@wyona.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
	<4BBC327B.1070305@wyona.com>
Message-ID: <v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>

Re which one to use: in the maven documentation, it is suggested (
http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_exte=
rnal_dependencies,
7. paragraph) that one use http://ibiblio.org/maven2 as a reference to what
the artifact id should be for any (apache) dependency. According to that, we
should use "commons-io", rather than "apache-jakarta-commons-io". So I would
suggest that we change all the dependencies referring to
"apache-jakarta-commons-io" to refer to "commons-io". Is that OK, or are
there other things to consider? If you agree, I will try to find out if this
is documented somewhere, and if not, add it to the best practices, OK?

(cont. below)

On Wed, Apr 7, 2010 at 9:21 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Dear Memo
>
> From your log file I can see
>
> [artifact:dependencies] Downloading:
> wyona-org-commons/wyona-org-commons/1.0-dev-r48003/wyona-org-commons-1.0-=
dev-r48003.pom
> from wyona.remote.repo
> sitory
> [artifact:dependencies] Transferring 1K from wyona.remote.repository
>
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.pom from wyona.remote.repository
> [artifact:dependencies] Downloading:
> commons-io/commons-io/1.2/commons-io-1.2.pom from central
>
> and checking on
>
>
> /Users/michaelwechner/.m2/repository/wyona-org-commons/wyona-org-commons/=
1.0-dev-r48003/wyona-org-commons-1.0-dev-r48003.pom
>
> shows that commons-io-1.2 us referenced there or rather in
>
> https://svn.wyona.com/repos/public/commons/trunk/build.xml
>

this seems to be the correct one, according to the maven docs (see above). I
am guessing that the ant task "wyona-tools:dependencies" in this build.xml
file produces the pom file above?


>
> Also I can see
>
> [artifact:dependencies] Downloading:
> wyona-org-security/wyona-org-security-core/0.2-dev-r48408/wyona-org-secur=
ity-core-0.2-dev-r48408.jar
> from wyona.remote.repository
> [artifact:dependencies] Transferring 17K from wyona.remote.repository
> [artifact:dependencies] Downloading:
> avalon-framework/avalon-framework-api/4.3/avalon-framework-api-4.3.jar fr=
om
> wyona.remote.repository
> [artifact:dependencies] Transferring 31K from wyona.remote.repository
> [artifact:dependencies] Downloading:
> avalon-framework/avalon-framework-impl/4.3/avalon-framework-impl-4.3.jar
> from wyona.remote.repository
> [artifact:dependencies] Transferring 58K from wyona.remote.repository
>
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakart=
a-commons-discovery-0.2.jar
> from wyona.remote.repository
> [artifact:dependencies] Transferring 70K from wyona.remote.repository
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache=
-jakarta-commons-id-0.1-dev-lcr357257.jar
> from wyona.remote.repository
> [artifact:dependencies] Transferring 53K from wyona.remote.repository
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakart=
a-commons-logging-1.0.4.jar
> from wyona.remote.repository
> [artifact:dependencies] Transferring 37K from wyona.remote.repository
> [artifact:dependencies] Downloading:
> apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commo=
ns-io-1.2.jar
> from wyona.remote.repository
>
> which means apache-jakarta-commons-io-1.2 is referenced from within
>
> https://svn.wyona.com/repos/public/security/trunk/dependencies.xml
>

yes, this seems to be (one of) the "incorrect" references, if we want to
follow the maven best practices


>
> Now we can start cleaning, whereas the question is which one we want to
> clean and I am concerned that there will be more
> such cases ...
>

I suspect the following as also being non-standard:

apache-jakarta-commons-discovery:
(http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-discovery/commons-di=
scovery/maven-metadata.xml)
apache-jakarta-commons-id:
(http://svn.apache.org/repos/asf/commons/sandbox/id/trunk/pom.xml)
apache-jakarta-commons-logging:
(http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-logging/commons-logg=
ing/maven-metadata.xml)

Of the files above, commons-discovery and commons-logging are downloaded
twice (like commons-io) while commons-id is only downloaded once (but to the
"wrong" path in the maven repository).

Shall I continue looking for inconsistencies? (There is also the grep output
of the src directory below to consider, I think there are a lot of "wrong"
references that might still download to this second location if we correct
the ref in wyona-org-security-core-0.2-dev-r48408.pom) The sure way to clean
this all up would probably be to go through the ~/.m2 directory and check
for each artifact if it is in the proper place, wdyt?

Cheers,

Memo



> Cheers
>
> Michi
>
> Mehmet Birgi wrote:
>
>> What I could find out so far:
>>
>> 1. The correct artifact-id is "commons-io", according to the Maven docs,
>> that point to ibiblio.org/maven2 <http://ibiblio.org/maven2> as the
>> reference (
>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/mave=
n-metadata.xml
>> )
>>
>>
>> 2. I have found a reference to the "incorrect" artifact-id,
>> "apache-jakarta-commons-io", but there seem to be several others too:
>>
>> memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>> apache-jakarta-commons-io src | grep -v '/\.svn/' | grep -v '\.yarep/'
>> src/build/dependencies.xml:      <dependency
>> groupId=3D"apache-jakarta-commons" artifactId=3D"apache-jakarta-commons-=
io"
>> src/contributions/resources/xinha/src/build/dependencies.xml:
>>  <dependency groupId=3D"apache-jakarta-commons"
>> artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>> src/realms/welcome-admin/yanel/resources/update-webapp/src/build/depende=
ncies.xml:
>>      <dependency groupId=3D"apache-jakarta-commons"
>> artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>> src/resources/add-realm/src/build/dependencies.xml:      <dependency
>> groupId=3D"apache-jakarta-commons" artifactId=3D"apache-jakarta-commons-=
io"
>> version=3D"1.2"/>
>> src/resources/testing-control/src/build/dependencies.xml:      <dependen=
cy
>> groupId=3D"apache-jakarta-commons" artifactId=3D"apache-jakarta-commons-=
io"
>> version=3D"1.2"/>
>> src/resources/tinymce/src/build/dependencies.xml:      <dependency
>> groupId=3D"apache-jakarta-commons" artifactId=3D"apache-jakarta-commons-=
io"
>> version=3D"1.2"/>
>> src/resources/xml/src/build/dependencies.xml:      <dependency
>> groupId=3D"apache-jakarta-commons" artifactId=3D"apache-jakarta-commons-=
io"
>> version=3D"1.2"/>
>> src/test/build.xml:      <dependency groupId=3D"apache-jakarta-commons"
>> artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>
>>
>> I am attaching the new build.log after deleting ~/.m2 to this mail, I
>> couldn't gain any new insights from it, but I will gladly pursue any fur=
ther
>> hints.
>>
>> That's it for now, cheers & good night
>>
>> Memo
>>
>>
>>
>>
>>
>> On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner <
>> michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>>
>>    From your log-file it seems that these libraries are downloaded at
>>    the very beginning of the build:
>>
>>    Apache Ant version 1.7.1 compiled on June 27 2008
>>    INFO: Building Yanel...
>>    Buildfile: src/build/build.xml
>>
>>    init:
>>       [echo] INFO: Building with Apache Ant version 1.7.1 compiled on
>>    June 27 2008 and Java version 1.6
>>       [echo] Yanel Home Dir:
>>    /Users/memo/Wyona/Work/Yanel/src/build/../../
>>
>>    probe-proxy:
>>       [echo] Check if proxy has been set ...
>>
>>    proxy:
>>
>>
>>    dependencies:
>>    [artifact:dependencies] Downloading:
>>    commons-io/commons-io/1.2/commons-io-1.2.pom from
>>    wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>    commons-io/commons-io/1.2/commons-io-1.2.pom from central
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.pom
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 0K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.pom
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 0K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.pom
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 0K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.pom
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 0K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>    commons-io/commons-io/1.2/commons-io-1.2.jar from
>>    wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>    commons-io/commons-io/1.2/commons-io-1.2.jar from central
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.jar
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 70K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.jar
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 53K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.jar
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 37K from wyona.remote.repository
>>    [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.jar
>>    from wyona.remote.repository
>>    [artifact:dependencies] Transferring 64K from wyona.remote.repository
>>      [unzip] Expanding:
>>    /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into
>>    /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>>
>>
>>    Now one has to analyze why. I guess the easiest is to delete the
>>    whole local Maven repo and build/log again and then analyze it
>>    again. (I assume you just deleted this libs instead the whole
>>    local repo, right?)
>>
>>    Thanks
>>
>>    Michi
>>
>>    Mehmet Birgi wrote:
>>
>>        Hi Michael
>>
>>
>>        On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com
>>        <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>>
>>        <mailto:bugzilla@wyona.com>>> wrote:
>>
>>           http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7=
551
>>
>>
>>           michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>        <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>> changed:
>>
>>
>>                     What    |Removed                     |Added
>>
>>  -----------------------------------------------------------------------=
-----
>>                   AssignedTo|michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>           <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>   |mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>
>>           <mailto:mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>>
>>
>>
>>
>>
>>
>>           ------- Comment #3 from michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>           <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>  2010-04-06 14:48 -------
>>
>>           It would be important that you add the piece of the log
>>        file where
>>           one can see
>>           from where the Maven download is actually started. Right
>>        now one
>>           can only see,
>>           that it is downloaded, but not which resource or realm or
>>           component is actually
>>           triggering the download
>>
>>
>>        I am not sure I understand what you mean, I have attached the
>>        whole log file, can you point me to the proper entries? Maybe
>>        this information is not logged?
>>
>>        Thanks,
>>
>>        Memo
>>
>>
>>
>>
>>           --
>>           Configure bugmail:
>>
>> http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=3Demail
>>           ------- You are receiving this mail because: -------
>>           You are the QA contact for the bug, or are watching the QA
>>        contact.
>>           --
>>           Yanel-development mailing list Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>
>>           <mailto:Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>>
>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>        --         Mehmet Birgi
>>        www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>
>>    --     Yanel-development mailing list Yanel-development@wyona.com
>>    <mailto:Yanel-development@wyona.com>
>>    http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
7/9ef98ff2/attachment-0001.htm
From bruno.vonrotz at wyona.com  Wed Apr  7 10:50:33 2010
From: bruno.vonrotz at wyona.com (Bruno von Rotz)
Date: Wed Apr  7 11:03:58 2010
Subject: [Yanel-dev] Login Zone Link
In-Reply-To: <4BBC4413.6090305@wyona.com>
References: <4BB3D12A.3000702@wyona.com> <4BBC4413.6090305@wyona.com>
Message-ID: <4BBC4759.7060503@wyona.com>

Cool. Given this is JS, would this mean it's only visible for human 
users, not for bots and other "non-wanted" visitors? Bruno
Michael Wechner schrieb:
> Hi
>
> I have slightly improved this by moving the code into various 
> core-webapp files such that it can be re-used more easier.
> In order to use it within your own website/realm one can reference it 
> from the XHTML head
>
>
> <head>
>        <!-- Yanel toolbar zone -->
>        <script type="text/javascript" 
> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/jquery/1.2.6/jquery.min.js"></script> 
>
>        <script type="text/javascript" 
> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/toolbar-zone.js"></script> 
>
>        <link media="screen" type="text/css" 
> href="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-css/toolbar-zone.css" 
> rel="stylesheet"/>
>
>      </head>
>
> and add it to the body as
>
>      <body>
> <xsl:if test="$yanel.toolbar-status = 'off'">
> <div id="yanelToolbarZone">
>  <div id="yanelToolbarZoneLink" style="display: none; height: 60px; 
> width: 60px;">
>    <a href="?yanel.toolbar=on" title="Turn on Toolbar" alt="Turn on 
> Toolbar"><img style="position: absolute; right:5px; top:5px;" 
> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-img/yanel_kangaroo.png" 
> height="48" width="109" border="0"/></a>
>  </div>
> </div>
> </xsl:if>
>
> Also we have added a new smaller logo displaying our new kangaroo.
>
> Cheers
>
> Michi
>
> Michael Wechner wrote:
>> Hi
>>
>> I have added a login-zone-link to the from scratch realm, which means 
>> if you hover with the mouse at
>> the upper right corner of your browser, then an image will appear 
>> saying "Login" and allows the user
>> to click in order to get to the login screen.
>>
>> I think this is a very nice for people familiar with Yanel to find 
>> the login page without having to make
>> a link available or remember some hidden URL.
>>
>> Please give it a try and let me know what you think
>>
>> Thanks
>>
>> Michi
>


-- 
______________________________
Bruno von Rotz
WYONA
Hardstrasse 219 
CH-8005 Z?rich 
Switzerland 
P: +41 44 272 91 61 
F: +41 44 272 91 62 
skype: wyona-switzerland
email: bruno.vonrotz@wyona.com
www.wyona.com 

From michael.wechner at wyona.com  Wed Apr  7 11:27:52 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 11:43:27 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>	<4BBB47B4.8020302@wyona.com>	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>	<4BBC327B.1070305@wyona.com>
	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
Message-ID: <4BBC5018.2080506@wyona.com>

Mehmet Birgi wrote:
> Re which one to use: in the maven documentation, it is suggested 
> (http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_external_dependencies, 
> 7. paragraph) that one use http://ibiblio.org/maven2 as a reference to 
> what the artifact id should be for any (apache) dependency. According 
> to that, we should use "commons-io", rather than 
> "apache-jakarta-commons-io". 

ibiblio is just one of the many Maven repositories. I think we need to 
approach this slightly different. First  we should check if these
libs are really the same. One first simple check is to open the jar 
files and compare:

jar -tf 
/Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar

another simple one is to count the number of files

jar -tf 
/Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar 
| wc -l

and another is to compare the size

ls -l 
/Users/michaelwechner/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar

and yes it really seems that these are the same libs -;-)

Yes,  ibiblio contains

http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/

but does not contain apache-jakarta-commons.

Also commons is an ex-subproject of the jakarta project

http://jakarta.apache.org/

which is now

http://commons.apache.org/io/
http://commons.apache.org/io/download_io.cgi
http://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-1.4/pom.xml

so based on this I would agree to replace the apache-jakarta-commons-io  
by commons-io.

I have done this now at

https://svn.wyona.com/repos/public/yanel/trunk/src/build/dependencies.xml

and

https://svn.wyona.com/repos/public/security/trunk/dependencies.xml



> So I would suggest that we change all the dependencies referring to 
> "apache-jakarta-commons-io" to refer to "commons-io". Is that OK, or 
> are there other things to consider? If you agree, I will try to find 
> out if this is documented somewhere, and if not, add it to the best 
> practices, OK?

I am not sure if the best practices are the best place for this, but I 
guess it's better to add it there than nowhere
>
>
>   
> Of the files above, commons-discovery and commons-logging are 
> downloaded twice (like commons-io) while commons-id is only downloaded 
> once (but to the "wrong" path in the maven repository).
>
> Shall I continue looking for inconsistencies? (There is also the grep 
> output of the src directory below to consider, I think there are a lot 
> of "wrong" references that might still download to this second 
> location if we correct the ref in 
> wyona-org-security-core-0.2-dev-r48408.pom) The sure way to clean this 
> all up would probably be to go through the ~/.m2 directory and check 
> for each artifact if it is in the proper place, wdyt?

I think we should do it incrementally. If we find something, then let's 
replace, otherwise it doesn't hurt.

Re commons-logging and the others we need to first check if these are 
really the same libs. Have you done this?

Thanks

Michi


>
> Cheers,
>
> Memo
>
>
>
>     Cheers
>
>     Michi
>
>     Mehmet Birgi wrote:
>
>         What I could find out so far:
>
>         1. The correct artifact-id is "commons-io", according to the
>         Maven docs, that point to ibiblio.org/maven2
>         <http://ibiblio.org/maven2> <http://ibiblio.org/maven2> as the
>         reference
>         (http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/maven-metadata.xml)
>
>
>
>         2. I have found a reference to the "incorrect" artifact-id,
>         "apache-jakarta-commons-io", but there seem to be several
>         others too:
>
>         memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>         apache-jakarta-commons-io src | grep -v '/\.svn/' | grep -v
>         '\.yarep/'
>         src/build/dependencies.xml:      <dependency
>         groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io"
>         src/contributions/resources/xinha/src/build/dependencies.xml:
>              <dependency groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/realms/welcome-admin/yanel/resources/update-webapp/src/build/dependencies.xml:
>              <dependency groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/resources/add-realm/src/build/dependencies.xml:    
>          <dependency groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/resources/testing-control/src/build/dependencies.xml:    
>          <dependency groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/resources/tinymce/src/build/dependencies.xml:    
>          <dependency groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/resources/xml/src/build/dependencies.xml:      <dependency
>         groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>         src/test/build.xml:      <dependency
>         groupId="apache-jakarta-commons"
>         artifactId="apache-jakarta-commons-io" version="1.2"/>
>
>
>         I am attaching the new build.log after deleting ~/.m2 to this
>         mail, I couldn't gain any new insights from it, but I will
>         gladly pursue any further hints.
>
>         That's it for now, cheers & good night
>
>         Memo
>
>
>
>
>
>         On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner
>         <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>
>         <mailto:michael.wechner@wyona.com
>         <mailto:michael.wechner@wyona.com>>> wrote:
>
>            From your log-file it seems that these libraries are
>         downloaded at
>            the very beginning of the build:
>
>            Apache Ant version 1.7.1 compiled on June 27 2008
>            INFO: Building Yanel...
>            Buildfile: src/build/build.xml
>
>            init:
>               [echo] INFO: Building with Apache Ant version 1.7.1
>         compiled on
>            June 27 2008 and Java version 1.6
>               [echo] Yanel Home Dir:
>            /Users/memo/Wyona/Work/Yanel/src/build/../../
>
>            probe-proxy:
>               [echo] Check if proxy has been set ...
>
>            proxy:
>
>
>            dependencies:
>            [artifact:dependencies] Downloading:
>            commons-io/commons-io/1.2/commons-io-1.2.pom from
>            wyona.remote.repository
>            [artifact:dependencies] Downloading:
>            commons-io/commons-io/1.2/commons-io-1.2.pom from central
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 0K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 0K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 0K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.pom
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 0K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>            commons-io/commons-io/1.2/commons-io-1.2.jar from
>            wyona.remote.repository
>            [artifact:dependencies] Downloading:
>            commons-io/commons-io/1.2/commons-io-1.2.jar from central
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 70K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 53K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 37K from
>         wyona.remote.repository
>            [artifact:dependencies] Downloading:
>          
>          apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>            from wyona.remote.repository
>            [artifact:dependencies] Transferring 64K from
>         wyona.remote.repository
>              [unzip] Expanding:
>          
>          /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into
>          
>          /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>
>
>            Now one has to analyze why. I guess the easiest is to
>         delete the
>            whole local Maven repo and build/log again and then analyze it
>            again. (I assume you just deleted this libs instead the whole
>            local repo, right?)
>
>            Thanks
>
>            Michi
>
>            Mehmet Birgi wrote:
>
>                Hi Michael
>
>
>                On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com
>         <mailto:bugzilla@wyona.com>
>                <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>>
>         <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>
>
>                <mailto:bugzilla@wyona.com
>         <mailto:bugzilla@wyona.com>>>> wrote:
>
>                  
>         http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551
>
>
>                   michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>> changed:
>
>
>                             What    |Removed                     |Added
>                        
>          ----------------------------------------------------------------------------
>                           AssignedTo|michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>
>                   <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>>   |mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>
>                <mailto:mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>>
>                   <mailto:mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>
>                <mailto:mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>>>
>
>
>
>
>
>                   ------- Comment #3 from michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>
>                   <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>
>                <mailto:michael.wechner@wyona.org
>         <mailto:michael.wechner@wyona.org>>>  2010-04-06 14:48 -------
>
>                   It would be important that you add the piece of the log
>                file where
>                   one can see
>                   from where the Maven download is actually started. Right
>                now one
>                   can only see,
>                   that it is downloaded, but not which resource or
>         realm or
>                   component is actually
>                   triggering the download
>
>
>                I am not sure I understand what you mean, I have
>         attached the
>                whole log file, can you point me to the proper entries?
>         Maybe
>                this information is not logged?
>
>                Thanks,
>
>                Memo
>
>
>                
>
>                   --
>                   Configure bugmail:
>                        
>          http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
>                   ------- You are receiving this mail because: -------
>                   You are the QA contact for the bug, or are watching
>         the QA
>                contact.
>                   --
>                   Yanel-development mailing list
>         Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>                <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>>
>                   <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>
>                <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>>>
>
>                        
>          http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>                --         Mehmet Birgi
>                www.wyona.com <http://www.wyona.com>
>         <http://www.wyona.com> <http://www.wyona.com>
>
>
>
>            --     Yanel-development mailing list
>         Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>            <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>>
>          
>          http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>         -- 
>         Mehmet Birgi
>         www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From michael.wechner at wyona.com  Wed Apr  7 11:44:46 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 11:58:08 2010
Subject: [Yanel-dev] Login Zone Link
In-Reply-To: <4BBC4759.7060503@wyona.com>
References: <4BB3D12A.3000702@wyona.com> <4BBC4413.6090305@wyona.com>
	<4BBC4759.7060503@wyona.com>
Message-ID: <4BBC540E.1030008@wyona.com>

Bruno von Rotz wrote:
> Cool. Given this is JS, would this mean it's only visible for human 
> users, not for bots and other "non-wanted" visitors? 

yes, except the bot is javascript enabled.

Cheers

Michi


> Bruno
> Michael Wechner schrieb:
>> Hi
>>
>> I have slightly improved this by moving the code into various 
>> core-webapp files such that it can be re-used more easier.
>> In order to use it within your own website/realm one can reference it 
>> from the XHTML head
>>
>>
>> <head>
>>        <!-- Yanel toolbar zone -->
>>        <script type="text/javascript" 
>> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/jquery/1.2.6/jquery.min.js"></script> 
>>
>>        <script type="text/javascript" 
>> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-js/toolbar-zone.js"></script> 
>>
>>        <link media="screen" type="text/css" 
>> href="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-css/toolbar-zone.css" 
>> rel="stylesheet"/>
>>
>>      </head>
>>
>> and add it to the body as
>>
>>      <body>
>> <xsl:if test="$yanel.toolbar-status = 'off'">
>> <div id="yanelToolbarZone">
>>  <div id="yanelToolbarZoneLink" style="display: none; height: 60px; 
>> width: 60px;">
>>    <a href="?yanel.toolbar=on" title="Turn on Toolbar" alt="Turn on 
>> Toolbar"><img style="position: absolute; right:5px; top:5px;" 
>> src="{$yarep.back2realm}{$yanel.reservedPrefix}/yanel-img/yanel_kangaroo.png" 
>> height="48" width="109" border="0"/></a>
>>  </div>
>> </div>
>> </xsl:if>
>>
>> Also we have added a new smaller logo displaying our new kangaroo.
>>
>> Cheers
>>
>> Michi
>>
>> Michael Wechner wrote:
>>> Hi
>>>
>>> I have added a login-zone-link to the from scratch realm, which 
>>> means if you hover with the mouse at
>>> the upper right corner of your browser, then an image will appear 
>>> saying "Login" and allows the user
>>> to click in order to get to the login screen.
>>>
>>> I think this is a very nice for people familiar with Yanel to find 
>>> the login page without having to make
>>> a link available or remember some hidden URL.
>>>
>>> Please give it a try and let me know what you think
>>>
>>> Thanks
>>>
>>> Michi
>>
>
>

From mehmet.birgi at wyona.com  Wed Apr  7 11:48:09 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr  7 12:01:39 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <4BBC5018.2080506@wyona.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
	<4BBC327B.1070305@wyona.com>
	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
	<4BBC5018.2080506@wyona.com>
Message-ID: <h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>

On Wed, Apr 7, 2010 at 11:27 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>> Re which one to use: in the maven documentation, it is suggested (
>> http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_e=
xternal_dependencies,
>> 7. paragraph) that one use http://ibiblio.org/maven2 as a reference to
>> what the artifact id should be for any (apache) dependency. According to
>> that, we should use "commons-io", rather than "apache-jakarta-commons-io=
".
>>
>
> ibiblio is just one of the many Maven repositories. I think we need to
> approach this slightly different. First  we should check if these
> libs are really the same. One first simple check is to open the jar files
> and compare:
>
> jar -tf
> /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakart=
a-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>
> another simple one is to count the number of files
>
> jar -tf
> /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakart=
a-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
> | wc -l
>
> and another is to compare the size
>
> ls -l
> /Users/michaelwechner/.m2/repository/commons-io/commons-io/1.2/commons-io=
-1.2.jar
>
> and yes it really seems that these are the same libs -;-)
>
> Yes,  ibiblio contains
>
>
> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/
>
> but does not contain apache-jakarta-commons.
>
> Also commons is an ex-subproject of the jakarta project
>
> http://jakarta.apache.org/
>
> which is now
>
> http://commons.apache.org/io/
> http://commons.apache.org/io/download_io.cgi
>
> http://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-1.4/pom=
.xml
>
> so based on this I would agree to replace the apache-jakarta-commons-io  =
by
> commons-io.
>
> I have done this now at
>
> https://svn.wyona.com/repos/public/yanel/trunk/src/build/dependencies.xml
>
> and
>
>
> https://svn.wyona.com/repos/public/security/trunk/dependencies.xml
>

Thanks


>
>
>
>  So I would suggest that we change all the dependencies referring to
>> "apache-jakarta-commons-io" to refer to "commons-io". Is that OK, or are
>> there other things to consider? If you agree, I will try to find out if =
this
>> is documented somewhere, and if not, add it to the best practices, OK?
>>
>
> I am not sure if the best practices are the best place for this, but I
> guess it's better to add it there than nowhere


We could add it here:
http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=3DCodingGuidelines
or better make a new page "MavenGuidelines", add it there, and link to it
from here: http://documentation.yanel.wyona.org/wiki/wiki/Guidelines

wdyt?



>
>>
>>  Of the files above, commons-discovery and commons-logging are downloaded
>> twice (like commons-io) while commons-id is only downloaded once (but to=
 the
>> "wrong" path in the maven repository).
>>
>> Shall I continue looking for inconsistencies? (There is also the grep
>> output of the src directory below to consider, I think there are a lot of
>> "wrong" references that might still download to this second location if =
we
>> correct the ref in wyona-org-security-core-0.2-dev-r48408.pom) The sure =
way
>> to clean this all up would probably be to go through the ~/.m2 directory=
 and
>> check for each artifact if it is in the proper place, wdyt?
>>
>
> I think we should do it incrementally. If we find something, then let's
> replace, otherwise it doesn't hurt.
>
> Re commons-logging and the others we need to first check if these are
> really the same libs. Have you done this?
>

no, i will check those and report back

Thanks,

memo



>
> Thanks
>
> Michi
>
>
>
>> Cheers,
>>
>> Memo
>>
>>
>>
>>    Cheers
>>
>>    Michi
>>
>>    Mehmet Birgi wrote:
>>
>>        What I could find out so far:
>>
>>        1. The correct artifact-id is "commons-io", according to the
>>        Maven docs, that point to ibiblio.org/maven2
>>        <http://ibiblio.org/maven2> <http://ibiblio.org/maven2> as the
>>
>>        reference
>>        (
>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/mave=
n-metadata.xml
>> )
>>
>>
>>
>>        2. I have found a reference to the "incorrect" artifact-id,
>>        "apache-jakarta-commons-io", but there seem to be several
>>        others too:
>>
>>        memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>>        apache-jakarta-commons-io src | grep -v '/\.svn/' | grep -v
>>        '\.yarep/'
>>        src/build/dependencies.xml:      <dependency
>>        groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io"
>>        src/contributions/resources/xinha/src/build/dependencies.xml:
>>             <dependency groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>
>>  src/realms/welcome-admin/yanel/resources/update-webapp/src/build/depend=
encies.xml:
>>             <dependency groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>        src/resources/add-realm/src/build/dependencies.xml:
>> <dependency groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>        src/resources/testing-control/src/build/dependencies.xml:
>>   <dependency groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>        src/resources/tinymce/src/build/dependencies.xml:
>> <dependency groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>        src/resources/xml/src/build/dependencies.xml:      <dependency
>>        groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>        src/test/build.xml:      <dependency
>>        groupId=3D"apache-jakarta-commons"
>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>
>>
>>        I am attaching the new build.log after deleting ~/.m2 to this
>>        mail, I couldn't gain any new insights from it, but I will
>>        gladly pursue any further hints.
>>
>>        That's it for now, cheers & good night
>>
>>        Memo
>>
>>
>>
>>
>>
>>        On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner
>>        <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>
>>        <mailto:michael.wechner@wyona.com
>>        <mailto:michael.wechner@wyona.com>>> wrote:
>>
>>           From your log-file it seems that these libraries are
>>        downloaded at
>>           the very beginning of the build:
>>
>>           Apache Ant version 1.7.1 compiled on June 27 2008
>>           INFO: Building Yanel...
>>           Buildfile: src/build/build.xml
>>
>>           init:
>>              [echo] INFO: Building with Apache Ant version 1.7.1
>>        compiled on
>>           June 27 2008 and Java version 1.6
>>              [echo] Yanel Home Dir:
>>           /Users/memo/Wyona/Work/Yanel/src/build/../../
>>
>>           probe-proxy:
>>              [echo] Check if proxy has been set ...
>>
>>           proxy:
>>
>>
>>           dependencies:
>>           [artifact:dependencies] Downloading:
>>           commons-io/commons-io/1.2/commons-io-1.2.pom from
>>           wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>           commons-io/commons-io/1.2/commons-io-1.2.pom from central
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.pom
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 0K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.pom
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 0K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.pom
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 0K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.pom
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 0K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>           commons-io/commons-io/1.2/commons-io-1.2.jar from
>>           wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>           commons-io/commons-io/1.2/commons-io-1.2.jar from central
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.jar
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 70K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.jar
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 53K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.jar
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 37K from
>>        wyona.remote.repository
>>           [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.jar
>>           from wyona.remote.repository
>>           [artifact:dependencies] Transferring 64K from
>>        wyona.remote.repository
>>             [unzip] Expanding:
>>
>>  /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into
>>
>>  /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>>
>>
>>           Now one has to analyze why. I guess the easiest is to
>>        delete the
>>           whole local Maven repo and build/log again and then analyze it
>>           again. (I assume you just deleted this libs instead the whole
>>           local repo, right?)
>>
>>           Thanks
>>
>>           Michi
>>
>>           Mehmet Birgi wrote:
>>
>>               Hi Michael
>>
>>
>>               On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com
>>        <mailto:bugzilla@wyona.com>
>>               <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>>
>>        <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>
>>
>>               <mailto:bugzilla@wyona.com
>>        <mailto:bugzilla@wyona.com>>>> wrote:
>>
>>
>> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7551
>>
>>
>>                  michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>> changed:
>>
>>
>>                            What    |Removed                     |Added
>>
>>  -----------------------------------------------------------------------=
-----
>>                          AssignedTo|michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>
>>                  <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>>   |mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>
>>               <mailto:mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>>
>>                  <mailto:mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>
>>               <mailto:mehmet.birgi@wyona.com
>>        <mailto:mehmet.birgi@wyona.com>>>
>>
>>
>>
>>
>>
>>                  ------- Comment #3 from michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>
>>                  <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>
>>               <mailto:michael.wechner@wyona.org
>>        <mailto:michael.wechner@wyona.org>>>  2010-04-06 14:48 -------
>>
>>                  It would be important that you add the piece of the log
>>               file where
>>                  one can see
>>                  from where the Maven download is actually started. Right
>>               now one
>>                  can only see,
>>                  that it is downloaded, but not which resource or
>>        realm or
>>                  component is actually
>>                  triggering the download
>>
>>
>>               I am not sure I understand what you mean, I have
>>        attached the
>>               whole log file, can you point me to the proper entries?
>>        Maybe
>>               this information is not logged?
>>
>>               Thanks,
>>
>>               Memo
>>
>>
>>
>>                  --
>>                  Configure bugmail:
>>
>> http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=3Demail
>>                  ------- You are receiving this mail because: -------
>>                  You are the QA contact for the bug, or are watching
>>        the QA
>>               contact.
>>                  --
>>                  Yanel-development mailing list
>>        Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>>               <mailto:Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>>
>>                  <mailto:Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>
>>               <mailto:Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>>>
>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>               --         Mehmet Birgi
>>               www.wyona.com <http://www.wyona.com>
>>        <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>
>>           --     Yanel-development mailing list
>>        Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>>           <mailto:Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>        --         Mehmet Birgi
>>        www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>    --     Yanel-development mailing list Yanel-development@wyona.com
>>    <mailto:Yanel-development@wyona.com>
>>    http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
7/859f8f2e/attachment-0001.htm
From michael.wechner at wyona.com  Wed Apr  7 11:57:16 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 12:10:51 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>	<4BBB47B4.8020302@wyona.com>	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>	<4BBC327B.1070305@wyona.com>	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>	<4BBC5018.2080506@wyona.com>
	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
Message-ID: <4BBC56FC.6070400@wyona.com>

Mehmet Birgi wrote:
>
>
>
>
> We could add it here: 
> http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=CodingGuidelines
> or better make a new page "MavenGuidelines", add it there, and link to 
> it from here: http://documentation.yanel.wyona.org/wiki/wiki/Guidelines
>
> wdyt?
>

whatever you think it's best

Thanks

Michi
From mehmet.birgi at wyona.com  Wed Apr  7 14:24:44 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr  7 14:38:27 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <4BBC56FC.6070400@wyona.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
	<4BBC327B.1070305@wyona.com>
	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
	<4BBC5018.2080506@wyona.com>
	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
	<4BBC56FC.6070400@wyona.com>
Message-ID: <l2u5bf1397d1004070524o772d0949qd0c62b40d7a99cd9@mail.gmail.com>

I have made a page "Maven Guidelines":
http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=3DMavenGuidelines

(it is linked from here:
http://documentation.yanel.wyona.org/wiki/wiki/Guidelines)

Cheers,

memo


On Wed, Apr 7, 2010 at 11:57 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>>
>>
>>
>>
>> We could add it here:
>> http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=3DCodingGuidelines
>> or better make a new page "MavenGuidelines", add it there, and link to it
>> from here: http://documentation.yanel.wyona.org/wiki/wiki/Guidelines
>>
>> wdyt?
>>
>>
> whatever you think it's best
>
> Thanks
>
> Michi
>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
7/2df58f69/attachment.htm
From mehmet.birgi at wyona.com  Wed Apr  7 14:55:34 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr  7 15:09:13 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
	<4BBC327B.1070305@wyona.com>
	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
	<4BBC5018.2080506@wyona.com>
	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
Message-ID: <l2w5bf1397d1004070555g571370fw99344b81ad5b599@mail.gmail.com>

I did some more checks for the other duplicates. It looks like we have 5
different versions of commons-logging in our repository, one of them twice:

$ find ~/.m2/repository/ -type f | grep "commons-logging"
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-l=
ogging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-l=
ogging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar.md5
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-l=
ogging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-l=
ogging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom.md5
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-log=
ging-1.0.pom
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-log=
ging-1.0.pom.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/commons-l=
ogging-1.0.3.pom
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/commons-l=
ogging-1.0.3.pom.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-l=
ogging-1.0.4.jar
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-l=
ogging-1.0.4.jar.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-l=
ogging-1.0.4.pom
/Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-l=
ogging-1.0.4.pom.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-log=
ging-1.1.jar
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-log=
ging-1.1.jar.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-log=
ging-1.1.pom
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-log=
ging-1.1.pom.sha1
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/commons-l=
ogging-1.1.1.pom
/Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/commons-l=
ogging-1.1.1.pom.sha1

Is it necessary to have so many versions? At least the 2 1.0.4 versions seem
to be the same (checked jar file contents).

commons-discovery is also included twice (they are identical):

$ find ~/.m2/repository/ -type f | grep
"commons-discovery"/Users/memo/.m2/repository//apache-jakarta-commons/apach=
e-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-d=
iscovery/0.2/apache-jakarta-commons-discovery-0.2.jar.md5
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-d=
iscovery/0.2/apache-jakarta-commons-discovery-0.2.pom
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-d=
iscovery/0.2/apache-jakarta-commons-discovery-0.2.pom.md5
/Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons=
-discovery-0.2.jar
/Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons=
-discovery-0.2.jar.sha1
/Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons=
-discovery-0.2.pom
/Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons=
-discovery-0.2.pom.sha1

while commons-id is there only once, but with the jakarta-groupId:

$ find ~/.m2/repository/ -type f | grep "commons-id"
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-i=
d/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-i=
d/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar.md5
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-i=
d/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-i=
d/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom.md5

Shall we continue with the cleaning now, or just put this info into bugzilla
for later?

Thanks,

memo






On Wed, Apr 7, 2010 at 11:48 AM, Mehmet Birgi <mehmet.birgi@wyona.com>wrote:

>
>
> On Wed, Apr 7, 2010 at 11:27 AM, Michael Wechner <
> michael.wechner@wyona.com> wrote:
>
>> Mehmet Birgi wrote:
>>
>>> Re which one to use: in the maven documentation, it is suggested (
>>> http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_=
external_dependencies,
>>> 7. paragraph) that one use http://ibiblio.org/maven2 as a reference to
>>> what the artifact id should be for any (apache) dependency. According to
>>> that, we should use "commons-io", rather than "apache-jakarta-commons-i=
o".
>>>
>>
>> ibiblio is just one of the many Maven repositories. I think we need to
>> approach this slightly different. First  we should check if these
>> libs are really the same. One first simple check is to open the jar files
>> and compare:
>>
>> jar -tf
>> /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakar=
ta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>>
>> another simple one is to count the number of files
>>
>> jar -tf
>> /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakar=
ta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>> | wc -l
>>
>> and another is to compare the size
>>
>> ls -l
>> /Users/michaelwechner/.m2/repository/commons-io/commons-io/1.2/commons-i=
o-1.2.jar
>>
>> and yes it really seems that these are the same libs -;-)
>>
>> Yes,  ibiblio contains
>>
>>
>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/
>>
>> but does not contain apache-jakarta-commons.
>>
>> Also commons is an ex-subproject of the jakarta project
>>
>> http://jakarta.apache.org/
>>
>> which is now
>>
>> http://commons.apache.org/io/
>> http://commons.apache.org/io/download_io.cgi
>>
>> http://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-1.4/po=
m.xml
>>
>> so based on this I would agree to replace the apache-jakarta-commons-io
>>  by commons-io.
>>
>> I have done this now at
>>
>> https://svn.wyona.com/repos/public/yanel/trunk/src/build/dependencies.xml
>>
>> and
>>
>>
>> https://svn.wyona.com/repos/public/security/trunk/dependencies.xml
>>
>
> Thanks
>
>
>>
>>
>>
>>  So I would suggest that we change all the dependencies referring to
>>> "apache-jakarta-commons-io" to refer to "commons-io". Is that OK, or are
>>> there other things to consider? If you agree, I will try to find out if=
 this
>>> is documented somewhere, and if not, add it to the best practices, OK?
>>>
>>
>> I am not sure if the best practices are the best place for this, but I
>> guess it's better to add it there than nowhere
>
>
> We could add it here:
> http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=3DCodingGuidelines
> or better make a new page "MavenGuidelines", add it there, and link to it
> from here: http://documentation.yanel.wyona.org/wiki/wiki/Guidelines
>
> wdyt?
>
>
>
>>
>>>
>>>  Of the files above, commons-discovery and commons-logging are download=
ed
>>> twice (like commons-io) while commons-id is only downloaded once (but t=
o the
>>> "wrong" path in the maven repository).
>>>
>>> Shall I continue looking for inconsistencies? (There is also the grep
>>> output of the src directory below to consider, I think there are a lot =
of
>>> "wrong" references that might still download to this second location if=
 we
>>> correct the ref in wyona-org-security-core-0.2-dev-r48408.pom) The sure=
 way
>>> to clean this all up would probably be to go through the ~/.m2 director=
y and
>>> check for each artifact if it is in the proper place, wdyt?
>>>
>>
>> I think we should do it incrementally. If we find something, then let's
>> replace, otherwise it doesn't hurt.
>>
>> Re commons-logging and the others we need to first check if these are
>> really the same libs. Have you done this?
>>
>
> no, i will check those and report back
>
> Thanks,
>
> memo
>
>
>
>>
>> Thanks
>>
>> Michi
>>
>>
>>
>>> Cheers,
>>>
>>> Memo
>>>
>>>
>>>
>>>    Cheers
>>>
>>>    Michi
>>>
>>>    Mehmet Birgi wrote:
>>>
>>>        What I could find out so far:
>>>
>>>        1. The correct artifact-id is "commons-io", according to the
>>>        Maven docs, that point to ibiblio.org/maven2
>>>        <http://ibiblio.org/maven2> <http://ibiblio.org/maven2> as the
>>>
>>>        reference
>>>        (
>>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/mav=
en-metadata.xml
>>> )
>>>
>>>
>>>
>>>        2. I have found a reference to the "incorrect" artifact-id,
>>>        "apache-jakarta-commons-io", but there seem to be several
>>>        others too:
>>>
>>>        memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>>>        apache-jakarta-commons-io src | grep -v '/\.svn/' | grep -v
>>>        '\.yarep/'
>>>        src/build/dependencies.xml:      <dependency
>>>        groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io"
>>>        src/contributions/resources/xinha/src/build/dependencies.xml:
>>>             <dependency groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>
>>>  src/realms/welcome-admin/yanel/resources/update-webapp/src/build/depen=
dencies.xml:
>>>             <dependency groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>        src/resources/add-realm/src/build/dependencies.xml:
>>> <dependency groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>        src/resources/testing-control/src/build/dependencies.xml:
>>>     <dependency groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>        src/resources/tinymce/src/build/dependencies.xml:
>>> <dependency groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>        src/resources/xml/src/build/dependencies.xml:      <dependency
>>>        groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>        src/test/build.xml:      <dependency
>>>        groupId=3D"apache-jakarta-commons"
>>>        artifactId=3D"apache-jakarta-commons-io" version=3D"1.2"/>
>>>
>>>
>>>        I am attaching the new build.log after deleting ~/.m2 to this
>>>        mail, I couldn't gain any new insights from it, but I will
>>>        gladly pursue any further hints.
>>>
>>>        That's it for now, cheers & good night
>>>
>>>        Memo
>>>
>>>
>>>
>>>
>>>
>>>        On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner
>>>        <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>
>>>        <mailto:michael.wechner@wyona.com
>>>        <mailto:michael.wechner@wyona.com>>> wrote:
>>>
>>>           From your log-file it seems that these libraries are
>>>        downloaded at
>>>           the very beginning of the build:
>>>
>>>           Apache Ant version 1.7.1 compiled on June 27 2008
>>>           INFO: Building Yanel...
>>>           Buildfile: src/build/build.xml
>>>
>>>           init:
>>>              [echo] INFO: Building with Apache Ant version 1.7.1
>>>        compiled on
>>>           June 27 2008 and Java version 1.6
>>>              [echo] Yanel Home Dir:
>>>           /Users/memo/Wyona/Work/Yanel/src/build/../../
>>>
>>>           probe-proxy:
>>>              [echo] Check if proxy has been set ...
>>>
>>>           proxy:
>>>
>>>
>>>           dependencies:
>>>           [artifact:dependencies] Downloading:
>>>           commons-io/commons-io/1.2/commons-io-1.2.pom from
>>>           wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>           commons-io/commons-io/1.2/commons-io-1.2.pom from central
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jak=
arta-commons-discovery-0.2.pom
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 0K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apa=
che-jakarta-commons-id-0.1-dev-lcr357257.pom
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 0K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jak=
arta-commons-logging-1.0.4.pom
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 0K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-co=
mmons-io-1.2.pom
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 0K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>           commons-io/commons-io/1.2/commons-io-1.2.jar from
>>>           wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>           commons-io/commons-io/1.2/commons-io-1.2.jar from central
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jak=
arta-commons-discovery-0.2.jar
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 70K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apa=
che-jakarta-commons-id-0.1-dev-lcr357257.jar
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 53K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jak=
arta-commons-logging-1.0.4.jar
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 37K from
>>>        wyona.remote.repository
>>>           [artifact:dependencies] Downloading:
>>>
>>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-co=
mmons-io-1.2.jar
>>>           from wyona.remote.repository
>>>           [artifact:dependencies] Transferring 64K from
>>>        wyona.remote.repository
>>>             [unzip] Expanding:
>>>
>>>  /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip into
>>>
>>>  /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>>>
>>>
>>>           Now one has to analyze why. I guess the easiest is to
>>>        delete the
>>>           whole local Maven repo and build/log again and then analyze it
>>>           again. (I assume you just deleted this libs instead the whole
>>>           local repo, right?)
>>>
>>>           Thanks
>>>
>>>           Michi
>>>
>>>           Mehmet Birgi wrote:
>>>
>>>               Hi Michael
>>>
>>>
>>>               On Tue, Apr 6, 2010 at 3:52 PM, <bugzilla@wyona.com
>>>        <mailto:bugzilla@wyona.com>
>>>               <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>>
>>>        <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>
>>>
>>>               <mailto:bugzilla@wyona.com
>>>        <mailto:bugzilla@wyona.com>>>> wrote:
>>>
>>>
>>> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7551
>>>
>>>
>>>                  michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>> changed:
>>>
>>>
>>>                            What    |Removed                     |Added
>>>
>>>  ----------------------------------------------------------------------=
------
>>>                          AssignedTo|michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>
>>>                  <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>>   |mehmet.birgi@wyona.com
>>>        <mailto:mehmet.birgi@wyona.com>
>>>               <mailto:mehmet.birgi@wyona.com
>>>        <mailto:mehmet.birgi@wyona.com>>
>>>                  <mailto:mehmet.birgi@wyona.com
>>>        <mailto:mehmet.birgi@wyona.com>
>>>               <mailto:mehmet.birgi@wyona.com
>>>        <mailto:mehmet.birgi@wyona.com>>>
>>>
>>>
>>>
>>>
>>>
>>>                  ------- Comment #3 from michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>
>>>                  <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>
>>>               <mailto:michael.wechner@wyona.org
>>>        <mailto:michael.wechner@wyona.org>>>  2010-04-06 14:48 -------
>>>
>>>                  It would be important that you add the piece of the log
>>>               file where
>>>                  one can see
>>>                  from where the Maven download is actually started. Rig=
ht
>>>               now one
>>>                  can only see,
>>>                  that it is downloaded, but not which resource or
>>>        realm or
>>>                  component is actually
>>>                  triggering the download
>>>
>>>
>>>               I am not sure I understand what you mean, I have
>>>        attached the
>>>               whole log file, can you point me to the proper entries?
>>>        Maybe
>>>               this information is not logged?
>>>
>>>               Thanks,
>>>
>>>               Memo
>>>
>>>
>>>
>>>                  --
>>>                  Configure bugmail:
>>>
>>> http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=3Demail
>>>                  ------- You are receiving this mail because: -------
>>>                  You are the QA contact for the bug, or are watching
>>>        the QA
>>>               contact.
>>>                  --
>>>                  Yanel-development mailing list
>>>        Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>>>               <mailto:Yanel-development@wyona.com
>>>        <mailto:Yanel-development@wyona.com>>
>>>                  <mailto:Yanel-development@wyona.com
>>>        <mailto:Yanel-development@wyona.com>
>>>               <mailto:Yanel-development@wyona.com
>>>        <mailto:Yanel-development@wyona.com>>>
>>>
>>>
>>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>>               --         Mehmet Birgi
>>>               www.wyona.com <http://www.wyona.com>
>>>        <http://www.wyona.com> <http://www.wyona.com>
>>>
>>>
>>>
>>>           --     Yanel-development mailing list
>>>        Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>>>           <mailto:Yanel-development@wyona.com
>>>        <mailto:Yanel-development@wyona.com>>
>>>
>>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>>        --         Mehmet Birgi
>>>        www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>>>
>>>
>>>    --     Yanel-development mailing list Yanel-development@wyona.com
>>>    <mailto:Yanel-development@wyona.com>
>>>    http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>>
>>>
>>>
>>>
>>> --
>>> Mehmet Birgi
>>> www.wyona.com <http://www.wyona.com>
>>>
>>>
>> --
>> Yanel-development mailing list Yanel-development@wyona.com
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>
>
>
> --
> Mehmet Birgi
> www.wyona.com
>
>


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
7/b96b0ba0/attachment-0001.htm
From michael.wechner at wyona.com  Wed Apr  7 15:20:39 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 15:34:04 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <l2w5bf1397d1004070555g571370fw99344b81ad5b599@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>	<4BBB47B4.8020302@wyona.com>	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>	<4BBC327B.1070305@wyona.com>	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>	<4BBC5018.2080506@wyona.com>	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
	<l2w5bf1397d1004070555g571370fw99344b81ad5b599@mail.gmail.com>
Message-ID: <4BBC86A7.3000307@wyona.com>

Mehmet Birgi wrote:
> I did some more checks for the other duplicates. It looks like we have 
> 5 different versions of commons-logging in our repository, one of them 
> twice:
>
> $ find ~/.m2/repository/ -type f | grep "commons-logging"
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar.md5
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom.md5
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-logging-1.0.pom
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-logging-1.0.pom.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.pom
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/commons-logging-1.0.3.pom.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.pom.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-logging-1.1.jar
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-logging-1.1.jar.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-logging-1.1.pom
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-logging-1.1.pom.sha1
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.pom
> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.pom.sha1
>
> Is it necessary to have so many versions?

I guess not, but I don't know or rather would have to check more closely 
myself


> At least the 2 1.0.4 versions seem to be the same (checked jar file 
> contents).
>
> commons-discovery is also included twice (they are identical):
>
> $ find ~/.m2/repository/ -type f | grep 
> "commons-discovery"/Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar.md5
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom.md5
> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons-discovery-0.2.jar
> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons-discovery-0.2.jar.sha1
> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons-discovery-0.2.pom
> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/commons-discovery-0.2.pom.sha1
>
> while commons-id is there only once, but with the jakarta-groupId:
>
> $ find ~/.m2/repository/ -type f | grep "commons-id"
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar.md5
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom.md5
>
> Shall we continue with the cleaning now, or just put this info into 
> bugzilla for later?

as said, let's do it incrementally ;-) If you work on something where 
this is somehow used, then change it,
otherwise let's just put it into Bugzilla.

Thanks

Michi
>
> Thanks,
>
> memo
>
>
>
>
>
>
> On Wed, Apr 7, 2010 at 11:48 AM, Mehmet Birgi <mehmet.birgi@wyona.com 
> <mailto:mehmet.birgi@wyona.com>> wrote:
>
>
>
>     On Wed, Apr 7, 2010 at 11:27 AM, Michael Wechner
>     <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>         Mehmet Birgi wrote:
>
>             Re which one to use: in the maven documentation, it is
>             suggested
>             (http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_external_dependencies,
>             7. paragraph) that one use http://ibiblio.org/maven2 as a
>             reference to what the artifact id should be for any
>             (apache) dependency. According to that, we should use
>             "commons-io", rather than "apache-jakarta-commons-io".
>
>
>         ibiblio is just one of the many Maven repositories. I think we
>         need to approach this slightly different. First  we should
>         check if these
>         libs are really the same. One first simple check is to open
>         the jar files and compare:
>
>         jar -tf
>         /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>
>         another simple one is to count the number of files
>
>         jar -tf
>         /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>         | wc -l
>
>         and another is to compare the size
>
>         ls -l
>         /Users/michaelwechner/.m2/repository/commons-io/commons-io/1.2/commons-io-1.2.jar
>
>         and yes it really seems that these are the same libs -;-)
>
>         Yes,  ibiblio contains
>
>
>         http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/
>
>         but does not contain apache-jakarta-commons.
>
>         Also commons is an ex-subproject of the jakarta project
>
>         http://jakarta.apache.org/
>
>         which is now
>
>         http://commons.apache.org/io/
>         http://commons.apache.org/io/download_io.cgi
>         http://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-1.4/pom.xml
>
>         so based on this I would agree to replace the
>         apache-jakarta-commons-io  by commons-io.
>
>         I have done this now at
>
>         https://svn.wyona.com/repos/public/yanel/trunk/src/build/dependencies.xml
>
>         and
>
>
>         https://svn.wyona.com/repos/public/security/trunk/dependencies.xml
>
>
>     Thanks
>      
>
>
>
>
>             So I would suggest that we change all the dependencies
>             referring to "apache-jakarta-commons-io" to refer to
>             "commons-io". Is that OK, or are there other things to
>             consider? If you agree, I will try to find out if this is
>             documented somewhere, and if not, add it to the best
>             practices, OK?
>
>
>         I am not sure if the best practices are the best place for
>         this, but I guess it's better to add it there than nowhere
>
>
>     We could add it here:
>     http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=CodingGuidelines
>     or better make a new page "MavenGuidelines", add it there, and
>     link to it from here:
>     http://documentation.yanel.wyona.org/wiki/wiki/Guidelines
>
>     wdyt?
>
>
>
>
>
>              Of the files above, commons-discovery and commons-logging
>             are downloaded twice (like commons-io) while commons-id is
>             only downloaded once (but to the "wrong" path in the maven
>             repository).
>
>             Shall I continue looking for inconsistencies? (There is
>             also the grep output of the src directory below to
>             consider, I think there are a lot of "wrong" references
>             that might still download to this second location if we
>             correct the ref in
>             wyona-org-security-core-0.2-dev-r48408.pom) The sure way
>             to clean this all up would probably be to go through the
>             ~/.m2 directory and check for each artifact if it is in
>             the proper place, wdyt?
>
>
>         I think we should do it incrementally. If we find something,
>         then let's replace, otherwise it doesn't hurt.
>
>         Re commons-logging and the others we need to first check if
>         these are really the same libs. Have you done this?
>
>
>     no, i will check those and report back
>
>     Thanks,
>
>     memo
>
>      
>
>
>         Thanks
>
>         Michi
>
>
>
>             Cheers,
>
>             Memo
>
>
>
>                Cheers
>
>                Michi
>
>                Mehmet Birgi wrote:
>
>                    What I could find out so far:
>
>                    1. The correct artifact-id is "commons-io",
>             according to the
>                    Maven docs, that point to ibiblio.org/maven2
>             <http://ibiblio.org/maven2>
>                    <http://ibiblio.org/maven2>
>             <http://ibiblio.org/maven2> as the
>
>                    reference
>                  
>              (http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/maven-metadata.xml)
>
>
>
>                    2. I have found a reference to the "incorrect"
>             artifact-id,
>                    "apache-jakarta-commons-io", but there seem to be
>             several
>                    others too:
>
>                    memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>                    apache-jakarta-commons-io src | grep -v '/\.svn/' |
>             grep -v
>                    '\.yarep/'
>                    src/build/dependencies.xml:      <dependency
>                    groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io"
>                  
>              src/contributions/resources/xinha/src/build/dependencies.xml:
>                         <dependency groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                  
>              src/realms/welcome-admin/yanel/resources/update-webapp/src/build/dependencies.xml:
>                         <dependency groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                    src/resources/add-realm/src/build/dependencies.xml:
>                         <dependency groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                  
>              src/resources/testing-control/src/build/dependencies.xml:
>                         <dependency groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                    src/resources/tinymce/src/build/dependencies.xml:  
>                       <dependency groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                    src/resources/xml/src/build/dependencies.xml:    
>              <dependency
>                    groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>                    src/test/build.xml:      <dependency
>                    groupId="apache-jakarta-commons"
>                    artifactId="apache-jakarta-commons-io" version="1.2"/>
>
>
>                    I am attaching the new build.log after deleting
>             ~/.m2 to this
>                    mail, I couldn't gain any new insights from it, but
>             I will
>                    gladly pursue any further hints.
>
>                    That's it for now, cheers & good night
>
>                    Memo
>
>
>
>
>
>                    On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner
>                    <michael.wechner@wyona.com
>             <mailto:michael.wechner@wyona.com>
>             <mailto:michael.wechner@wyona.com
>             <mailto:michael.wechner@wyona.com>>
>                    <mailto:michael.wechner@wyona.com
>             <mailto:michael.wechner@wyona.com>
>                    <mailto:michael.wechner@wyona.com
>             <mailto:michael.wechner@wyona.com>>>> wrote:
>
>                       From your log-file it seems that these libraries are
>                    downloaded at
>                       the very beginning of the build:
>
>                       Apache Ant version 1.7.1 compiled on June 27 2008
>                       INFO: Building Yanel...
>                       Buildfile: src/build/build.xml
>
>                       init:
>                          [echo] INFO: Building with Apache Ant version
>             1.7.1
>                    compiled on
>                       June 27 2008 and Java version 1.6
>                          [echo] Yanel Home Dir:
>                       /Users/memo/Wyona/Work/Yanel/src/build/../../
>
>                       probe-proxy:
>                          [echo] Check if proxy has been set ...
>
>                       proxy:
>
>
>                       dependencies:
>                       [artifact:dependencies] Downloading:
>                       commons-io/commons-io/1.2/commons-io-1.2.pom from
>                       wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                       commons-io/commons-io/1.2/commons-io-1.2.pom
>             from central
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 0K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 0K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 0K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.pom
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 0K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                       commons-io/commons-io/1.2/commons-io-1.2.jar from
>                       wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                       commons-io/commons-io/1.2/commons-io-1.2.jar
>             from central
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 70K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 53K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 37K from
>                    wyona.remote.repository
>                       [artifact:dependencies] Downloading:
>                            
>              apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>                       from wyona.remote.repository
>                       [artifact:dependencies] Transferring 64K from
>                    wyona.remote.repository
>                         [unzip] Expanding:
>                            
>              /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip
>             into
>                            
>              /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>
>
>                       Now one has to analyze why. I guess the easiest
>             is to
>                    delete the
>                       whole local Maven repo and build/log again and
>             then analyze it
>                       again. (I assume you just deleted this libs
>             instead the whole
>                       local repo, right?)
>
>                       Thanks
>
>                       Michi
>
>                       Mehmet Birgi wrote:
>
>                           Hi Michael
>
>
>                           On Tue, Apr 6, 2010 at 3:52 PM,
>             <bugzilla@wyona.com <mailto:bugzilla@wyona.com>
>                    <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>>
>                           <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com>>>
>                    <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com>>
>
>                           <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com>
>                    <mailto:bugzilla@wyona.com
>             <mailto:bugzilla@wyona.com>>>>> wrote:
>
>                                    
>             http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551
>
>
>                              michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>> changed:
>
>
>                                        What    |Removed              
>                   |Added
>                                          
>              ----------------------------------------------------------------------------
>                                    
>              AssignedTo|michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>
>                              <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>>  
>             |mehmet.birgi@wyona.com <mailto:mehmet.birgi@wyona.com>
>                    <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>>
>                           <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>
>                    <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>>>
>                              <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>
>                    <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>>
>                           <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>
>                    <mailto:mehmet.birgi@wyona.com
>             <mailto:mehmet.birgi@wyona.com>>>>
>
>
>
>
>
>                              ------- Comment #3 from
>             michael.wechner@wyona.org <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>
>                              <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>
>                           <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>
>                    <mailto:michael.wechner@wyona.org
>             <mailto:michael.wechner@wyona.org>>>>  2010-04-06 14:48
>             -------
>
>                              It would be important that you add the
>             piece of the log
>                           file where
>                              one can see
>                              from where the Maven download is actually
>             started. Right
>                           now one
>                              can only see,
>                              that it is downloaded, but not which
>             resource or
>                    realm or
>                              component is actually
>                              triggering the download
>
>
>                           I am not sure I understand what you mean, I have
>                    attached the
>                           whole log file, can you point me to the
>             proper entries?
>                    Maybe
>                           this information is not logged?
>
>                           Thanks,
>
>                           Memo
>
>
>                          
>                              --
>                              Configure bugmail:
>                                          
>              http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
>                              ------- You are receiving this mail
>             because: -------
>                              You are the QA contact for the bug, or
>             are watching
>                    the QA
>                           contact.
>                              --
>                              Yanel-development mailing list
>                    Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>             <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>
>                           <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>                    <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>>
>                              <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>                    <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>
>                           <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>                    <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>>>
>
>                                          
>              http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>                           --         Mehmet Birgi
>                           www.wyona.com <http://www.wyona.com>
>             <http://www.wyona.com>
>                    <http://www.wyona.com> <http://www.wyona.com>
>
>
>
>                       --     Yanel-development mailing list
>                    Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>             <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>
>                       <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>                    <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>>
>                            
>              http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>                    --         Mehmet Birgi
>                    www.wyona.com <http://www.wyona.com>
>             <http://www.wyona.com> <http://www.wyona.com>
>
>
>                --     Yanel-development mailing list
>             Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>
>                <mailto:Yanel-development@wyona.com
>             <mailto:Yanel-development@wyona.com>>
>              
>              http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>             -- 
>             Mehmet Birgi
>             www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>         -- 
>         Yanel-development mailing list Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>
>         http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>     -- 
>     Mehmet Birgi
>     www.wyona.com <http://www.wyona.com>
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From bugzilla at wyona.com  Wed Apr  7 15:51:07 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr  7 15:51:10 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache libraries in .m2
Message-ID: <20100407135107.A0E9A10CA2F@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551


mehmet.birgi@wyona.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Duplicate Apache commons-io |Duplicate Apache libraries
                   |in .m2                      |in .m2




------- Comment #4 from mehmet.birgi@wyona.com  2010-04-07 14:47 -------
The inconsistency for commons-io is now fixed, but there are other duplicates
in the repository. These should be fixed incrementally, whenever the
opportunity arises. Some of the remaining duplicates are: 

apache-jakarta-commons-logging-1.0.4.jar
commons-logging-1.0.4.jar
commons-logging-1.1.jar

apache-jakarta-commons-discovery-0.2.jar
commons-discovery-0.2.jar

For the convention on naming the artifacts, see:
http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=MavenGuidelines

According to this guideline, also the following should be renamed for
consistency, because it is not (anymore) part of Jakarta:

apache-jakarta-commons-id-0.1-dev-lcr357257.jar


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From mehmet.birgi at wyona.com  Wed Apr  7 15:45:41 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr  7 16:00:38 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <4BBC86A7.3000307@wyona.com>
References: <20100406135219.5908310CAB7@server1.example.com>
	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>
	<4BBB47B4.8020302@wyona.com>
	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>
	<4BBC327B.1070305@wyona.com>
	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>
	<4BBC5018.2080506@wyona.com>
	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>
	<l2w5bf1397d1004070555g571370fw99344b81ad5b599@mail.gmail.com>
	<4BBC86A7.3000307@wyona.com>
Message-ID: <o2l5bf1397d1004070645nb5ab7391t8e29515c63a27102@mail.gmail.com>

OK, I have added this info to bugzilla:
http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7551

Cheers,

memo



On Wed, Apr 7, 2010 at 3:20 PM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>> I did some more checks for the other duplicates. It looks like we have 5
>> different versions of commons-logging in our repository, one of them twi=
ce:
>>
>> $ find ~/.m2/repository/ -type f | grep "commons-logging"
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.jar.md5
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-logging/1.0.4/apache-jakarta-commons-logging-1.0.4.pom.md5
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-=
logging-1.0.pom
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0/commons-=
logging-1.0.pom.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/common=
s-logging-1.0.3.pom
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.3/common=
s-logging-1.0.3.pom.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/common=
s-logging-1.0.4.jar
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/common=
s-logging-1.0.4.jar.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/common=
s-logging-1.0.4.pom
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.0.4/common=
s-logging-1.0.4.pom.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-=
logging-1.1.jar
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-=
logging-1.1.jar.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-=
logging-1.1.pom
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1/commons-=
logging-1.1.pom.sha1
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/common=
s-logging-1.1.1.pom
>>
>> /Users/memo/.m2/repository//commons-logging/commons-logging/1.1.1/common=
s-logging-1.1.1.pom.sha1
>>
>> Is it necessary to have so many versions?
>>
>
> I guess not, but I don't know or rather would have to check more closely
> myself
>
>
>
>  At least the 2 1.0.4 versions seem to be the same (checked jar file
>> contents).
>>
>> commons-discovery is also included twice (they are identical):
>>
>> $ find ~/.m2/repository/ -type f | grep
>> "commons-discovery"/Users/memo/.m2/repository//apache-jakarta-commons/ap=
ache-jakarta-commons-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-discovery/0.2/apache-jakarta-commons-discovery-0.2.jar.md5
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-discovery/0.2/apache-jakarta-commons-discovery-0.2.pom.md5
>>
>> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/comm=
ons-discovery-0.2.jar
>>
>> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/comm=
ons-discovery-0.2.jar.sha1
>>
>> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/comm=
ons-discovery-0.2.pom
>>
>> /Users/memo/.m2/repository//commons-discovery/commons-discovery/0.2/comm=
ons-discovery-0.2.pom.sha1
>>
>> while commons-id is there only once, but with the jakarta-groupId:
>>
>> $ find ~/.m2/repository/ -type f | grep "commons-id"
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.jar.md5
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom
>>
>> /Users/memo/.m2/repository//apache-jakarta-commons/apache-jakarta-common=
s-id/0.1-dev-lcr357257/apache-jakarta-commons-id-0.1-dev-lcr357257.pom.md5
>>
>> Shall we continue with the cleaning now, or just put this info into
>> bugzilla for later?
>>
>
> as said, let's do it incrementally ;-) If you work on something where this
> is somehow used, then change it,
> otherwise let's just put it into Bugzilla.
>
> Thanks
>
> Michi
>
>>
>> Thanks,
>>
>> memo
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 7, 2010 at 11:48 AM, Mehmet Birgi <mehmet.birgi@wyona.com<ma=
ilto:
>> mehmet.birgi@wyona.com>> wrote:
>>
>>
>>
>>    On Wed, Apr 7, 2010 at 11:27 AM, Michael Wechner
>>    <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>>
>>        Mehmet Birgi wrote:
>>
>>            Re which one to use: in the maven documentation, it is
>>            suggested
>>            (
>> http://maven.apache.org/guides/getting-started/index.html#How_do_I_use_e=
xternal_dependencies
>> ,
>>            7. paragraph) that one use http://ibiblio.org/maven2 as a
>>            reference to what the artifact id should be for any
>>            (apache) dependency. According to that, we should use
>>            "commons-io", rather than "apache-jakarta-commons-io".
>>
>>
>>        ibiblio is just one of the many Maven repositories. I think we
>>        need to approach this slightly different. First  we should
>>        check if these
>>        libs are really the same. One first simple check is to open
>>        the jar files and compare:
>>
>>        jar -tf
>>
>>  /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jaka=
rta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>>
>>        another simple one is to count the number of files
>>
>>        jar -tf
>>
>>  /Users/michaelwechner/.m2/repository/apache-jakarta-commons/apache-jaka=
rta-commons-io/1.2/apache-jakarta-commons-io-1.2.jar
>>        | wc -l
>>
>>        and another is to compare the size
>>
>>        ls -l
>>
>>  /Users/michaelwechner/.m2/repository/commons-io/commons-io/1.2/commons-=
io-1.2.jar
>>
>>        and yes it really seems that these are the same libs -;-)
>>
>>        Yes,  ibiblio contains
>>
>>
>>
>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/
>>
>>        but does not contain apache-jakarta-commons.
>>
>>        Also commons is an ex-subproject of the jakarta project
>>
>>        http://jakarta.apache.org/
>>
>>        which is now
>>
>>        http://commons.apache.org/io/
>>        http://commons.apache.org/io/download_io.cgi
>>
>> http://svn.apache.org/repos/asf/commons/proper/io/tags/commons-io-1.4/po=
m.xml
>>
>>        so based on this I would agree to replace the
>>        apache-jakarta-commons-io  by commons-io.
>>
>>        I have done this now at
>>
>>
>> https://svn.wyona.com/repos/public/yanel/trunk/src/build/dependencies.xml
>>
>>        and
>>
>>
>>        https://svn.wyona.com/repos/public/security/trunk/dependencies.xml
>>
>>
>>    Thanks
>>
>>
>>
>>
>>            So I would suggest that we change all the dependencies
>>            referring to "apache-jakarta-commons-io" to refer to
>>            "commons-io". Is that OK, or are there other things to
>>            consider? If you agree, I will try to find out if this is
>>            documented somewhere, and if not, add it to the best
>>            practices, OK?
>>
>>
>>        I am not sure if the best practices are the best place for
>>        this, but I guess it's better to add it there than nowhere
>>
>>
>>    We could add it here:
>>    http://wiki.wyona.com/WyonaWiki/Wiki.jsp?page=3DCodingGuidelines
>>    or better make a new page "MavenGuidelines", add it there, and
>>    link to it from here:
>>    http://documentation.yanel.wyona.org/wiki/wiki/Guidelines
>>
>>    wdyt?
>>
>>
>>
>>
>>
>>             Of the files above, commons-discovery and commons-logging
>>            are downloaded twice (like commons-io) while commons-id is
>>            only downloaded once (but to the "wrong" path in the maven
>>            repository).
>>
>>            Shall I continue looking for inconsistencies? (There is
>>            also the grep output of the src directory below to
>>            consider, I think there are a lot of "wrong" references
>>            that might still download to this second location if we
>>            correct the ref in
>>            wyona-org-security-core-0.2-dev-r48408.pom) The sure way
>>            to clean this all up would probably be to go through the
>>            ~/.m2 directory and check for each artifact if it is in
>>            the proper place, wdyt?
>>
>>
>>        I think we should do it incrementally. If we find something,
>>        then let's replace, otherwise it doesn't hurt.
>>
>>        Re commons-logging and the others we need to first check if
>>        these are really the same libs. Have you done this?
>>
>>
>>    no, i will check those and report back
>>
>>    Thanks,
>>
>>    memo
>>
>>
>>
>>        Thanks
>>
>>        Michi
>>
>>
>>
>>            Cheers,
>>
>>            Memo
>>
>>
>>
>>               Cheers
>>
>>               Michi
>>
>>               Mehmet Birgi wrote:
>>
>>                   What I could find out so far:
>>
>>                   1. The correct artifact-id is "commons-io",
>>            according to the
>>                   Maven docs, that point to ibiblio.org/maven2
>>            <http://ibiblio.org/maven2>
>>                   <http://ibiblio.org/maven2>
>>            <http://ibiblio.org/maven2> as the
>>
>>                   reference
>>                              (
>> http://mirrors.ibiblio.org/pub/mirrors/maven2/commons-io/commons-io/mave=
n-metadata.xml
>> )
>>
>>
>>
>>                   2. I have found a reference to the "incorrect"
>>            artifact-id,
>>                   "apache-jakarta-commons-io", but there seem to be
>>            several
>>                   others too:
>>
>>                   memo@Memos-MacSilver:~/Wyona/Work/Yanel $ grep -riI
>>                   apache-jakarta-commons-io src | grep -v '/\.svn/' |
>>            grep -v
>>                   '\.yarep/'
>>                   src/build/dependencies.xml:      <dependency
>>                   groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io"
>>
>>  src/contributions/resources/xinha/src/build/dependencies.xml:
>>                        <dependency groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>
>>  src/realms/welcome-admin/yanel/resources/update-webapp/src/build/depend=
encies.xml:
>>                        <dependency groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>                   src/resources/add-realm/src/build/dependencies.xml:
>>                        <dependency groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>
>>  src/resources/testing-control/src/build/dependencies.xml:
>>                        <dependency groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>                   src/resources/tinymce/src/build/dependencies.xml:
>>                  <dependency groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>                   src/resources/xml/src/build/dependencies.xml:
>>       <dependency
>>                   groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>                   src/test/build.xml:      <dependency
>>                   groupId=3D"apache-jakarta-commons"
>>                   artifactId=3D"apache-jakarta-commons-io" version=3D"1.=
2"/>
>>
>>
>>                   I am attaching the new build.log after deleting
>>            ~/.m2 to this
>>                   mail, I couldn't gain any new insights from it, but
>>            I will
>>                   gladly pursue any further hints.
>>
>>                   That's it for now, cheers & good night
>>
>>                   Memo
>>
>>
>>
>>
>>
>>                   On Tue, Apr 6, 2010 at 4:39 PM, Michael Wechner
>>                   <michael.wechner@wyona.com
>>            <mailto:michael.wechner@wyona.com>
>>            <mailto:michael.wechner@wyona.com
>>            <mailto:michael.wechner@wyona.com>>
>>                   <mailto:michael.wechner@wyona.com
>>            <mailto:michael.wechner@wyona.com>
>>                   <mailto:michael.wechner@wyona.com
>>            <mailto:michael.wechner@wyona.com>>>> wrote:
>>
>>                      From your log-file it seems that these libraries are
>>                   downloaded at
>>                      the very beginning of the build:
>>
>>                      Apache Ant version 1.7.1 compiled on June 27 2008
>>                      INFO: Building Yanel...
>>                      Buildfile: src/build/build.xml
>>
>>                      init:
>>                         [echo] INFO: Building with Apache Ant version
>>            1.7.1
>>                   compiled on
>>                      June 27 2008 and Java version 1.6
>>                         [echo] Yanel Home Dir:
>>                      /Users/memo/Wyona/Work/Yanel/src/build/../../
>>
>>                      probe-proxy:
>>                         [echo] Check if proxy has been set ...
>>
>>                      proxy:
>>
>>
>>                      dependencies:
>>                      [artifact:dependencies] Downloading:
>>                      commons-io/commons-io/1.2/commons-io-1.2.pom from
>>                      wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>                      commons-io/commons-io/1.2/commons-io-1.2.pom
>>            from central
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.pom
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 0K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.pom
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 0K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.pom
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 0K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.pom
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 0K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>                      commons-io/commons-io/1.2/commons-io-1.2.jar from
>>                      wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>                      commons-io/commons-io/1.2/commons-io-1.2.jar
>>            from central
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-discovery/0.2/apache-jaka=
rta-commons-discovery-0.2.jar
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 70K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-id/0.1-dev-lcr357257/apac=
he-jakarta-commons-id-0.1-dev-lcr357257.jar
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 53K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-logging/1.0.4/apache-jaka=
rta-commons-logging-1.0.4.jar
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 37K from
>>                   wyona.remote.repository
>>                      [artifact:dependencies] Downloading:
>>
>>  apache-jakarta-commons/apache-jakarta-commons-io/1.2/apache-jakarta-com=
mons-io-1.2.jar
>>                      from wyona.remote.repository
>>                      [artifact:dependencies] Transferring 64K from
>>                   wyona.remote.repository
>>                        [unzip] Expanding:
>>
>>  /Users/memo/.m2/repository/ext/gwtext/2.0.2/gwtext-2.0.2.zip
>>            into
>>
>>  /Users/memo/Wyona/Work/Yanel/build/webapps/yanel/htdocs/gwt-ext-2.0.2
>>
>>
>>                      Now one has to analyze why. I guess the easiest
>>            is to
>>                   delete the
>>                      whole local Maven repo and build/log again and
>>            then analyze it
>>                      again. (I assume you just deleted this libs
>>            instead the whole
>>                      local repo, right?)
>>
>>                      Thanks
>>
>>                      Michi
>>
>>                      Mehmet Birgi wrote:
>>
>>                          Hi Michael
>>
>>
>>                          On Tue, Apr 6, 2010 at 3:52 PM,
>>            <bugzilla@wyona.com <mailto:bugzilla@wyona.com>
>>                   <mailto:bugzilla@wyona.com <mailto:bugzilla@wyona.com>>
>>                          <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com>>>
>>                   <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com> <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com>>
>>
>>                          <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com>
>>                   <mailto:bugzilla@wyona.com
>>            <mailto:bugzilla@wyona.com>>>>> wrote:
>>
>>
>> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=3D7551
>>
>>
>>                             michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>> changed:
>>
>>
>>                                       What    |Removed
>>            |Added
>>
>>  -----------------------------------------------------------------------=
-----
>>                                                AssignedTo|
>> michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>
>>                             <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>>              |
>> mehmet.birgi@wyona.com <mailto:mehmet.birgi@wyona.com>
>>                   <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>>
>>                          <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>
>>                   <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>>>
>>                             <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>
>>                   <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>>
>>                          <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>
>>                   <mailto:mehmet.birgi@wyona.com
>>            <mailto:mehmet.birgi@wyona.com>>>>
>>
>>
>>
>>
>>
>>                             ------- Comment #3 from
>>            michael.wechner@wyona.org <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>
>>                             <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>
>>                          <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>
>>                   <mailto:michael.wechner@wyona.org
>>            <mailto:michael.wechner@wyona.org>>>>  2010-04-06 14:48
>>            -------
>>
>>                             It would be important that you add the
>>            piece of the log
>>                          file where
>>                             one can see
>>                             from where the Maven download is actually
>>            started. Right
>>                          now one
>>                             can only see,
>>                             that it is downloaded, but not which
>>            resource or
>>                   realm or
>>                             component is actually
>>                             triggering the download
>>
>>
>>                          I am not sure I understand what you mean, I have
>>                   attached the
>>                          whole log file, can you point me to the
>>            proper entries?
>>                   Maybe
>>                          this information is not logged?
>>
>>                          Thanks,
>>
>>                          Memo
>>
>>
>>                                                      --
>>                             Configure bugmail:
>>
>> http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=3Demail
>>                             ------- You are receiving this mail
>>            because: -------
>>                             You are the QA contact for the bug, or
>>            are watching
>>                   the QA
>>                          contact.
>>                             --
>>                             Yanel-development mailing list
>>                   Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>            <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>
>>                          <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>                   <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>>
>>                             <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>                   <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>
>>                          <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>                   <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>>>
>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>                          --         Mehmet Birgi
>>                          www.wyona.com <http://www.wyona.com>
>>            <http://www.wyona.com>
>>                   <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>
>>                      --     Yanel-development mailing list
>>                   Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>            <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>
>>                      <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>                   <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>                   --         Mehmet Birgi
>>                   www.wyona.com <http://www.wyona.com>
>>            <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>               --     Yanel-development mailing list
>>            Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>
>>               <mailto:Yanel-development@wyona.com
>>            <mailto:Yanel-development@wyona.com>>
>>
>> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>            --             Mehmet Birgi
>>            www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>>
>>
>>        --         Yanel-development mailing list
>> Yanel-development@wyona.com
>>        <mailto:Yanel-development@wyona.com>
>>        http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>>    --     Mehmet Birgi
>>    www.wyona.com <http://www.wyona.com>
>>
>>
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010040=
7/14eb8c4e/attachment-0001.htm
From michael.wechner at wyona.com  Wed Apr  7 15:56:57 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr  7 16:11:04 2010
Subject: [Yanel-dev] [Bug 7551] Duplicate Apache commons-io in .m2
In-Reply-To: <o2l5bf1397d1004070645nb5ab7391t8e29515c63a27102@mail.gmail.com>
References: <20100406135219.5908310CAB7@server1.example.com>	<j2o5bf1397d1004060644ndf5edf3du91756df769f9bd6a@mail.gmail.com>	<4BBB47B4.8020302@wyona.com>	<w2u5bf1397d1004061423s1d95f6d4p7deca0a9165569be@mail.gmail.com>	<4BBC327B.1070305@wyona.com>	<v2n5bf1397d1004070139t7fed683ey36cd10d66d98f5d8@mail.gmail.com>	<4BBC5018.2080506@wyona.com>	<h2y5bf1397d1004070248s12baee73p1ecbac0a1175d3af@mail.gmail.com>	<l2w5bf1397d1004070555g571370fw99344b81ad5b599@mail.gmail.com>	<4BBC86A7.3000307@wyona.com>
	<o2l5bf1397d1004070645nb5ab7391t8e29515c63a27102@mail.gmail.com>
Message-ID: <4BBC8F29.4090205@wyona.com>

Mehmet Birgi wrote:
> OK, I have added this info to bugzilla:
> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7551

thanks very much

Michi
>

From michael.wechner at wyona.com  Fri Apr  9 00:21:42 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 00:35:16 2010
Subject: [Yanel-dev] Re: [Yanel-commits] rev 48566
	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>
References: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>
Message-ID: <4BBE56F6.1010201@wyona.com>

Dear Guillaume

As discussed before lets please discuss such changes beforehand:

- Explain what you intend to do and how you want to use this
- Make examples/document it

Maybe there are other possibilities to acomplish what you  want to 
acomplish.

Thanks

Michi

guillaume@wyona.com wrote:
> Author: guillaume
> Date: 2010-04-08 19:47:33 +0200 (Thu, 08 Apr 2010)
> New Revision: 48566
>
> Modified:
>    public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java
> Log:
> EXPERIMENTAL: introduced a "content-repository-id" RC property
>  to allow to choose the repository used when looking for the node:
>  this should allow us to start getting rid of the infamous "data/app*" directories!
>
>
> Modified: public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java
> ===================================================================
> --- public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java	2010-04-08 17:28:40 UTC (rev 48565)
> +++ public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java	2010-04-08 17:47:33 UTC (rev 48566)
> @@ -61,12 +61,6 @@
>      /**
>       *
>       */
> -    public NodeResource() {
> -    }
> -
> -    /**
> -     *
> -     */
>      public ViewDescriptor[] getViewDescriptors() {
>          return null;
>      }
> @@ -143,10 +137,10 @@
>       */
>      public OutputStream getOutputStream() throws Exception {
>          log.error("TODO: Use existsNode() method!");
> -        if (!getRealm().getRepository().existsNode(getPath())) {
> +        if (!getRepository().existsNode(getPath())) {
>              // TODO: create node recursively ...
>              log.error("TODO: Use getNode() method!");
> -            getRealm().getRepository().getNode(new org.wyona.commons.io.Path(getPath()).getParent().toString()).addNode(new org.wyona.commons.io.Path(getPath()).getName().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
> +            getRepository().getNode(new org.wyona.commons.io.Path(getPath()).getParent().toString()).addNode(new org.wyona.commons.io.Path(getPath()).getName().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
>          }
>          return getNode().getOutputStream();
>      }
> @@ -195,7 +189,7 @@
>                  revisionInfos[i] = new RevisionInformation(revisions[i]);
>              }
>              if (revisions.length > 0) {
> -                log.warn("Node \"" + getPath() + "\" does not seem to have any revisions! The repository \"" + getRealm().getRepository() + "\"  might not support revisions!");
> +                log.warn("Node \"" + getPath() + "\" does not seem to have any revisions! The repository \"" + getRepository() + "\"  might not support revisions!");
>              }
>              return revisionInfos;
>          }
> @@ -268,7 +262,7 @@
>      }
>  
>      public boolean exists() throws Exception {
> -        return getRealm().getRepository().existsNode(getPath());
> +        return getRepository().existsNode(getPath());
>      }
>  
>      /**
> @@ -313,7 +307,7 @@
>       */
>      public void create(HttpServletRequest request) {
>          try {
> -            Repository repo = getRealm().getRepository();
> +            Repository repo = getRepository();
>  
>              if (request instanceof HttpRequest) {
>                  HttpRequest yanelRequest = (HttpRequest)request;
> @@ -322,7 +316,7 @@
>                      if (parameters.hasMoreElements()) {
>                          String name = (String) parameters.nextElement();
>  
> -                        Node newNode = org.wyona.yanel.core.util.YarepUtil.addNodes(repo, getPath().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
> +                        Node newNode = org.wyona.yarep.util.YarepUtil.addNodes(repo, getPath().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
>                          OutputStream output = newNode.getOutputStream();
>                          InputStream is = yanelRequest.getInputStream(name);
>                          Streams.copy(is, output, true);
> @@ -594,13 +588,23 @@
>                  path = getResourceConfigProperty("src");
>              }
>              try {
> -                return getRealm().getRepository().getNode(path);
> +                return getRepository().getNode(path);
>              } catch (org.wyona.yarep.core.NoSuchNodeException e) {
>                  throw new org.wyona.yanel.core.ResourceNotFoundException(path);
> -                //throw new org.wyona.yanel.core.ResourceNotFoundException(path, getRealm(), getRealm().getRepository());
> +                //throw new org.wyona.yanel.core.ResourceNotFoundException(path, getRealm(), getRepository());
>              }
>          } catch (Exception e) {
>              throw new org.wyona.yanel.core.ResourceNotFoundException(e);
>          }
>      }
> +
> +    private Repository getRepository() throws Exception {
> +        String repositoryID = getResourceConfigProperty("content-repository-id");
> +        if (log.isDebugEnabled()) log.debug("repositoryID: "+repositoryID); //FIXME
> +        if (repositoryID == null) {
> +            return getRealm().getRepository();
> +        }
> +        Repository repository = getRealm().getRepository(repositoryID);
> +        return repository;
> +    }
>  }
>
>   

From guillaume.deflache at wyona.com  Fri Apr  9 09:00:57 2010
From: guillaume.deflache at wyona.com (=?UTF-8?B?R3VpbGxhdW1lIETDqWZsYWNoZQ==?=)
Date: Fri Apr  9 09:14:14 2010
Subject: [Yanel-dev] Re: [Yanel-commits] rev
	48566	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <4BBE56F6.1010201@wyona.com>
References: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>
	<4BBE56F6.1010201@wyona.com>
Message-ID: <4BBED0A9.4000005@wyona.com>

Hi!

Michael Wechner schrieb:
> Dear Guillaume
> 
> As discussed before lets please discuss such changes beforehand:
> 
> - Explain what you intend to do and how you want to use this

I already explain the intent months ago in "[Yanel-dev] separating 
content from application code &  configuration (or getting rid of "app" 
directory in repository e.g. data/app/)" 
http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
on which I had no feedback.

The change compared to that message is that I found an even simpler 
solution for the "3.2)" point there that is fully backward-compatible 
and IMHO does no harm, so I just committed "out of enthousiasm", sorry...
Maybe I should reply to my own message and explain this new solution there?


> - Make examples/document it

I will be glad to do that once we agree on the details like the name of 
the RC property.
BTW I already tested that on the project I am currently starting, works 
great.
We can probably illustrate it on any public realm that uses a 
"data/app"-like directory, and maybe add a HTTPUnit or Canoo test for 
that while we are at it.


> Maybe there are other possibilities to acomplish what you  want to 
> acomplish.

Maybe, but nobody stepped up to suggest any so far, and I did not want 
to start a project with a "data/app" directory ever again, because we 
all know it cause lots of deployment problems (as you reminded me lately 
when I introduced a "data/admin" directory for storing mockup XHTML pages).

Cheers,
    Guillaume
From guillaume.deflache at wyona.com  Fri Apr  9 13:47:51 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Fri Apr  9 14:02:28 2010
Subject: [Yanel-dev] no password needed for svn read-only access anymore
Message-ID: <4BBF13E7.40206@wyona.com>

HI!

FYI the Wyona server no longer asks for a password /at all/ for 
anonymous read-only access to almost all of 
http://svn.wyona.com/repos/public/ and as such to all Yanel-related code.

So it should be easier than ever to try or lurk into the very latest 
version of Yanel!

Enjoy,
    Guillaume
From michael.wechner at wyona.com  Fri Apr  9 14:10:58 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 14:24:26 2010
Subject: [Yanel-dev] no password needed for svn read-only access anymore
In-Reply-To: <4BBF13E7.40206@wyona.com>
References: <4BBF13E7.40206@wyona.com>
Message-ID: <4BBF1952.3060506@wyona.com>

Guillaume D?flache wrote:
> HI!
>
> FYI the Wyona server no longer asks for a password /at all/ for 
> anonymous read-only access to almost all of 
> http://svn.wyona.com/repos/public/ and as such to all Yanel-related code.
>
> So it should be easier than ever to try or lurk into the very latest 
> version of Yanel!

thanks very much for fixing this.

Michi
>
> Enjoy,
>    Guillaume

From michael.wechner at wyona.com  Fri Apr  9 14:28:20 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 14:41:47 2010
Subject: [Yanel-dev] [Yarep] Getting the owner repository from the node
Message-ID: <4BBF1D64.8010608@wyona.com>

Hi

It seems there is no way to figure out to which repository a node 
belongs to, e.g.

src/core/java/org/wyona/yarep/core/Node.java#getOwnerRepository()

similar to

org.w3c.dom.Node#getOwnerDocument()

or any idea how to accomplish this?

Thanks

Michi
From michael.wechner at wyona.com  Fri Apr  9 15:26:40 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 15:40:07 2010
Subject: [Yanel-dev] Re: [Yanel-commits]
	rev	48566	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <4BBED0A9.4000005@wyona.com>
References: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>	<4BBE56F6.1010201@wyona.com>
	<4BBED0A9.4000005@wyona.com>
Message-ID: <4BBF2B10.9000908@wyona.com>

Guillaume D?flache wrote:
> Hi!
>
> Michael Wechner schrieb:
>> Dear Guillaume
>>
>> As discussed before lets please discuss such changes beforehand:
>>
>> - Explain what you intend to do and how you want to use this
>
> I already explain the intent months ago in "[Yanel-dev] separating 
> content from application code &  configuration (or getting rid of 
> "app" directory in repository e.g. data/app/)" 
> http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
> on which I had no feedback.

just remind people once again



>
> The change compared to that message is that I found an even simpler 
> solution for the "3.2)" point there that is fully backward-compatible 
> and IMHO does no harm, so I just committed "out of enthousiasm", sorry...
> Maybe I should reply to my own message and explain this new solution 
> there?

please do


>
>
>> - Make examples/document it
>
> I will be glad to do that once we agree on the details like the name 
> of the RC property.
> BTW I already tested that on the project I am currently starting, 
> works great.
> We can probably illustrate it on any public realm that uses a 
> "data/app"-like directory, and maybe add a HTTPUnit or Canoo test for 
> that while we are at it.

yes, you should do that


>
>
>> Maybe there are other possibilities to acomplish what you  want to 
>> acomplish.
>
> Maybe, but nobody stepped up to suggest any so far,

Well, I think it's better to use a protocol:

http://documentation.yanel.wyona.org/wiki/wiki/Unstructured%20Points

e.g.

src="yanelrepo:REALM_ID:REPO_ID:/index.html"

and in your particular case

src="yanelrepo::app:/index.html"

WDYT?


> and I did not want to start a project with a "data/app" directory ever 
> again, because we all know it cause lots of deployment problems

you mean because of the CHANGE_LOG?

If you have files within a separate repository, you will still have to 
synchronize these repositories and chances
are there that people do make changes on the productive environment. So 
I don't think the problems
will go away completely, but I agree it will make it easier


> (as you reminded me lately when I introduced a "data/admin" directory 
> for storing mockup XHTML pages).

I think that's a different case
>
> Cheers,
>    Guillaume

From michael.wechner at wyona.com  Fri Apr  9 15:56:21 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 16:09:48 2010
Subject: [Yanel-dev] Re: [Yanel-commits] rev 48579
	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <201004091306.o39D6EQ2030151@cvs-extra.wyona.com>
References: <201004091306.o39D6EQ2030151@cvs-extra.wyona.com>
Message-ID: <4BBF3205.60500@wyona.com>

I have reverted the commit, because we have to clarify what's best and I 
think it's important that we
do that first before the code creates its own dynamic.

In the meantime Guillaume will create a separate resource to experiment 
with.

Thanks

Michi


michi@wyona.com wrote:
> Author: michi
> Date: 2010-04-09 15:06:14 +0200 (Fri, 09 Apr 2010)
> New Revision: 48579
>
> Modified:
>    public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java
> Log:
> last change reverted because discussion has not been clarified yet. We will create a separate resource type based on the file/node resource to experiment with and come back to probably enhancing this at some later stage
>
> Modified: public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java
> ===================================================================
> --- public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java	2010-04-09 12:48:20 UTC (rev 48578)
> +++ public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node/NodeResource.java	2010-04-09 13:06:14 UTC (rev 48579)
> @@ -61,6 +61,12 @@
>      /**
>       *
>       */
> +    public NodeResource() {
> +    }
> +
> +    /**
> +     *
> +     */
>      public ViewDescriptor[] getViewDescriptors() {
>          return null;
>      }
> @@ -137,10 +143,10 @@
>       */
>      public OutputStream getOutputStream() throws Exception {
>          log.error("TODO: Use existsNode() method!");
> -        if (!getRepository().existsNode(getPath())) {
> +        if (!getRealm().getRepository().existsNode(getPath())) {
>              // TODO: create node recursively ...
>              log.error("TODO: Use getNode() method!");
> -            getRepository().getNode(new org.wyona.commons.io.Path(getPath()).getParent().toString()).addNode(new org.wyona.commons.io.Path(getPath()).getName().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
> +            getRealm().getRepository().getNode(new org.wyona.commons.io.Path(getPath()).getParent().toString()).addNode(new org.wyona.commons.io.Path(getPath()).getName().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
>          }
>          return getNode().getOutputStream();
>      }
> @@ -189,7 +195,7 @@
>                  revisionInfos[i] = new RevisionInformation(revisions[i]);
>              }
>              if (revisions.length > 0) {
> -                log.warn("Node \"" + getPath() + "\" does not seem to have any revisions! The repository \"" + getRepository() + "\"  might not support revisions!");
> +                log.warn("Node \"" + getPath() + "\" does not seem to have any revisions! The repository \"" + getRealm().getRepository() + "\"  might not support revisions!");
>              }
>              return revisionInfos;
>          }
> @@ -262,7 +268,7 @@
>      }
>  
>      public boolean exists() throws Exception {
> -        return getRepository().existsNode(getPath());
> +        return getRealm().getRepository().existsNode(getPath());
>      }
>  
>      /**
> @@ -307,7 +313,7 @@
>       */
>      public void create(HttpServletRequest request) {
>          try {
> -            Repository repo = getRepository();
> +            Repository repo = getRealm().getRepository();
>  
>              if (request instanceof HttpRequest) {
>                  HttpRequest yanelRequest = (HttpRequest)request;
> @@ -316,7 +322,7 @@
>                      if (parameters.hasMoreElements()) {
>                          String name = (String) parameters.nextElement();
>  
> -                        Node newNode = org.wyona.yarep.util.YarepUtil.addNodes(repo, getPath().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
> +                        Node newNode = org.wyona.yanel.core.util.YarepUtil.addNodes(repo, getPath().toString(), org.wyona.yarep.core.NodeType.RESOURCE);
>                          OutputStream output = newNode.getOutputStream();
>                          InputStream is = yanelRequest.getInputStream(name);
>                          Streams.copy(is, output, true);
> @@ -588,23 +594,13 @@
>                  path = getResourceConfigProperty("src");
>              }
>              try {
> -                return getRepository().getNode(path);
> +                return getRealm().getRepository().getNode(path);
>              } catch (org.wyona.yarep.core.NoSuchNodeException e) {
>                  throw new org.wyona.yanel.core.ResourceNotFoundException(path);
> -                //throw new org.wyona.yanel.core.ResourceNotFoundException(path, getRealm(), getRepository());
> +                //throw new org.wyona.yanel.core.ResourceNotFoundException(path, getRealm(), getRealm().getRepository());
>              }
>          } catch (Exception e) {
>              throw new org.wyona.yanel.core.ResourceNotFoundException(e);
>          }
>      }
> -
> -    private Repository getRepository() throws Exception {
> -        String repositoryID = getResourceConfigProperty("content-repository-id");
> -        if (log.isDebugEnabled()) log.debug("repositoryID: "+repositoryID); //FIXME
> -        if (repositoryID == null) {
> -            return getRealm().getRepository();
> -        }
> -        Repository repository = getRealm().getRepository(repositoryID);
> -        return repository;
> -    }
>  }
>
>   

From michael.wechner at wyona.com  Fri Apr  9 16:24:26 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 16:41:00 2010
Subject: [Yanel-dev] Problems with singleton
Message-ID: <4BBF389A.5030705@wyona.com>

Hi

I recently had another experience re a singleton which was intended to 
be a good idea re avoiding
concurrent access, but caused problems within a multi-realm environment.

For example if you implement the sitetree as a singleton and two realms 
are using the same implementation,
then the first sitetree which will be loaded will rule and hence you 
will have strange behaviour within the second realm
or rather you will access the sitetree of the first realm also within 
the second realm.

It seems to me that many of us developers forget that people might want 
to setup the same realm multiple times,  hence
I wanted to make you aware of this.

Thanks

Michi


From guillaume.deflache at wyona.com  Fri Apr  9 16:25:49 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Fri Apr  9 16:41:02 2010
Subject: [Yanel-dev] separating content from application code &
	configuration
	(or getting rid of "app" directory in repository e.g. data/app/)
In-Reply-To: <4B02BB63.1000702@wyona.com>
References: <4B02BB63.1000702@wyona.com>
Message-ID: <4BBF38ED.3060800@wyona.com>

Guillaume D?flache schrieb:
> At the moment in most (all?) applications using Yanel a recurring 
> pattern is creating an 'app' directory in realms' data repositories to 
> hold all sort of things having nothing to do with content like:
> - browser assets (CSS, JS, image, etc. files)
> - realm's code (XSLT, Jelly files)
> - administrative content (admin doc, help, ...)
> - configuration files (I18N, other realm-specific config).
> 
> This is an issue because this complicates realm code updates for the 
> application/realm administrator:
> - as the realms' data repo primarily contains the content, it is in 
> principle "owned" by the administrator, not by the developers
> - HOWEVER when a new version of the realm code has to be installed, the 
> administrator cannot simply points to the new data repo in the realm 
> configuration, as it does not contain his current content, so it has to 
> copy the newly delivered 'app' dir to its current data repo (which BTW 
> can be highly non-trivial if the later is not file-based!!!)
> - BUT the app dir also contain some configuration files, e.g. [almost] 
> always I18N (which the administrator may have chosen to own), so the 
> administrator's original one cannot be blindly overwritten!
> 
> So what we have been doing as of now is to keep a manual list for every 
> release in some changelog file of all files in the "app" directory that 
> needs to be copied to fully update the realm code. And until recently no 
> one cared to also note there the files that were no longer needed, and 
> whose presence already confused some administrators.
> 
> 
> Ideas on how to gradually improve this:
> 
> 1) use the VCS to get the list of changes in the "app" dir, similar to 
> svn log -rPREVIOUS_RELEASE:NEXT_RELEASE data/app/ probably: this would 
> relieve us of the burden to think about updating the changelog at each 
> commit and checking and updating it manually just before each release
> - this also gives use the deleted files
> - if commits are functional ones and reference a bug number as they 
> should, the intent of the addition or removal of these files should be 
> clear, and anyway I still think administrators should not bother at 
> least for non-configuration files
> 
> 2) move configuration stuff (incl. I18N) out of the "app" dir, for 
> instead into a "conf" dir: this would allow the "app"-dir-copy solution
> 
> 3) move code-related stuff out of the data-repo: this would allow the 
> administrator to have almost nothing to do on realm upgrades, except 
> checking for changes in configuration files, of which there should be a 
> known and short list: for this we should
> 3.1) use the 'rtyanelhdocs' protocol to move code-related files to the 
> only resource-type they most of the time belong to
> 3.2) and as some are truly global to the realm (e.g. global.xsl) we 
> should introduce a new 'realmhtdocs' protocol(*) similar to the 
> 'rthdocs' one, which would also need to be proxyied thru HTTP under 
> <realm-URL>/<Yanel-reserved-prefix>/realm/... for access by browsers I 
> guess
> 
> 4) move configuration stuff out of the data-repo: this would allow the 
> administrator to have nothing to do on realm upgrades (after initially 
> overriding and fine-tuning of the configuration), except upgrading its 
> own configuration to use new features (as configuration should be 
> backward-compatible): for this we should
> 4.1) allow to configure custom repositories (this notion already exists 
> in the Realm API, see 
> <http://yanel.org/javadoc/org/wyona/yanel/core/map/Realm.html#getRepository(java.lang.String)> 
> and the 'yanelrepo' protocol seems to support it, but AFAICR there are 
> still some minor implementation issues)
> 4.2) add a new custom repository for configuration(*) and use it!
> 
> (*): Or we could at least use a dedicated RC file to catch access to all 
> these files at the URL level
> 
> 
> IMHO:
> 1) could be followed immediately.
> 2) is only a relatively short refactoring (say 2-4 hours per realm maybe 
> depending on the number of configuration files), but this needs 
> communication with the application administrators and their agreement if 
> they have some related written/automated procedures on their end.
> I am doing regularly 3.1) as part of ongoing refactoring, it may be 
> tricky for custom resource-types if they do not use the Yanel resolver 
> though
> 3.2) should be a one- or two-day task given it's a slight modification 
> of existing but tricky code.
> 4.1) should be a one- or two-day task since some debugging and 
> refactoring may also be needed
> 4.2) is simply configuration work once 4.1) is done.
> 
> 
> WDYT?
> 
> 
> Cheers,
>    Guillaume

This is now being discussed further at 
http://lists.wyona.org/pipermail/yanel-development/2010-April/004667.html
From guillaume.deflache at wyona.com  Fri Apr  9 16:27:15 2010
From: guillaume.deflache at wyona.com (=?UTF-8?B?R3VpbGxhdW1lIETDqWZsYWNoZQ==?=)
Date: Fri Apr  9 16:41:03 2010
Subject: [Yanel-dev] Re:
	[Yanel-commits]	rev	48566	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <4BBF2B10.9000908@wyona.com>
References: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>	<4BBE56F6.1010201@wyona.com>	<4BBED0A9.4000005@wyona.com>
	<4BBF2B10.9000908@wyona.com>
Message-ID: <4BBF3943.3050109@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Hi!
>>
>> Michael Wechner schrieb:
>>> Dear Guillaume
>>>
>>> As discussed before lets please discuss such changes beforehand:
>>>
>>> - Explain what you intend to do and how you want to use this
>>
>> I already explain the intent months ago in "[Yanel-dev] separating 
>> content from application code &  configuration (or getting rid of 
>> "app" directory in repository e.g. data/app/)" 
>> http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
>> on which I had no feedback.
> 
> just remind people once again

OK.


>> The change compared to that message is that I found an even simpler 
>> solution for the "3.2)" point there that is fully backward-compatible 
>> and IMHO does no harm, so I just committed "out of enthousiasm", sorry...
>> Maybe I should reply to my own message and explain this new solution 
>> there?
> 
> please do

I link to this thread from there instead as the discussion continues here.

> 
>>> - Make examples/document it
>>
>> I will be glad to do that once we agree on the details like the name 
>> of the RC property.
>> BTW I already tested that on the project I am currently starting, 
>> works great.
>> We can probably illustrate it on any public realm that uses a 
>> "data/app"-like directory, and maybe add a HTTPUnit or Canoo test for 
>> that while we are at it.
> 
> yes, you should do that

As agreed with Michi, he will revert the change in Yanel and I will add 
the modified file resource-type in my own project, so for now I can not 
write a public test specifically for that feature.


>>> Maybe there are other possibilities to acomplish what you  want to 
>>> acomplish.
>>
>> Maybe, but nobody stepped up to suggest any so far,
> 
> Well, I think it's better to use a protocol:
> 
> http://documentation.yanel.wyona.org/wiki/wiki/Unstructured%20Points
> 
> e.g.
> 
> src="yanelrepo:REALM_ID:REPO_ID:/index.html"
> 
> and in your particular case
> 
> src="yanelrepo::app:/index.html"
> 
> WDYT?

That's also what I initially had in mind for 3.2) but there are problems 
with this approach:
- all protocols do not resolve any URL to a writable resource:
   - that may mislead people into thinking any protocol may be used
   - one would have to special-case on some protocols, and it is not 
clear to me what the ramifications could be
- it will only work for one file per RC: as one needs a full URL to 
resolve it to something, one cannot for example easily map 
http://localhost:8080/yanel/my-realm/app/** to $MY_REALM_DIR/htdocs/** 
which is what I'd like to do for all static content (CSS, JS, ...)


>> and I did not want to start a project with a "data/app" directory ever 
>> again, because we all know it cause lots of deployment problems
> 
> you mean because of the CHANGE_LOG?

Among others outlined in 
http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
yes.

Generally I would like to really be able to switch content repositories 
(for deployment in test or production environments) only by editing the 
corresponding repository configuration file, and without copying files.
If neither application code nor additional configuration files are in 
the content repository, this should be doable.


> If you have files within a separate repository, you will still have to 
> synchronize these repositories and chances
> are there that people do make changes on the productive environment. So 

Application code files should not need to be changed on the production 
environment, so at least moving them away should reduce the need to sync 
to only real content (and configuration if we do not decide to move it 
away as well).


> I don't think the problems
> will go away completely, but I agree it will make it easier

There are probably some other kinds of files I did not think about, but 
I really think taking care of the current large majority of misplaced 
files will already help a lot.


>> (as you reminded me lately when I introduced a "data/admin" directory 
>> for storing mockup XHTML pages).
> 
> I think that's a different case

I think it may be solved by the same enhancements, but I guess it's a 
matter of POV.
From michael.wechner at wyona.com  Fri Apr  9 16:58:34 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr  9 17:12:02 2010
Subject: [Yanel-dev]
	Re:	[Yanel-commits]	rev	48566	-	public/yanel/trunk/src/resources/file/src/java/org/wyona/yanel/impl/resources/node
In-Reply-To: <4BBF3943.3050109@wyona.com>
References: <201004081747.o38HlXsh027419@cvs-extra.wyona.com>	<4BBE56F6.1010201@wyona.com>	<4BBED0A9.4000005@wyona.com>	<4BBF2B10.9000908@wyona.com>
	<4BBF3943.3050109@wyona.com>
Message-ID: <4BBF409A.80102@wyona.com>

Guillaume D?flache wrote:
>
>>
>> yes, you should do that
>
> As agreed with Michi, he will revert the change in Yanel and I will 
> add the modified file resource-type in my own project, so for now I 
> can not write a public test specifically for that feature.

you can write a test within your custom project and also a test within 
the usecase-realm using the src property (I think
such a test does not exist yet)



>
>
>>>> Maybe there are other possibilities to acomplish what you  want to 
>>>> acomplish.
>>>
>>> Maybe, but nobody stepped up to suggest any so far,
>>
>> Well, I think it's better to use a protocol:
>>
>> http://documentation.yanel.wyona.org/wiki/wiki/Unstructured%20Points
>>
>> e.g.
>>
>> src="yanelrepo:REALM_ID:REPO_ID:/index.html"
>>
>> and in your particular case
>>
>> src="yanelrepo::app:/index.html"
>>
>> WDYT?
>
> That's also what I initially had in mind for 3.2) but there are 
> problems with this approach:
> - all protocols do not resolve any URL to a writable resource:
>   - that may mislead people into thinking any protocol may be used
>   - one would have to special-case on some protocols, and it is not 
> clear to me what the ramifications could be
> - it will only work for one file per RC: as one needs a full URL to 
> resolve it to something, one cannot for example easily map 
> http://localhost:8080/yanel/my-realm/app/** to $MY_REALM_DIR/htdocs/** 
> which is what I'd like to do for all static content (CSS, JS, ...)


agreed. Let me think about that some more ....



>
>
>>> and I did not want to start a project with a "data/app" directory 
>>> ever again, because we all know it cause lots of deployment problems
>>
>> you mean because of the CHANGE_LOG?
>
> Among others outlined in 
> http://lists.wyona.org/pipermail/yanel-development/2009-November/004154.html 
> yes.
>
> Generally I would like to really be able to switch content 
> repositories (for deployment in test or production environments) only 
> by editing the corresponding repository configuration file, and 
> without copying files.
> If neither application code nor additional configuration files are in 
> the content repository, this should be doable.

the borders are not always clear
>
>
>> If you have files within a separate repository, you will still have 
>> to synchronize these repositories and chances
>> are there that people do make changes on the productive environment. So 
>
> Application code files should not need to be changed on the production 
> environment, 

people just do it, trust me ;-)

For example XSLTs (or Jelly) often contain content which is not 
editable, but at some point people want to change it



> so at least moving them away should reduce the need to sync to only 
> real content (and configuration if we do not decide to move it away as 
> well).
>
>
>> I don't think the problems
>> will go away completely, but I agree it will make it easier
>
> There are probably some other kinds of files I did not think about, 
> but I really think taking care of the current large majority of 
> misplaced files will already help a lot.

agreed

Cheers

Michi
>
>
>>> (as you reminded me lately when I introduced a "data/admin" 
>>> directory for storing mockup XHTML pages).
>>
>> I think that's a different case
>
> I think it may be solved by the same enhancements, but I guess it's a 
> matter of POV.

From guillaume.deflache at wyona.com  Fri Apr  9 19:38:48 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Fri Apr  9 19:52:05 2010
Subject: [Yanel-dev] exception handling in Ant tasks
Message-ID: <4BBF6628.9070000@wyona.com>

Could we stop logging exceptions in Ant tasks and simply rethrow them as 
build exceptions (org.apache.tools.ant.BuildException).
The Ant tasks's "execute" entry-point method that every task shall 
implement already throws this type of exception so by only (re)throwing 
it here and in other methods:
- the stacktraces are simpler because they don't get displayed and/or 
wrapped many times
- one does not litter one's code with a lot of exception handling, the 
only needed code is "throws BuildException" appended on all methods 
signatures, or even "throws Exception" with only a exception wrapper 
from Exception to BuildException on the "execute" method
- errors ultimately get catched by Ant anyway, which already does a 
great job at showing full stacktraces, *and failing the whole build*


I am asking because I spent quite some time wondering why my 
resource-type was not found, it was only because my project's 
resource-types.xml was not well-formed and it just got ignored because 
of these issues (culprit here being Yanel's 
src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)...

Better fail fast than silently!!!
From michael.wechner at wyona.com  Sat Apr 10 07:50:21 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sat Apr 10 08:03:49 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BBF6628.9070000@wyona.com>
References: <4BBF6628.9070000@wyona.com>
Message-ID: <4BC0119D.4070803@wyona.com>

Guillaume D?flache wrote:
> Could we stop logging exceptions in Ant tasks and simply rethrow them 
> as build exceptions (org.apache.tools.ant.BuildException).
> The Ant tasks's "execute" entry-point method that every task shall 
> implement already throws this type of exception so by only 
> (re)throwing it here and in other methods:
> - the stacktraces are simpler because they don't get displayed and/or 
> wrapped many times
> - one does not litter one's code with a lot of exception handling, the 
> only needed code is "throws BuildException" appended on all methods 
> signatures, or even "throws Exception" with only a exception wrapper 
> from Exception to BuildException on the "execute" method
> - errors ultimately get catched by Ant anyway, which already does a 
> great job at showing full stacktraces, *and failing the whole build*
>
>
> I am asking because I spent quite some time wondering why my 
> resource-type was not found, it was only because my project's 
> resource-types.xml was not well-formed and it just got ignored because 
> of these issues (culprit here being Yanel's 
> src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)...
>
> Better fail fast than silently!!!

I understand your frustration, but you need to be more specific by 
providing a patch of the MergeResourceTypesConfigsTask class
re which errors you want to throw and give specific examples when these 
errors are thrown, e.g. resource-types.xml is not well-formed.

The case that your resource-types.xml is not found is NOT a build error, 
because a realm does not have to have such a file.
That's rather a matter of documentation. Also you could enhance this 
documentation, e.g.

http://www.yanel.org/en/documentation/configuration/resource-types_xml.html
http://www.yanel.org/en/documentation/create-new-resource.html

Thanks

Michi

From michael.wechner at wyona.com  Sat Apr 10 10:14:59 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sat Apr 10 10:29:37 2010
Subject: [Yanel-dev] Problem re importing XSLTs
Message-ID: <4BC03383.5040905@wyona.com>

Hi

Within the from scratch realm we have implemented a layout switch by 
using the yanelresource protocol

<yanel:property name="xslt" value="yanelresource:/my-global.xsl"/>

which works fine, but it seems when such an XSLT is calling another XSLT 
via import, then it fails.

If I find the time then I will investigate some more.

Thanks

Michi
From michael.wechner at wyona.com  Sat Apr 10 14:10:56 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sat Apr 10 14:24:24 2010
Subject: [Yanel-dev] 404 -> page creation (if Yanel toolbar enabled)
Message-ID: <4BC06AD0.4010107@wyona.com>

Hi

During a private discussion with Bruno we realized it would be nice that 
in the case of a 404 and if the Yanel toolbar is
enabled, then the 404 screen would provide links to either create this 
page or create a redirect (in the sense of this page has moved)

WDYT?

Cheers

Michi
From mehmet.birgi at wyona.com  Sun Apr 11 14:56:18 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Sun Apr 11 15:09:49 2010
Subject: [Yanel-dev] 404 -> page creation (if Yanel toolbar enabled)
In-Reply-To: <4BC06AD0.4010107@wyona.com>
References: <4BC06AD0.4010107@wyona.com>
Message-ID: <4BC1C6F2.9030701@wyona.com>



On 10.4.10 14:10 , Michael Wechner wrote:
> Hi
>
> During a private discussion with Bruno we realized it would be nice 
> that in the case of a 404 and if the Yanel toolbar is
> enabled, then the 404 screen would provide links to either create this 
> page or create a redirect (in the sense of this page has moved)
>
> WDYT?
+1
>
> Cheers
>
> Michi
From mehmet.birgi at wyona.com  Sun Apr 11 15:01:36 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Sun Apr 11 15:15:06 2010
Subject: [Yanel-dev] Resource creation
Message-ID: <4BC1C830.2000500@wyona.com>

When a new resource is created via "build.sh new-resource-type", it 
might be nice to set the svn:ignore property for the build directory 
automatically.

wdyt?
From bruno.vonrotz at wyona.com  Sun Apr 11 20:43:47 2010
From: bruno.vonrotz at wyona.com (Bruno von Rotz)
Date: Sun Apr 11 20:58:31 2010
Subject: [Yanel-dev] A couple of issues identified when working with Yanel
Message-ID: <4BC21863.5060303@wyona.com>

An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/20100411/596ec714/attachment.htm
From michael.wechner at wyona.com  Sun Apr 11 21:15:18 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sun Apr 11 21:28:58 2010
Subject: [Yanel-dev] Resource creation
In-Reply-To: <4BC1C830.2000500@wyona.com>
References: <4BC1C830.2000500@wyona.com>
Message-ID: <4BC21FC6.1070607@wyona.com>

Mehmet Birgi wrote:
> When a new resource is created via "build.sh new-resource-type", it 
> might be nice to set the svn:ignore property for the build directory 
> automatically.
>
> wdyt?

if you download a source snapshot, then you do not have SVN.

Also please be aware that one does often move the directory of the newly 
created resource type.

Hence I would rather add this to the documentation than make this automagic.

Cheers

Michi

From mehmet.birgi at wyona.com  Sun Apr 11 21:22:58 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Sun Apr 11 21:38:45 2010
Subject: [Yanel-dev] Resource creation
In-Reply-To: <4BC21FC6.1070607@wyona.com>
References: <4BC1C830.2000500@wyona.com> <4BC21FC6.1070607@wyona.com>
Message-ID: <4BC22192.1070307@wyona.com>



On 11.4.10 21:15 , Michael Wechner wrote:
> Mehmet Birgi wrote:
>> When a new resource is created via "build.sh new-resource-type", it
>> might be nice to set the svn:ignore property for the build directory
>> automatically.
>>
>> wdyt?
>
> if you download a source snapshot, then you do not have SVN.
>
> Also please be aware that one does often move the directory of the newly
> created resource type.
>
> Hence I would rather add this to the documentation than make this
> automagic.

yes, you're right of course. i'll add it to the docs.

cheers,

memo

>
> Cheers
>
> Michi
>

-- 
Mehmet Birgi
www.wyona.com
From michael.wechner at wyona.com  Sun Apr 11 21:25:18 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sun Apr 11 21:39:01 2010
Subject: [Yanel-dev] A couple of issues identified when working with Yanel
In-Reply-To: <4BC21863.5060303@wyona.com>
References: <4BC21863.5060303@wyona.com>
Message-ID: <4BC2221E.5030503@wyona.com>

Bruno von Rotz wrote:
> Team,
> here are a couple of issues I came across when working with a new 
> instance of yanel:
>
> 1) login seems not to properly work, first attempt is refused, second 
> attempt is good without changing anything on the screen. Might be an 
> issue with browser settings

I also experience this behaviour "sometimes", whereas it might also be a 
reverse proxy issue and one has to debug/reproduce it
within a controlled environment
> 2) toolbar disappears when chaning the language (e->d), after hitting 
> refresh it comes up - might be an issue with local caching in the browser

yes, whereas I think we discussed this before and one way of solving it 
would be to return no-cache if the toolbar is on.
> 3) special characters (Swiss ?, ?, ?) seem to not be treated correctly 
> on the "add new page" functionality. When you enter a "?" you receive 
> some strange letter with another special character as a result in the 
> header (h1) of the new page

you mean when entering the title?
> 4) pages created in a specific "folder" seem to not show up in tinymce 
> when you want to add a link to them, if they include an "_" 
> (underline) character (example 
> http://test.wyona.com/de/CMS_migration.html)

can you explain this a bit more, because I don't really understand what 
you tried to accomplish?

> 5) There are a number of unnecessairy confirms or "in-between-steps". 
> For example, if you add a new page, why wouldn't you get directly into 
> edit mode? 

because it is not clear which editing tool you might want to use. See 
the recent discussion with Memo.

Another related question was:

Also why not edit right before creation? (like you already do with the 
title)


> Or, after you have edited a page, why do you need a "has been saved" page?

it depends what you are creating. In the case of an HTML page, you could 
be redirected to the new page,
but in the case of uploading an asset?
> I guess this goes back to some of the usability discussions we had in 
> the past

yes. Also the problem is as always generic versus specific.

I would be glad if you could create Bugzilla entries for the above items 
and describe them as detailed as possible.

Thanks

Michi
>
> That's it for the time being. Bruno
>

From michael.wechner at wyona.com  Sun Apr 11 22:48:55 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sun Apr 11 23:02:32 2010
Subject: [Yanel-dev] Resource creation
In-Reply-To: <4BC22192.1070307@wyona.com>
References: <4BC1C830.2000500@wyona.com> <4BC21FC6.1070607@wyona.com>
	<4BC22192.1070307@wyona.com>
Message-ID: <4BC235B7.7020506@wyona.com>

Mehmet Birgi wrote:
>
>
> On 11.4.10 21:15 , Michael Wechner wrote:
>> Mehmet Birgi wrote:
>>> When a new resource is created via "build.sh new-resource-type", it
>>> might be nice to set the svn:ignore property for the build directory
>>> automatically.
>>>
>>> wdyt?
>>
>> if you download a source snapshot, then you do not have SVN.
>>
>> Also please be aware that one does often move the directory of the newly
>> created resource type.
>>
>> Hence I would rather add this to the documentation than make this
>> automagic.
>
> yes, you're right of course. i'll add it to the docs.

thanks very much

Michi
>
> cheers,
>
> memo
>
>>
>> Cheers
>>
>> Michi
>>
>

From guillaume.deflache at wyona.com  Mon Apr 12 08:53:48 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 09:07:20 2010
Subject: [Yanel-dev] 404 -> page creation (if Yanel toolbar enabled)
In-Reply-To: <4BC06AD0.4010107@wyona.com>
References: <4BC06AD0.4010107@wyona.com>
Message-ID: <4BC2C37C.1090003@wyona.com>

Michael Wechner schrieb:
> Hi

Hi!


> During a private discussion with Bruno we realized it would be nice that 
> in the case of a 404 and if the Yanel toolbar is
> enabled, then the 404 screen would provide links to either create this 
> page or create a redirect (in the sense of this page has moved)

We had already had similar ideas: 
http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6941
The idea to also allow to create a redirect is new though, and a nice 
one: perhaps one should display the sitetree at once to allow looking 
for a similarly-named page?


> WDYT?

I still think it's a good idea! ;)


Cheers,
    Guillaume
From guillaume.deflache at wyona.com  Mon Apr 12 09:05:16 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 09:18:48 2010
Subject: [Yanel-dev] Problem re importing XSLTs
In-Reply-To: <4BC03383.5040905@wyona.com>
References: <4BC03383.5040905@wyona.com>
Message-ID: <4BC2C62C.1090306@wyona.com>

Michael Wechner schrieb:
> Hi
> 
> Within the from scratch realm we have implemented a layout switch by 
> using the yanelresource protocol
> 
> <yanel:property name="xslt" value="yanelresource:/my-global.xsl"/>

On which base resource-type is the resource-type you use based on? 
BasicXMLResource?


> which works fine, but it seems when such an XSLT is calling another XSLT 
> via import, then it fails.

I used the 'rthtdocs' protocol on 'xsl:include' elements quite a lot in 
an XSLT on my last Wyona project, and it worked great (I can send you 
some more specific pointers privately).
Maybe the problems are specific to the 'yanelresource' protocol? At 
least the generic resolving part seems to work great.
From guillaume.deflache at wyona.com  Mon Apr 12 09:25:54 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 09:39:57 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BC0119D.4070803@wyona.com>
References: <4BBF6628.9070000@wyona.com> <4BC0119D.4070803@wyona.com>
Message-ID: <4BC2CB02.8020301@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Could we stop logging exceptions in Ant tasks and simply rethrow them 
>> as build exceptions (org.apache.tools.ant.BuildException).
>> The Ant tasks's "execute" entry-point method that every task shall 
>> implement already throws this type of exception so by only 
>> (re)throwing it here and in other methods:
>> - the stacktraces are simpler because they don't get displayed and/or 
>> wrapped many times
>> - one does not litter one's code with a lot of exception handling, the 
>> only needed code is "throws BuildException" appended on all methods 
>> signatures, or even "throws Exception" with only a exception wrapper 
>> from Exception to BuildException on the "execute" method
>> - errors ultimately get catched by Ant anyway, which already does a 
>> great job at showing full stacktraces, *and failing the whole build*
>>
>>
>> I am asking because I spent quite some time wondering why my 
>> resource-type was not found, it was only because my project's 
>> resource-types.xml was not well-formed and it just got ignored because 
>> of these issues (culprit here being Yanel's 
>> src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)...
>>
>> Better fail fast than silently!!!
> 
> I understand your frustration, but you need to be more specific by 
> providing a patch of the MergeResourceTypesConfigsTask class

Shall I do that now?
The modification is pretty systematic as I tried to explain: remove all 
"try { ...} catch" constructs and make all methods throws Exception. 
Only the 'execute' method's contract will only allow BuildException to 
be thrown so wrap Exception to BuildException there.


> re which errors you want to throw and give specific examples when these 
> errors are thrown, e.g. resource-types.xml is not well-formed.

I already gave an example:
make your realm's resource-types.xml not well-formed => the build will 
not break
Sadly you cannot provide an example log since AFAICS the errors do not 
show up on the console, at least not at the log level I usually run Ant 
(with ANT_ARGS=-q).
Where are the log4j logs supposed to be written to in this case? I am 
not sure which log4j properties file gets read here.


> The case that your resource-types.xml is not found is NOT a build error, 
> because a realm does not have to have such a file.

It was a misformulation from my side, I should have written
"spent quite some time wondering why my resource-type was not taken into 
account" instead of "spent quite some time wondering why my 
resource-type was not found".
I am aware this file is not mandatory.


> That's rather a matter of documentation. Also you could enhance this 
> documentation, e.g.
> 
> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html
> http://www.yanel.org/en/documentation/create-new-resource.html

We certainly could expand 
http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
with a rationale for the example and at 
$YANELHOME/conf/local/local.resource-type.xml in the "Register New 
Resource" section suggest to use $REALM_DIR/resource-types.xml instead 
of $YANEL_HOME/conf/local/local.resource-types.xml

Should I do that now?
From michael.wechner at wyona.com  Mon Apr 12 09:27:40 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 12 09:41:11 2010
Subject: [Yanel-dev] Problem re importing XSLTs
In-Reply-To: <4BC2C62C.1090306@wyona.com>
References: <4BC03383.5040905@wyona.com> <4BC2C62C.1090306@wyona.com>
Message-ID: <4BC2CB6C.7090305@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Hi
>>
>> Within the from scratch realm we have implemented a layout switch by 
>> using the yanelresource protocol
>>
>> <yanel:property name="xslt" value="yanelresource:/my-global.xsl"/>
>
> On which base resource-type is the resource-type you use based on? 
> BasicXMLResource?

on nothing

src/realms/from-scratch-realm-template/res-types/layoutselector/src/java/org/wyona/yanel/impl/resources/layoutselector/LayoutSelector.java

and maybe that's the problem, because it seems to be a copy of another 
resource. I have committed it though and my bad that I didn't review it 
properly  :-(
>
>
>> which works fine, but it seems when such an XSLT is calling another 
>> XSLT via import, then it fails.
>
> I used the 'rthtdocs' protocol on 'xsl:include' elements quite a lot 
> in an XSLT on my last Wyona project, and it worked great (I can send 
> you some more specific pointers privately).
> Maybe the problems are specific to the 'yanelresource' protocol? At 
> least the generic resolving part seems to work great.

thanks for these hints. I will first cleanup this layoutselector 
resource though.

Thanks

Michi

From michael.wechner at wyona.com  Mon Apr 12 09:44:16 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 12 09:57:51 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BC2CB02.8020301@wyona.com>
References: <4BBF6628.9070000@wyona.com> <4BC0119D.4070803@wyona.com>
	<4BC2CB02.8020301@wyona.com>
Message-ID: <4BC2CF50.8080700@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Guillaume D?flache wrote:
>>> Could we stop logging exceptions in Ant tasks and simply rethrow 
>>> them as build exceptions (org.apache.tools.ant.BuildException).
>>> The Ant tasks's "execute" entry-point method that every task shall 
>>> implement already throws this type of exception so by only 
>>> (re)throwing it here and in other methods:
>>> - the stacktraces are simpler because they don't get displayed 
>>> and/or wrapped many times
>>> - one does not litter one's code with a lot of exception handling, 
>>> the only needed code is "throws BuildException" appended on all 
>>> methods signatures, or even "throws Exception" with only a exception 
>>> wrapper from Exception to BuildException on the "execute" method
>>> - errors ultimately get catched by Ant anyway, which already does a 
>>> great job at showing full stacktraces, *and failing the whole build*
>>>
>>>
>>> I am asking because I spent quite some time wondering why my 
>>> resource-type was not found, it was only because my project's 
>>> resource-types.xml was not well-formed and it just got ignored 
>>> because of these issues (culprit here being Yanel's 
>>> src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)... 
>>>
>>>
>>> Better fail fast than silently!!!
>>
>> I understand your frustration, but you need to be more specific by 
>> providing a patch of the MergeResourceTypesConfigsTask class
>
> Shall I do that now?
> The modification is pretty systematic as I tried to explain: remove 
> all "try { ...} catch" constructs and make all methods throws 
> Exception. Only the 'execute' method's contract will only allow 
> BuildException to be thrown so wrap Exception to BuildException there.

rather not, because I do not think we should "replace" *all* try/catch  
statements, but we really need to spend time on each case.

I will now implement the case of not well-formed resource-types.xml

>
>
>> re which errors you want to throw and give specific examples when 
>> these errors are thrown, e.g. resource-types.xml is not well-formed.
>
> I already gave an example:
> make your realm's resource-types.xml not well-formed => the build will 
> not break

it didn't sound like this was the only case/example



> Sadly you cannot provide an example log since AFAICS the errors do not 
> show up on the console, at least not at the log level I usually run 
> Ant (with ANT_ARGS=-q).

maybe you should consider running without -q

> Where are the log4j logs supposed to be written to in this case?

I think it's standard output/command line

> I am not sure which log4j properties file gets read here.

I am not sure either and would have to check


>
>> The case that your resource-types.xml is not found is NOT a build 
>> error, because a realm does not have to have such a file.
>
> It was a misformulation from my side, I should have written
> "spent quite some time wondering why my resource-type was not taken 
> into account" instead of "spent quite some time wondering why my 
> resource-type was not found".
> I am aware this file is not mandatory.

ok, maybe you want to add this to the documentation
>
>
>> That's rather a matter of documentation. Also you could enhance this 
>> documentation, e.g.
>>
>> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
>>
>> http://www.yanel.org/en/documentation/create-new-resource.html
>
> We certainly could expand 
> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
> with a rationale for the example and at 
> $YANELHOME/conf/local/local.resource-type.xml in the "Register New 
> Resource" section suggest to use $REALM_DIR/resource-types.xml instead 
> of $YANEL_HOME/conf/local/local.resource-types.xml
>
> Should I do that now?

yes, that would be great

Thanks

Michi

From michael.wechner at wyona.com  Mon Apr 12 09:59:22 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 12 10:12:54 2010
Subject: [Yanel-dev] A couple of issues identified when working with Yanel
In-Reply-To: <4BC21863.5060303@wyona.com>
References: <4BC21863.5060303@wyona.com>
Message-ID: <4BC2D2DA.3090208@wyona.com>

Bruno von Rotz wrote:
> 4) pages created in a specific "folder" seem to not show up in tinymce 
> when you want to add a link to them, if they include an "_" 
> (underline) character (example 
> http://test.wyona.com/de/CMS_migration.html)


IIUC you did the following:

- Browse to some XHTML page
- Enable Yanel Toolbar
- Open Page with TinyMCE
- Select a text
- Select the link widget
- Browse within the sitetree to select a link
- BUG: All files/nodes are displayed, except CMS_migration.html

right?

Thanks

Michi

From michael.wechner at wyona.com  Mon Apr 12 10:01:57 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 12 10:15:28 2010
Subject: [Yanel-dev] A couple of issues identified when working with Yanel
In-Reply-To: <4BC21863.5060303@wyona.com>
References: <4BC21863.5060303@wyona.com>
Message-ID: <4BC2D375.5090209@wyona.com>

Bruno von Rotz wrote:
> Team,
> here are a couple of issues I came across when working with a new 
> instance of yanel:
>
> 1) login seems not to properly work, first attempt is refused, second 
> attempt is good without changing anything on the screen. Might be an 
> issue with browser settings
I have tested it once again and it works locally without a problem, but 
not with a reverse proxy in between.
I think this is a revers proxy problem and I need to debug it.

Cheers

Michi

From guillaume.deflache at wyona.com  Mon Apr 12 10:29:17 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 10:42:50 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BC2CF50.8080700@wyona.com>
References: <4BBF6628.9070000@wyona.com>
	<4BC0119D.4070803@wyona.com>	<4BC2CB02.8020301@wyona.com>
	<4BC2CF50.8080700@wyona.com>
Message-ID: <4BC2D9DD.5040904@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Michael Wechner schrieb:
>>> Guillaume D?flache wrote:
>>>> Could we stop logging exceptions in Ant tasks and simply rethrow 
>>>> them as build exceptions (org.apache.tools.ant.BuildException).
>>>> The Ant tasks's "execute" entry-point method that every task shall 
>>>> implement already throws this type of exception so by only 
>>>> (re)throwing it here and in other methods:
>>>> - the stacktraces are simpler because they don't get displayed 
>>>> and/or wrapped many times
>>>> - one does not litter one's code with a lot of exception handling, 
>>>> the only needed code is "throws BuildException" appended on all 
>>>> methods signatures, or even "throws Exception" with only a exception 
>>>> wrapper from Exception to BuildException on the "execute" method
>>>> - errors ultimately get catched by Ant anyway, which already does a 
>>>> great job at showing full stacktraces, *and failing the whole build*
>>>>
>>>>
>>>> I am asking because I spent quite some time wondering why my 
>>>> resource-type was not found, it was only because my project's 
>>>> resource-types.xml was not well-formed and it just got ignored 
>>>> because of these issues (culprit here being Yanel's 
>>>> src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)... 
>>>>
>>>>
>>>> Better fail fast than silently!!!
>>>
>>> I understand your frustration, but you need to be more specific by 
>>> providing a patch of the MergeResourceTypesConfigsTask class
>>
>> Shall I do that now?
>> The modification is pretty systematic as I tried to explain: remove 
>> all "try { ...} catch" constructs and make all methods throws 
>> Exception. Only the 'execute' method's contract will only allow 
>> BuildException to be thrown so wrap Exception to BuildException there.
> 
> rather not, because I do not think we should "replace" *all* try/catch  
> statements, but we really need to spend time on each case.
> 
> I will now implement the case of not well-formed resource-types.xml

OK.


>>> re which errors you want to throw and give specific examples when 
>>> these errors are thrown, e.g. resource-types.xml is not well-formed.
>>
>> I already gave an example:
>> make your realm's resource-types.xml not well-formed => the build will 
>> not break
> 
> it didn't sound like this was the only case/example

Really it was sound-distortion by frustration! ;)
I had other problems because I thought the resource-types.xml has to be 
placed directly under the realm directory (where build.xml is located) 
whereas it has to be in the same directory as the realm configuration 
file (e.g. realm.xml).


>> Sadly you cannot provide an example log since AFAICS the errors do not 
>> show up on the console, at least not at the log level I usually run 
>> Ant (with ANT_ARGS=-q).
> 
> maybe you should consider running without -q
> 
>> Where are the log4j logs supposed to be written to in this case?
> 
> I think it's standard output/command line

Indeed, maybe not using -q would have revealed this.


>> I am not sure which log4j properties file gets read here.
> 
> I am not sure either and would have to check
> 
> 
>>
>>> The case that your resource-types.xml is not found is NOT a build 
>>> error, because a realm does not have to have such a file.
>>
>> It was a misformulation from my side, I should have written
>> "spent quite some time wondering why my resource-type was not taken 
>> into account" instead of "spent quite some time wondering why my 
>> resource-type was not found".
>> I am aware this file is not mandatory.
> 
> ok, maybe you want to add this to the documentation

I will.


>>> That's rather a matter of documentation. Also you could enhance this 
>>> documentation, e.g.
>>>
>>> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
>>>
>>> http://www.yanel.org/en/documentation/create-new-resource.html
>>
>> We certainly could expand 
>> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
>> with a rationale for the example and at 
>> $YANELHOME/conf/local/local.resource-type.xml in the "Register New 
>> Resource" section suggest to use $REALM_DIR/resource-types.xml instead 
>> of $YANEL_HOME/conf/local/local.resource-types.xml
>>
>> Should I do that now?
> 
> yes, that would be great

OK, doing that now.

I'll add another simpler example for project-specific resource-types.xml 
files (taken from the from-scratch realm) as the existing one is rather 
lengthy.

BTW I noticed that for project-specific resource-types.xml files on 
'resource-type' elements:
- AFAICS the 'src' attributes do not have to end with "/" to work
- the paths for these attributes are also really relative to the 
directory where the realm configuration file (e.g. realm.xml) is, not to 
the realm directory (where build.xml is)
I will document the second point, but I won't document the first as I am 
not so sure it works in all cases (with 'copy-dir-name' attribute for 
example) so I will only experiment that on my current project and see if 
it goes well.
From michael.wechner at wyona.com  Mon Apr 12 10:30:29 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 12 10:44:01 2010
Subject: [Yanel-dev] 404 -> page creation (if Yanel toolbar enabled)
In-Reply-To: <4BC2C37C.1090003@wyona.com>
References: <4BC06AD0.4010107@wyona.com> <4BC2C37C.1090003@wyona.com>
Message-ID: <4BC2DA25.9050303@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Hi
>
> Hi!
>
>
>> During a private discussion with Bruno we realized it would be nice 
>> that in the case of a 404 and if the Yanel toolbar is
>> enabled, then the 404 screen would provide links to either create 
>> this page or create a redirect (in the sense of this page has moved)
>
> We had already had similar ideas: 
> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6941

thanks for pointing this out
> The idea to also allow to create a redirect is new though,

I will add it to Bugzilla
> and a nice one: perhaps one should display the sitetree at once to 
> allow looking for a similarly-named page?

I would suggest to make this part of the redirect/move option

whereas if the toolbar is not enabled, then it would make sense to 
display the sitetree.


WDYT?
>
>
>> WDYT?
>
> I still think it's a good idea! ;)

good :-)

Thanks

Michi
>
>
> Cheers,
>    Guillaume

From bugzilla at wyona.com  Mon Apr 12 10:47:25 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Mon Apr 12 10:47:28 2010
Subject: [Yanel-dev] [Bug 6941] wiki-style 404 page in authoring mode for
	Yanel website and documentation
Message-ID: <20100412084725.0CAC810C93E@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6941





------- Comment #1 from michael.wechner@wyona.org  2010-04-12 09:42 -------
Re the "create new page" link, one should check the creator resource first if
it actually exists within this realm.

Another "creator" could be "create a redirect/move" link (again an exist test
should be done) and in this case one should be able to select a link from the
sitetree.

If the toolbar is not enabled, then also the sitetree and a search field could
be displayed in order to help people to find what they are looking for.
Also mabye a contact form ...


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are the assignee for the bug, or are watching the assignee.
From guillaume.deflache at wyona.com  Mon Apr 12 11:49:59 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 12:05:47 2010
Subject: docs on the various resource-types.xml files (was: Re: [Yanel-dev]
	exception handling in Ant tasks)
In-Reply-To: <4BC2D9DD.5040904@wyona.com>
References: <4BBF6628.9070000@wyona.com>	<4BC0119D.4070803@wyona.com>	<4BC2CB02.8020301@wyona.com>	<4BC2CF50.8080700@wyona.com>
	<4BC2D9DD.5040904@wyona.com>
Message-ID: <4BC2ECC7.4050903@wyona.com>

Guillaume D?flache schrieb:
> Michael Wechner schrieb:
>> Guillaume D?flache wrote:
>>> Michael Wechner schrieb:
>>>> Guillaume D?flache wrote:
[...]
> I had other problems because I thought the resource-types.xml has to be 
> placed directly under the realm directory (where build.xml is located) 
> whereas it has to be in the same directory as the realm configuration 
> file (e.g. realm.xml).

Added to 
http://localhost:8080/yanel/yanel-website/en/documentation/configuration/resource-types_xml.html 
in r48705.


[...]
>>>> The case that your resource-types.xml is not found is NOT a build 
>>>> error, because a realm does not have to have such a file.
>>>
>>> It was a misformulation from my side, I should have written
>>> "spent quite some time wondering why my resource-type was not taken 
>>> into account" instead of "spent quite some time wondering why my 
>>> resource-type was not found".
>>> I am aware this file is not mandatory.
>>
>> ok, maybe you want to add this to the documentation
> 
> I will.

Ditto.


>>>> That's rather a matter of documentation. Also you could enhance this 
>>>> documentation, e.g.
>>>>
>>>> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
>>>>
>>>> http://www.yanel.org/en/documentation/create-new-resource.html
>>>
>>> We certainly could expand 
>>> http://www.yanel.org/en/documentation/configuration/resource-types_xml.html 
>>> with a rationale for the example and at 

Ditto.


>>> $YANELHOME/conf/local/local.resource-type.xml in the "Register New 
>>> Resource" section suggest to use $REALM_DIR/resource-types.xml 
>>> instead of $YANEL_HOME/conf/local/local.resource-types.xml

I refrained on doing that for now because it's not simpler for newbies, 
because I am not sure that the resource-types.xml file of new realms is 
created by default, and so you would have to put it manually just in the 
right place with the right name.


>>> Should I do that now?
>>
>> yes, that would be great
> 
> OK, doing that now.
> 
> I'll add another simpler example for project-specific resource-types.xml 
> files (taken from the from-scratch realm) as the existing one is rather 
> lengthy.

Done that too.


> BTW I noticed that for project-specific resource-types.xml files on 
> 'resource-type' elements:
> - AFAICS the 'src' attributes do not have to end with "/" to work
> - the paths for these attributes are also really relative to the 
> directory where the realm configuration file (e.g. realm.xml) is, not to 
> the realm directory (where build.xml is)
> I will document the second point, but I won't document the first as I am 
> not so sure it works in all cases (with 'copy-dir-name' attribute for 
> example) so I will only experiment that on my current project and see if 
> it goes well.

Did just as suggested.
From guillaume.deflache at wyona.com  Mon Apr 12 12:02:05 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 12:15:36 2010
Subject: [Yanel-dev] Resource creation
In-Reply-To: <4BC21FC6.1070607@wyona.com>
References: <4BC1C830.2000500@wyona.com> <4BC21FC6.1070607@wyona.com>
Message-ID: <4BC2EF9D.7040203@wyona.com>

Michael Wechner schrieb:
> Mehmet Birgi wrote:
>> When a new resource is created via "build.sh new-resource-type", it 
>> might be nice to set the svn:ignore property for the build directory 
>> automatically.
>>
>> wdyt?
> 
> if you download a source snapshot, then you do not have SVN.

> Also please be aware that one does often move the directory of the newly 
> created resource type.

Indeed.

Also people may want to want something else than Subversion like GIT or 
Mercurial for source control, and both do not have properties but rather 
files like .gitignore and .hgignore with similar syntaxes, like CVS does 
with .cvsignore.


> Hence I would rather add this to the documentation than make this 
> automagic.

Maybe we might add a (documented) semi-automatic way of doing it, that 
would give you a list of what files to ignore, than you could manually 
copy & paste into you .*ignore files.
Although with only few files to ignore it might not be worth it, and one 
would have to split the list output per directory as most of these file 
formats are for one directory at a time only.

Anyway it's better to have a documentation about all these ignores 
somewhere first!
From guillaume.deflache at wyona.com  Mon Apr 12 15:22:10 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 15:35:40 2010
Subject: [Yanel-dev] Yanel documentation, SVN and Yarep files
Message-ID: <4BC31E82.2080004@wyona.com>

I am wondering if we should not just svn:ignore all "revisions" 
directories for the Yanel documentation:

- we would not have to bother committing files for old revisions we do 
not need (as the current content file everything is under version 
control anyway); AFAIK not having this files does not produce any error, 
or at least it should not

- we would still experience how Yanel behaves with many revisions on the 
Wyona website (even if we already experience that on a much larger scale 
on some customer projects anyway), and at least those who try and 
download Yanel would not be obliged to pay the hefty price in terms of 
files downloaded...

- we could do that incrementally each time a committer updates a 
documentation page

- it certainly is easier to do than to use SVN as repository backend for 
the Yanel website /cf. 
<http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6939>) which 
originally had the same motivations

Note that it looks like it was already "unofficially" done for some 
pages where:
- either the "revisions" directory has never been committed (e.g. 
src/realms/yanel-website/content/source-repository.xhtml.yarep/revisions)
- or the whole "*.yarep" directory in which the "revisions" directory 
sits is ignored (e.g 
src/realms/yanel-website/content/documentation/create-new-resource/en.xhtml.yarep) 
or maybe sometimes not committed, both of which I am not sure it's 
really a good idea...

WDYT?
From mehmet.birgi at wyona.com  Mon Apr 12 15:44:53 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Mon Apr 12 16:00:06 2010
Subject: [Yanel-dev] Yanel documentation, SVN and Yarep files
In-Reply-To: <4BC31E82.2080004@wyona.com>
References: <4BC31E82.2080004@wyona.com>
Message-ID: <4BC323D5.2010708@wyona.com>



On 12.4.10 15:22 , Guillaume D?flache wrote:
> I am wondering if we should not just svn:ignore all "revisions"
> directories for the Yanel documentation:
>
> - we would not have to bother committing files for old revisions we do
> not need (as the current content file everything is under version
> control anyway); AFAIK not having this files does not produce any error,
> or at least it should not
>
> - we would still experience how Yanel behaves with many revisions on the
> Wyona website (even if we already experience that on a much larger scale
> on some customer projects anyway), and at least those who try and
> download Yanel would not be obliged to pay the hefty price in terms of
> files downloaded...
>
> - we could do that incrementally each time a committer updates a
> documentation page
>
> - it certainly is easier to do than to use SVN as repository backend for
> the Yanel website /cf.
> <http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=6939>) which
> originally had the same motivations
>
> Note that it looks like it was already "unofficially" done for some
> pages where:
> - either the "revisions" directory has never been committed (e.g.
> src/realms/yanel-website/content/source-repository.xhtml.yarep/revisions)
> - or the whole "*.yarep" directory in which the "revisions" directory
> sits is ignored (e.g
> src/realms/yanel-website/content/documentation/create-new-resource/en.xhtml.yarep)
> or maybe sometimes not committed, both of which I am not sure it's
> really a good idea...
>
> WDYT?

+1

-- 
Mehmet Birgi
www.wyona.com
From mehmet.birgi at wyona.com  Mon Apr 12 15:59:24 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Mon Apr 12 16:13:07 2010
Subject: [Yanel-dev] Resource creation
In-Reply-To: <4BC2EF9D.7040203@wyona.com>
References: <4BC1C830.2000500@wyona.com> <4BC21FC6.1070607@wyona.com>
	<4BC2EF9D.7040203@wyona.com>
Message-ID: <4BC3273C.7060808@wyona.com>

Hi All

I have updated the documentation for new resource creation, you can 
check it out at

http://127.0.0.1:8080/yanel/yanel-website/en/documentation/create-new-resource.html

Cheers

Memo


On 12.4.10 12:02 , Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Mehmet Birgi wrote:
>>> When a new resource is created via "build.sh new-resource-type", it
>>> might be nice to set the svn:ignore property for the build directory
>>> automatically.
>>>
>>> wdyt?
>>
>> if you download a source snapshot, then you do not have SVN.
>
>> Also please be aware that one does often move the directory of the
>> newly created resource type.
>
> Indeed.
>
> Also people may want to want something else than Subversion like GIT or
> Mercurial for source control, and both do not have properties but rather
> files like .gitignore and .hgignore with similar syntaxes, like CVS does
> with .cvsignore.
>
>
>> Hence I would rather add this to the documentation than make this
>> automagic.
>
> Maybe we might add a (documented) semi-automatic way of doing it, that
> would give you a list of what files to ignore, than you could manually
> copy & paste into you .*ignore files.
> Although with only few files to ignore it might not be worth it, and one
> would have to split the list output per directory as most of these file
> formats are for one directory at a time only.
>
> Anyway it's better to have a documentation about all these ignores
> somewhere first!

-- 
Mehmet Birgi
www.wyona.com
From guillaume.deflache at wyona.com  Mon Apr 12 18:40:07 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 12 18:53:38 2010
Subject: [Yanel-dev] Re: [Yanel-commits] Build failed in Hudson:
	security-trunk #0
In-Reply-To: <1146437083.31271088717036.JavaMail.memo@Memos-MacSilver.local>
References: <1146437083.31271088717036.JavaMail.memo@Memos-MacSilver.local>
Message-ID: <4BC34CE7.3020207@wyona.com>

hudson@wyona.com schrieb:
> See http://195.226.6.72:8080/job/security-trunk/0/
[...]

Please ignore all of these low-numbered Hudson job status reports, this 
came from a local Hudson setup, we forgot to change the E-mail 
configuration before running it... :/
I guess we will also add this step as the very first item in the 
upcoming documentation for local Hudson setup then! ;)
From guillaume.deflache at wyona.com  Wed Apr 14 14:31:38 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Wed Apr 14 14:48:16 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
Message-ID: <4BC5B5AA.3060107@wyona.com>

Hi!

At lunch we discussed what still prevent Yanel webapps to be redeployed 
fully automatically.

A few things we could think of:
- WEB-INF/classes/log4j.properties file which ATM use absolute paths for 
the various log files
- WEB-INF/classes/realms.xml which must point to at least one custom 
realm: ATM we do that using an absolute path

We thought we could maybe use the servlet context temporary directory[1] 
to store the realms.xml file itself or even the path under which it may 
be found.
I am not so sure it's a good idea since it looks like this directory may 
be deleted without notice: the application may be unable to restart 
automatically if this happens... :/

Ideas?

Cheers,
   Guillaume


[1] defined in the servlet specification since v2.2: 
http://java.sun.com/developer/technicalArticles/Servlets/servletapi/ 
look for "javax.servlet.context.tempdir"
Tomcat configuration: 
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html look for 
"workDir" there
From michael.wechner at wyona.com  Wed Apr 14 15:02:31 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 14 15:16:07 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC5B5AA.3060107@wyona.com>
References: <4BC5B5AA.3060107@wyona.com>
Message-ID: <4BC5BCE7.8000906@wyona.com>

Guillaume D?flache wrote:
> Hi!
>
> At lunch we discussed what still prevent Yanel webapps to be 
> redeployed fully automatically.
>
> A few things we could think of:
> - WEB-INF/classes/log4j.properties file which ATM use absolute paths 
> for the various log files
> - WEB-INF/classes/realms.xml which must point to at least one custom 
> realm: ATM we do that using an absolute path
>
> We thought we could maybe use the servlet context temporary 
> directory[1] to store the realms.xml file itself or even the path 
> under which it may be found.

Btw, the realms.xml path is already configured within 
local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml

re the working/temp dir I guess you mean with

File dir = (File) getServletContext()

     .getAttribute(
     "javax.servlet.context.tempdir");


right?

> I am not so sure it's a good idea since it looks like this directory 
> may be deleted without notice: the application may be unable to 
> restart automatically if this happens... :/

if the paths of the realms are wrong within classes/realms.xml then it 
doesn't start either ;-)

I think the question is what situations is this directory deleted.

Let me give it a try ...

Cheers

Michi

>
> Ideas?
>
> Cheers,
>   Guillaume
>
>
> [1] defined in the servlet specification since v2.2: 
> http://java.sun.com/developer/technicalArticles/Servlets/servletapi/ 
> look for "javax.servlet.context.tempdir"
> Tomcat configuration: 
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html look for 
> "workDir" there

From guillaume.deflache at wyona.com  Wed Apr 14 15:05:55 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Wed Apr 14 15:19:35 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BC2CF50.8080700@wyona.com>
References: <4BBF6628.9070000@wyona.com>
	<4BC0119D.4070803@wyona.com>	<4BC2CB02.8020301@wyona.com>
	<4BC2CF50.8080700@wyona.com>
Message-ID: <4BC5BDB3.90207@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Michael Wechner schrieb:
>>> Guillaume D?flache wrote:
>>>> Could we stop logging exceptions in Ant tasks and simply rethrow 
>>>> them as build exceptions (org.apache.tools.ant.BuildException).
>>>> The Ant tasks's "execute" entry-point method that every task shall 
>>>> implement already throws this type of exception so by only 
>>>> (re)throwing it here and in other methods:
>>>> - the stacktraces are simpler because they don't get displayed 
>>>> and/or wrapped many times
>>>> - one does not litter one's code with a lot of exception handling, 
>>>> the only needed code is "throws BuildException" appended on all 
>>>> methods signatures, or even "throws Exception" with only a exception 
>>>> wrapper from Exception to BuildException on the "execute" method
>>>> - errors ultimately get catched by Ant anyway, which already does a 
>>>> great job at showing full stacktraces, *and failing the whole build*
>>>>
>>>>
>>>> I am asking because I spent quite some time wondering why my 
>>>> resource-type was not found, it was only because my project's 
>>>> resource-types.xml was not well-formed and it just got ignored 
>>>> because of these issues (culprit here being Yanel's 
>>>> src/build/java/org/wyona/yanel/ant/MergeResourceTypesConfigsTask.java)... 
>>>>
>>>>
>>>> Better fail fast than silently!!!
>>>
>>> I understand your frustration, but you need to be more specific by 
>>> providing a patch of the MergeResourceTypesConfigsTask class
>>
>> Shall I do that now?
>> The modification is pretty systematic as I tried to explain: remove 
>> all "try { ...} catch" constructs and make all methods throws 
>> Exception. Only the 'execute' method's contract will only allow 
>> BuildException to be thrown so wrap Exception to BuildException there.
> 
> rather not, because I do not think we should "replace" *all* try/catch  
> statements, but we really need to spend time on each case.
> 
> I will now implement the case of not well-formed resource-types.xml
> 
>>
>>
>>> re which errors you want to throw and give specific examples when 
>>> these errors are thrown, e.g. resource-types.xml is not well-formed.
>>
>> I already gave an example:
>> make your realm's resource-types.xml not well-formed => the build will 
>> not break
> 
> it didn't sound like this was the only case/example

Another case I just stumbled upon is when the realm configuration file 
is not found:
> [merge-resource-types-configs] Realm context config: Realm context configuration:   ID = zwischengas,   Mount point = /,   Root flag = true,   Unresolved realm config file = /home/guillaume/zwischengas.VCWC/distribution/build/wyona_zwischengas_dist-r48758/zwischengas-realm_r48758/realm.xml
> [merge-resource-types-configs] 792  2010-04-14 14:56:11,903 [main] ERROR org.wyona.yanel.ant.MergeResourceTypesConfigsTask.mergeResourceTypesOfRealm():?  - Neither file nor directory: /home/guillaume/zwischengas.VCWC/distribution/build/wyona_zwischengas_dist-r48758/zwischengas-realm_r48758/realm.xml
> 
> init:
[Ant continues to build after that.]


>> Sadly you cannot provide an example log since AFAICS the errors do not 
>> show up on the console, at least not at the log level I usually run 
>> Ant (with ANT_ARGS=-q).
> 
> maybe you should consider running without -q
> 
>> Where are the log4j logs supposed to be written to in this case?
> 
> I think it's standard output/command line

You were right, see above.


>> I am not sure which log4j properties file gets read here.
> 
> I am not sure either and would have to check
[...]
From guillaume.deflache at wyona.com  Wed Apr 14 15:15:25 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Wed Apr 14 15:28:57 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC5BCE7.8000906@wyona.com>
References: <4BC5B5AA.3060107@wyona.com> <4BC5BCE7.8000906@wyona.com>
Message-ID: <4BC5BFED.2080701@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Hi!
>>
>> At lunch we discussed what still prevent Yanel webapps to be 
>> redeployed fully automatically.
>>
>> A few things we could think of:
>> - WEB-INF/classes/log4j.properties file which ATM use absolute paths 
>> for the various log files
>> - WEB-INF/classes/realms.xml which must point to at least one custom 
>> realm: ATM we do that using an absolute path
>>
>> We thought we could maybe use the servlet context temporary 
>> directory[1] to store the realms.xml file itself or even the path 
>> under which it may be found.

One argument in favor of storing the path itself: if you have many 
custom realms it may get tedious to reconfigure all of them by 
recreating the whole XML file: better keep realms.xml in a safe place!


> Btw, the realms.xml path is already configured within 
> local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml

Yes, and that's why as explained during lunch we might even want to use 
that for yanel.xml instead of realms.xml! ;)


> re the working/temp dir I guess you mean with
> 
> File dir = (File) getServletContext()
> 
>     .getAttribute(
>     "javax.servlet.context.tempdir");
> 
> 
> right?

Yes.


>> I am not so sure it's a good idea since it looks like this directory 
>> may be deleted without notice: the application may be unable to 
>> restart automatically if this happens... :/
> 
> if the paths of the realms are wrong within classes/realms.xml then it 
> doesn't start either ;-)

Yes, but then the adminstrator can only blame himself for that, whereas 
we may not want to trust what the servlet engine and/or the operating 
system does with the work directory...

BTW I had a look at what a Cocoon 2.1 application stores there and there 
are only cache files, no configuration.


> I think the question is what situations is this directory deleted.
> 
> Let me give it a try ...

Good luck! :)


> Cheers
> 
> Michi
> 
>>
>> Ideas?
>>
>> Cheers,
>>   Guillaume
>>
>>
>> [1] defined in the servlet specification since v2.2: 
>> http://java.sun.com/developer/technicalArticles/Servlets/servletapi/ 
>> look for "javax.servlet.context.tempdir"
>> Tomcat configuration: 
>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html look for 
>> "workDir" there
> 

From michael.wechner at wyona.com  Wed Apr 14 15:49:54 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 14 16:03:29 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC5BFED.2080701@wyona.com>
References: <4BC5B5AA.3060107@wyona.com> <4BC5BCE7.8000906@wyona.com>
	<4BC5BFED.2080701@wyona.com>
Message-ID: <4BC5C802.6070606@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Guillaume D?flache wrote:
>>> Hi!
>>>
>>> At lunch we discussed what still prevent Yanel webapps to be 
>>> redeployed fully automatically.
>>>
>>> A few things we could think of:
>>> - WEB-INF/classes/log4j.properties file which ATM use absolute paths 
>>> for the various log files
>>> - WEB-INF/classes/realms.xml which must point to at least one custom 
>>> realm: ATM we do that using an absolute path
>>>
>>> We thought we could maybe use the servlet context temporary 
>>> directory[1] to store the realms.xml file itself or even the path 
>>> under which it may be found.
>
> One argument in favor of storing the path itself: if you have many 
> custom realms it may get tedious to reconfigure all of them by 
> recreating the whole XML file: better keep realms.xml in a safe place!

well, you can always keep a copy of the realms.xml file in a save place ;-)


>
>
>> Btw, the realms.xml path is already configured within 
>> local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml
>
> Yes, and that's why as explained during lunch we might even want to 
> use that for yanel.xml instead of realms.xml! ;)


I didn't mean either/or, of course we can provide for all config files 
alternative directories


>
>
>> re the working/temp dir I guess you mean with
>>
>> File dir = (File) getServletContext()
>>
>>     .getAttribute(
>>     "javax.servlet.context.tempdir");
>>
>>
>> right?
>
> Yes.
>
>
>>> I am not so sure it's a good idea since it looks like this directory 
>>> may be deleted without notice: the application may be unable to 
>>> restart automatically if this happens... :/
>>
>> if the paths of the realms are wrong within classes/realms.xml then 
>> it doesn't start either ;-)
>
> Yes, but then the adminstrator can only blame himself for that, 
> whereas we may not want to trust what the servlet engine and/or the 
> operating system does with the work directory...
>
> BTW I had a look at what a Cocoon 2.1 application stores there and 
> there are only cache files, no configuration.

that's why it is called temporary/work dir ;-)

Cheers

Michi
>
>
>> I think the question is what situations is this directory deleted.
>>
>> Let me give it a try ...
>
> Good luck! :)
>
>
>> Cheers
>>
>> Michi
>>
>>>
>>> Ideas?
>>>
>>> Cheers,
>>>   Guillaume
>>>
>>>
>>> [1] defined in the servlet specification since v2.2: 
>>> http://java.sun.com/developer/technicalArticles/Servlets/servletapi/ 
>>> look for "javax.servlet.context.tempdir"
>>> Tomcat configuration: 
>>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html look for 
>>> "workDir" there
>>
>

From michael.wechner at wyona.com  Wed Apr 14 15:50:41 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 14 16:06:56 2010
Subject: [Yanel-dev] exception handling in Ant tasks
In-Reply-To: <4BC5BDB3.90207@wyona.com>
References: <4BBF6628.9070000@wyona.com>	<4BC0119D.4070803@wyona.com>	<4BC2CB02.8020301@wyona.com>	<4BC2CF50.8080700@wyona.com>
	<4BC5BDB3.90207@wyona.com>
Message-ID: <4BC5C831.4080100@wyona.com>

Guillaume D?flache wrote:
>>>
>>> I already gave an example:
>>> make your realm's resource-types.xml not well-formed => the build 
>>> will not break
>>
>> it didn't sound like this was the only case/example
>
> Another case I just stumbled upon is when the realm configuration file 
> is not found:

ok, so I will also implement this case


Cheers

Michi




>> [merge-resource-types-configs] Realm context config: Realm context 
>> configuration:   ID = zwischengas,   Mount point = /,   Root flag = 
>> true,   Unresolved realm config file = 
>> /home/guillaume/zwischengas.VCWC/distribution/build/wyona_zwischengas_dist-r48758/zwischengas-realm_r48758/realm.xml 
>>
>> [merge-resource-types-configs] 792  2010-04-14 14:56:11,903 [main] 
>> ERROR 
>> org.wyona.yanel.ant.MergeResourceTypesConfigsTask.mergeResourceTypesOfRealm():?  
>> - Neither file nor directory: 
>> /home/guillaume/zwischengas.VCWC/distribution/build/wyona_zwischengas_dist-r48758/zwischengas-realm_r48758/realm.xml 
>>
>>
>> init:
> [Ant continues to build after that.]
>
>
>>> Sadly you cannot provide an example log since AFAICS the errors do 
>>> not show up on the console, at least not at the log level I usually 
>>> run Ant (with ANT_ARGS=-q).
>>
>> maybe you should consider running without -q
>>
>>> Where are the log4j logs supposed to be written to in this case?
>>
>> I think it's standard output/command line
>
> You were right, see above.
>
>
>>> I am not sure which log4j properties file gets read here.
>>
>> I am not sure either and would have to check
> [...]

From michael.wechner at wyona.com  Wed Apr 14 21:36:41 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 14 21:50:22 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC5BFED.2080701@wyona.com>
References: <4BC5B5AA.3060107@wyona.com> <4BC5BCE7.8000906@wyona.com>
	<4BC5BFED.2080701@wyona.com>
Message-ID: <4BC61949.2080803@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Guillaume D?flache wrote:
>>> Hi!
>>>
>>> At lunch we discussed what still prevent Yanel webapps to be 
>>> redeployed fully automatically.
>>>
>>> A few things we could think of:
>>> - WEB-INF/classes/log4j.properties file which ATM use absolute paths 
>>> for the various log files

I have added the catalina.base variable to

Sending        conf/log4j.properties
Transmitting file data .
Committed revision 48799.

whereas for Backwards compatibility and documentation reasons I have 
commented it though, but
it should give people at least a hint how to use/overwrite it.

Cheers

Michi
From michael.wechner at wyona.com  Wed Apr 14 22:25:41 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 14 22:39:36 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC5BCE7.8000906@wyona.com>
References: <4BC5B5AA.3060107@wyona.com> <4BC5BCE7.8000906@wyona.com>
Message-ID: <4BC624C5.5060309@wyona.com>

Michael Wechner wrote:
>>
>> - WEB-INF/classes/realms.xml which must point to at least one custom 
>> realm: ATM we do that using an absolute path
>>
>> We thought we could maybe use the servlet context temporary 
>> directory[1] to store the realms.xml file itself or even the path 
>> under which it may be found.
>
> Btw, the realms.xml path is already configured within 
> local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml
>
> re the working/temp dir I guess you mean with
>
> File dir = (File) getServletContext()
>
>     .getAttribute(
>     "javax.servlet.context.tempdir");
>
>
> right?

The following java classes would have to be enhanced:

src/webapp/src/java/org/wyona/yanel/servlet/YanelServlet.java
src/core/java/org/wyona/yanel/core/Yanel.java#init()
src/core/java/org/wyona/yanel/core/map/RealmManager.java

whereas I have done some preparations in order to make this work.

Cheers

Michi
From michael.wechner at wyona.com  Fri Apr 16 11:01:13 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 16 11:14:54 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC624C5.5060309@wyona.com>
References: <4BC5B5AA.3060107@wyona.com> <4BC5BCE7.8000906@wyona.com>
	<4BC624C5.5060309@wyona.com>
Message-ID: <4BC82759.7070006@wyona.com>

Michael Wechner wrote:
> Michael Wechner wrote:
>>>
>>> - WEB-INF/classes/realms.xml which must point to at least one custom 
>>> realm: ATM we do that using an absolute path
>>>
>>> We thought we could maybe use the servlet context temporary 
>>> directory[1] to store the realms.xml file itself or even the path 
>>> under which it may be found.
>>
>> Btw, the realms.xml path is already configured within 
>> local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml
>>
>> re the working/temp dir I guess you mean with
>>
>> File dir = (File) getServletContext()
>>
>>     .getAttribute(
>>     "javax.servlet.context.tempdir");
>>
>>
>> right?
>
> The following java classes would have to be enhanced:
>
> src/webapp/src/java/org/wyona/yanel/servlet/YanelServlet.java
> src/core/java/org/wyona/yanel/core/Yanel.java#init()
> src/core/java/org/wyona/yanel/core/map/RealmManager.java
>
> whereas I have done some preparations in order to make this work.

btw, there might be some alternative solutions, see

http://discuss.joelonsoftware.com/default.asp?joel.3.145249.13
http://www.brunningonline.net/simon/blog/archives/001235.html

It seems to me these are the possibilities:

1) Look within webapp classspath (which it does now)
2) Look within temporary directory (the problem with this is that it 
might get deleted)
3) Use preference API to find the file somewhere within the user 
directory under which the webapp-server (e.g. Tomcat) is running
4) Use environment variable which is configured under the user the 
webapp-server (e.g. Tomcat) is running or configure it during startup of 
the webapp-server (e.g. Tomcat/bin/catalina.sh)

WDYT?

Cheers

Michi
>
> Cheers
>
> Michi

From michael.wechner at wyona.com  Fri Apr 16 12:09:05 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 16 12:22:46 2010
Subject: [Yanel-dev] redeploying WARs fully automatically
In-Reply-To: <4BC82759.7070006@wyona.com>
References: <4BC5B5AA.3060107@wyona.com>
	<4BC5BCE7.8000906@wyona.com>	<4BC624C5.5060309@wyona.com>
	<4BC82759.7070006@wyona.com>
Message-ID: <4BC83741.3040103@wyona.com>

Michael Wechner wrote:
> Michael Wechner wrote:
>> Michael Wechner wrote:
>>>>
>>>> - WEB-INF/classes/realms.xml which must point to at least one 
>>>> custom realm: ATM we do that using an absolute path
>>>>
>>>> We thought we could maybe use the servlet context temporary 
>>>> directory[1] to store the realms.xml file itself or even the path 
>>>> under which it may be found.
>>>
>>> Btw, the realms.xml path is already configured within 
>>> local/apache-tomcat-5.5.20/webapps/yanel/WEB-INF/classes/yanel.xml
>>>
>>> re the working/temp dir I guess you mean with
>>>
>>> File dir = (File) getServletContext()
>>>
>>>     .getAttribute(
>>>     "javax.servlet.context.tempdir");
>>>
>>>
>>> right?
>>
>> The following java classes would have to be enhanced:
>>
>> src/webapp/src/java/org/wyona/yanel/servlet/YanelServlet.java
>> src/core/java/org/wyona/yanel/core/Yanel.java#init()
>> src/core/java/org/wyona/yanel/core/map/RealmManager.java
>>
>> whereas I have done some preparations in order to make this work.
>
> btw, there might be some alternative solutions, see
>
> http://discuss.joelonsoftware.com/default.asp?joel.3.145249.13
> http://www.brunningonline.net/simon/blog/archives/001235.html
>
> It seems to me these are the possibilities:
>
> 1) Look within webapp classspath (which it does now)
> 2) Look within temporary directory (the problem with this is that it 
> might get deleted)
> 3) Use preference API to find the file somewhere within the user 
> directory under which the webapp-server (e.g. Tomcat) is running
> 4) Use environment variable which is configured under the user the 
> webapp-server (e.g. Tomcat) is running or configure it during startup 
> of the webapp-server (e.g. Tomcat/bin/catalina.sh)

another interesting document might be

http://download.oracle.com/docs/cd/B12166_01/web/B10321_01/deploy.htm#1021783

because it shows we are not the only ones having configurations ;-)

Cheers

Michi
>
> WDYT?
>
> Cheers
>
> Michi
>>
>> Cheers
>>
>> Michi
>

From guillaume.deflache at wyona.com  Mon Apr 19 17:01:36 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 19 17:16:22 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler
	returning null
Message-ID: <4BCC7050.9080403@wyona.com>

Hi!

When using XSLT via the JAXP API, you may use the 
SAXTransformerFactory#newTransformerHandler(Source) method 
(<http://java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Source)>).

Please be aware than with Xalan (2.7.1 at least) this method may only 
return null if your XSLT is incorrect for some reason (in our case this 
was a namespace used in XPath that never got declared), instead of 
complaining loudly, which can be extremly confusing.

HTH,
    Guillaume
From michael.wechner at wyona.com  Mon Apr 19 22:26:44 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Mon Apr 19 22:40:49 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler
	returning null
In-Reply-To: <4BCC7050.9080403@wyona.com>
References: <4BCC7050.9080403@wyona.com>
Message-ID: <4BCCBC84.4000908@wyona.com>

Guillaume D?flache wrote:
> Hi!
>
> When using XSLT via the JAXP API, you may use the 
> SAXTransformerFactory#newTransformerHandler(Source) method 
> (<http://java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Source)>). 
>

instead of what?
>
> Please be aware than with Xalan (2.7.1 at least) this method may only 
> return null if your XSLT is incorrect for some reason (in our case 
> this was a namespace used in XPath that never got declared),

can you give a more concrete example?
> instead of complaining loudly, which can be extremly confusing.

which method didn't complain?

Thanks

Michi
>
> HTH,
>    Guillaume

From guillaume.deflache at wyona.com  Tue Apr 20 09:13:53 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Tue Apr 20 09:30:29 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler
	returning null
In-Reply-To: <4BCCBC84.4000908@wyona.com>
References: <4BCC7050.9080403@wyona.com> <4BCCBC84.4000908@wyona.com>
Message-ID: <4BCD5431.9020701@wyona.com>

Michael Wechner schrieb:
> Guillaume D?flache wrote:
>> Hi!

Hi!


>> When using XSLT via the JAXP API, you may use the 
>> SAXTransformerFactory#newTransformerHandler(Source) method 
>> (<http://java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Source)>). 
>>
> 
> instead of what?

Describing an alternative way was not the point here, we just used 
what's in 
http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/src/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.java


>> Please be aware than with Xalan (2.7.1 at least) this method may only 
>> return null if your XSLT is incorrect for some reason (in our case 
>> this was a namespace used in XPath that never got declared),
> 
> can you give a more concrete example?

In 
http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/src/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.java 
there is:
xsltHandlers[i] = tf.newTransformerHandler(new 
StreamSource(repo.getNode(xsltPath[i]).getInputStream()));
The variable is set to null when e.g. the Yanel NS namespace has not 
been associated with the 'yanel' prefix in e.g. <xsl:value-of 
select="yanel:foo"/>

>> instead of complaining loudly, which can be extremly confusing.
> 
> which method didn't complain?

SAXTransformerFactory#newTransformerHandler as written above.

Cheers,
    Guillaume
From michael.wechner at wyona.com  Tue Apr 20 09:34:15 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr 20 09:53:11 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler
	returning null
In-Reply-To: <4BCD5431.9020701@wyona.com>
References: <4BCC7050.9080403@wyona.com> <4BCCBC84.4000908@wyona.com>
	<4BCD5431.9020701@wyona.com>
Message-ID: <4BCD58F7.2060404@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Guillaume D?flache wrote:
>>> Hi!
>
> Hi!
>
>
>>> When using XSLT via the JAXP API, you may use the 
>>> SAXTransformerFactory#newTransformerHandler(Source) method 
>>> (<http://java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Source)>). 
>>>
>>
>> instead of what?
>
> Describing an alternative way was not the point here, we just used 
> what's in 
> http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/src/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.java

so you received a NullPointer at the following line:

xsltHandlers[i] = tf.newTransformerHandler(new 
StreamSource(repo.getNode(xsltPath[i]).getInputStream()));

but it was not clear which call exactly created the NullPointer, right?

In order to find out you have split this line into several lines, e.g.

    Node node = repo.getNode(xsltPath[i]);

   InputStream is = node.getInputStream()

    StreamSource ss = new StreamSource(is)
> xsltHandlers[i] = tf.newTransformerHandler(ss);

and then received the NullPointer on the line of newTransformerHandler
 which means something is wrong with the XSLT
>
>
>>> Please be aware than with Xalan (2.7.1 at least) this method may 
>>> only return null if your XSLT is incorrect for some reason (in our 
>>> case this was a namespace used in XPath that never got declared),
>>
>> can you give a more concrete example?
>
> In 
> http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/src/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.java 
> there is:
> xsltHandlers[i] = tf.newTransformerHandler(new 
> StreamSource(repo.getNode(xsltPath[i]).getInputStream()));
> The variable is set to null when e.g. the Yanel NS namespace has not 
> been associated with the 'yanel' prefix in e.g. <xsl:value-of 
> select="yanel:foo"/>

so you are saying that the namespace declaration was missing, e.g.

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:yanel="http://www.wyona.org/yanel/1.0"

right?


Thanks

Michi
>
>>> instead of complaining loudly, which can be extremly confusing.
>>
>> which method didn't complain?
>
> SAXTransformerFactory#newTransformerHandler as written above.
>
> Cheers,
>    Guillaume

From mehmet.birgi at wyona.com  Tue Apr 20 09:42:50 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr 20 10:00:11 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler 
	returning null
In-Reply-To: <4BCD58F7.2060404@wyona.com>
References: <4BCC7050.9080403@wyona.com> <4BCCBC84.4000908@wyona.com>
	<4BCD5431.9020701@wyona.com> <4BCD58F7.2060404@wyona.com>
Message-ID: <x2z5bf1397d1004200042nd5847eacw8a0a68bad414bf26@mail.gmail.com>

On Tue, Apr 20, 2010 at 9:34 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Guillaume D=E9flache wrote:
>
>> Michael Wechner schrieb:
>>
>>> Guillaume D=E9flache wrote:
>>>
>>>> Hi!
>>>>
>>>
>> Hi!
>>
>>
>>  When using XSLT via the JAXP API, you may use the
>>>> SAXTransformerFactory#newTransformerHandler(Source) method (<
>>>> http://java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTrans=
formerFactory.html#newTransformerHandler(javax.xml.transform.Source)<http:/=
/java.sun.com/javase/6/docs/api/javax/xml/transform/sax/SAXTransformerFacto=
ry.html#newTransformerHandler%28javax.xml.transform.Source%29>>).
>>>>
>>>>
>>>
>>> instead of what?
>>>
>>
>> Describing an alternative way was not the point here, we just used what's
>> in
>> http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/s=
rc/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.java
>>
>
> so you received a NullPointer at the following line:
>
>
> xsltHandlers[i] =3D tf.newTransformerHandler(new
> StreamSource(repo.getNode(xsltPath[i]).getInputStream()));
>
> but it was not clear which call exactly created the NullPointer, right?
>
> In order to find out you have split this line into several lines, e.g.
>
>   Node node =3D repo.getNode(xsltPath[i]);
>
>  InputStream is =3D node.getInputStream()
>
>   StreamSource ss =3D new StreamSource(is)
>
>> xsltHandlers[i] =3D tf.newTransformerHandler(ss);
>>
>
> and then received the NullPointer on the line of newTransformerHandler
> which means something is wrong with the XSLT


That's exactly what we did :-)

>
>
>>
>>  Please be aware than with Xalan (2.7.1 at least) this method may only
>>>> return null if your XSLT is incorrect for some reason (in our case thi=
s was
>>>> a namespace used in XPath that never got declared),
>>>>
>>>
>>> can you give a more concrete example?
>>>
>>
>> In
>> http://svn.wyona.com/repos/public/yanel/trunk/src/resources/navigation/s=
rc/java/org/wyona/yanel/impl/resources/navigation/NavigationResource.javath=
ere is:
>> xsltHandlers[i] =3D tf.newTransformerHandler(new
>> StreamSource(repo.getNode(xsltPath[i]).getInputStream()));
>> The variable is set to null when e.g. the Yanel NS namespace has not been
>> associated with the 'yanel' prefix in e.g. <xsl:value-of
>> select=3D"yanel:foo"/>
>>
>
> so you are saying that the namespace declaration was missing, e.g.
>
> <xsl:stylesheet version=3D"1.0"
>  xmlns:xsl=3D"http://www.w3.org/1999/XSL/Transform"
>  xmlns:yanel=3D"http://www.wyona.org/yanel/1.0"
>
> right?
>

Yes, that was it.  And what helped us find it in the end was a tool called
xsltproc (http://xmlsoft.org/XSLT/xsltproc2.html), which is basically a
command line transformer. The simplest usage in this case is:

> xsltproc header.xsl header.xsl

It pointed out the error immediately (that the namespace was undeclared).

Cheers,

Memo



>
> Thanks
>
> Michi
>
>
>>  instead of complaining loudly, which can be extremly confusing.
>>>>
>>>
>>> which method didn't complain?
>>>
>>
>> SAXTransformerFactory#newTransformerHandler as written above.
>>
>> Cheers,
>>   Guillaume
>>
>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
0/d201f2f5/attachment.htm
From mehmet.birgi at wyona.com  Tue Apr 20 09:55:10 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr 20 10:13:02 2010
Subject: [Yanel-dev] Keeping line breaks in XSLT
Message-ID: <g2u5bf1397d1004200055m60c3d5b2jc207a60148fc7301@mail.gmail.com>

When your content that is transformed through XSLT has line breaks that need
to be preserved, you should use <xsl:copy-of> instead of <xsl:value-of> in
your stylesheet. Here is an example:

The original XML snippet:

  <node href=3D"xyz">
    <name>Foo &amp;<br/>Bar</name>
  </node>

When you apply <xsl:value-of select=3D"node/name"/> in your stylesheet, you
get:

Foo &Bar

but when you use <xsl:copy-of select=3D"node/name"/>, you get:

Foo &
Bar

HTH, cheers,

Memo



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
0/75804a2c/attachment.htm
From michael.wechner at wyona.com  Tue Apr 20 09:58:26 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr 20 10:13:13 2010
Subject: [Yanel-dev] [FYI] SAXTransformerFactory#newTransformerHandler
	returning null
In-Reply-To: <x2z5bf1397d1004200042nd5847eacw8a0a68bad414bf26@mail.gmail.com>
References: <4BCC7050.9080403@wyona.com>
	<4BCCBC84.4000908@wyona.com>	<4BCD5431.9020701@wyona.com>
	<4BCD58F7.2060404@wyona.com>
	<x2z5bf1397d1004200042nd5847eacw8a0a68bad414bf26@mail.gmail.com>
Message-ID: <4BCD5EA2.2030005@wyona.com>

Mehmet Birgi wrote:
>
>
>
> Yes, that was it.  And what helped us find it in the end was a tool 
> called xsltproc (http://xmlsoft.org/XSLT/xsltproc2.html), which is 
> basically a command line transformer. The simplest usage in this case is:
>
> > xsltproc header.xsl header.xsl

Thanks for pointing this out. It seems to be installed on Mac OS X (at 
least Snow Leopard) by default and can be applied as follows:

xsltproc myxslt.xsl myxml.xml

Thanks

Michi





>
> It pointed out the error immediately (that the namespace was undeclared).
>
> Cheers,
>
> Memo
>
>
>
>
>     Thanks
>
>     Michi
>
>
>                 instead of complaining loudly, which can be extremly
>                 confusing.
>
>
>             which method didn't complain?
>
>
>         SAXTransformerFactory#newTransformerHandler as written above.
>
>         Cheers,
>           Guillaume
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From mehmet.birgi at wyona.com  Tue Apr 20 18:02:01 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr 20 18:16:16 2010
Subject: [Yanel-dev] Contact Form
Message-ID: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>

I am trying to use the contact-form resource provided by Yanel. As described
in the documentation (
http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html), I
have put this in my local.yanel.xml:

  <smtp host=3D"mail.wyona.com" port=3D"25"/>

but I still get a

    java.net.UnknownHostException: mail.foo.bar

The same thing happens when I put the line above in the realm.xml of my
realm.

Does anyone know why this is happening? Am I doing something wrong?

Thanks,

Memo


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
0/1ad8f21c/attachment.htm
From mehmet.birgi at wyona.com  Tue Apr 20 18:33:17 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr 20 18:47:06 2010
Subject: [Yanel-dev] Re: Contact Form
In-Reply-To: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
Message-ID: <r2s5bf1397d1004200933xa9c2b6a5id9503b24217c6cd2@mail.gmail.com>

Update: I got it working after rebuilding Yanel. It seems that this is
necessary, just changing the smtp host in WEB-INF/classes/yanel.xml is not
enough. If someone (Michi?) can confirm this, I will update the
documentation.

Thanks,

Mehmet



On Tue, Apr 20, 2010 at 6:02 PM, Mehmet Birgi <mehmet.birgi@wyona.com>wrote:

> I am trying to use the contact-form resource provided by Yanel. As
> described in the documentation (
> http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html), I
> have put this in my local.yanel.xml:
>
>   <smtp host=3D"mail.wyona.com" port=3D"25"/>
>
> but I still get a
>
>     java.net.UnknownHostException: mail.foo.bar
>
> The same thing happens when I put the line above in the realm.xml of my
> realm.
>
> Does anyone know why this is happening? Am I doing something wrong?
>
> Thanks,
>
> Memo
>
>
> --
> Mehmet Birgi
> www.wyona.com
>
>


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
0/17acdf2b/attachment.htm
From michael.wechner at wyona.com  Tue Apr 20 21:01:21 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr 20 21:33:30 2010
Subject: [Yanel-dev] Re: Contact Form
In-Reply-To: <r2s5bf1397d1004200933xa9c2b6a5id9503b24217c6cd2@mail.gmail.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
	<r2s5bf1397d1004200933xa9c2b6a5id9503b24217c6cd2@mail.gmail.com>
Message-ID: <4BCDFA01.4080908@wyona.com>

Mehmet Birgi wrote:
> Update: I got it working after rebuilding Yanel.

if you change conf/local/local.yanel.xml then you need to rebuild, 
whereas this would be a bit overkill,
hence you rather change it at the same time at WEB-INF/classes/yanel.xml 
and only restart Yanel, so no need
to rebuild Yanel.

The reason you should change it at both cases is because during rebuild

conf/local/local.yanel.xml

is going to overwrite

WEB-INF/classes/yanel.xml

(btw, this is true for basically all configuration files)

> It seems that this is necessary, just changing the smtp host in 
> WEB-INF/classes/yanel.xml 

did you restart Yanel after changing yanel.xml?
> is not enough. If someone (Michi?) can confirm this, I will update the 
> documentation.

Do you mean

http://www.yanel.org/en/documentation/configuration/yanel_xml.html

or

http://www.yanel.org/en/documentation/misc/smtp-configuration.html

I would be glad if you could update both pages.

Thanks

Michi
>
> Thanks,
>
> Mehmet
>
>
>
> On Tue, Apr 20, 2010 at 6:02 PM, Mehmet Birgi <mehmet.birgi@wyona.com 
> <mailto:mehmet.birgi@wyona.com>> wrote:
>
>     I am trying to use the contact-form resource provided by Yanel. As
>     described in the documentation
>     (http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html),
>     I have put this in my local.yanel.xml:
>
>       <smtp host="mail.wyona.com <http://mail.wyona.com>" port="25"/>
>
>     but I still get a
>
>         java.net.UnknownHostException: mail.foo.bar
>
>     The same thing happens when I put the line above in the realm.xml
>     of my realm.
>
>     Does anyone know why this is happening? Am I doing something wrong?
>
>     Thanks,
>
>     Memo
>
>
>     -- 
>     Mehmet Birgi
>     www.wyona.com <http://www.wyona.com>
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From michael.wechner at wyona.com  Tue Apr 20 21:13:12 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Tue Apr 20 21:43:26 2010
Subject: [Yanel-dev] Contact Form
In-Reply-To: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
Message-ID: <4BCDFCC8.2020505@wyona.com>

Mehmet Birgi wrote:
> I am trying to use the contact-form resource provided by Yanel. As 
> described in the documentation 
> (http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html), 
> I have put this in my local.yanel.xml:
>
>   <smtp host="mail.wyona.com <http://mail.wyona.com>" port="25"/>
>
> but I still get a
>
>     java.net.UnknownHostException: mail.foo.bar

did you restart Yanel after this change?
>
> The same thing happens when I put the line above in the realm.xml of 
> my realm.

where did you get this idea from? IIRC I once wrote an email about this 
that it might make sense that each realm
could have its own mail server configuration, but I do not think we have 
ever implemented this.

Cheers

Michi
>
> Does anyone know why this is happening? Am I doing something wrong?
>
> Thanks,
>
> Memo
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From mehmet.birgi at wyona.com  Wed Apr 21 08:44:36 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr 21 09:00:48 2010
Subject: [Yanel-dev] Re: Contact Form
In-Reply-To: <4BCDFA01.4080908@wyona.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
	<r2s5bf1397d1004200933xa9c2b6a5id9503b24217c6cd2@mail.gmail.com>
	<4BCDFA01.4080908@wyona.com>
Message-ID: <x2k5bf1397d1004202344s5398d8acqfaa7a560e6dd7401@mail.gmail.com>

On Tue, Apr 20, 2010 at 9:01 PM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>> Update: I got it working after rebuilding Yanel.
>>
>
> if you change conf/local/local.yanel.xml then you need to rebuild, whereas
> this would be a bit overkill,
> hence you rather change it at the same time at WEB-INF/classes/yanel.xml
> and only restart Yanel, so no need
> to rebuild Yanel.
>
> The reason you should change it at both cases is because during rebuild
>
> conf/local/local.yanel.xml
>
> is going to overwrite
>
>
> WEB-INF/classes/yanel.xml
>
> (btw, this is true for basically all configuration files)


understood, but I will still make a note in the docs, just in case

>
>
>  It seems that this is necessary, just changing the smtp host in
>> WEB-INF/classes/yanel.xml
>>
>
> did you restart Yanel after changing yanel.xml?


I had, but as this seemed rather bizarre even at that time, I retried this
now, and realized that yesterday I had edited the yanel.xml in the wrong
WEB-INF :-(

sorry about the confusion, changing this and restarting does work, as
expected


>
>  is not enough. If someone (Michi?) can confirm this, I will update the
>> documentation.
>>
>
> Do you mean
>
> http://www.yanel.org/en/documentation/configuration/yanel_xml.html
>
> or
>
> http://www.yanel.org/en/documentation/misc/smtp-configuration.html
>
> I would be glad if you could update both pages.
>

I will, right away

Cheers,

Memo



>
> Thanks
>
> Michi
>
>>
>> Thanks,
>>
>> Mehmet
>>
>>
>>
>>
>> On Tue, Apr 20, 2010 at 6:02 PM, Mehmet Birgi <mehmet.birgi@wyona.com<ma=
ilto:
>> mehmet.birgi@wyona.com>> wrote:
>>
>>    I am trying to use the contact-form resource provided by Yanel. As
>>    described in the documentation
>>    (http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html
>> ),
>>    I have put this in my local.yanel.xml:
>>
>>      <smtp host=3D"mail.wyona.com <http://mail.wyona.com>" port=3D"25"/>
>>
>>
>>    but I still get a
>>
>>        java.net.UnknownHostException: mail.foo.bar
>>
>>    The same thing happens when I put the line above in the realm.xml
>>    of my realm.
>>
>>    Does anyone know why this is happening? Am I doing something wrong?
>>
>>    Thanks,
>>
>>    Memo
>>
>>
>>    --     Mehmet Birgi
>>    www.wyona.com <http://www.wyona.com>
>>
>>
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
1/0145ba47/attachment-0001.htm
From mehmet.birgi at wyona.com  Wed Apr 21 08:45:19 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr 21 09:00:51 2010
Subject: [Yanel-dev] Contact Form
In-Reply-To: <4BCDFCC8.2020505@wyona.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>
	<4BCDFCC8.2020505@wyona.com>
Message-ID: <x2o5bf1397d1004202345p4e18cd86j20f51347480d8185@mail.gmail.com>

On Tue, Apr 20, 2010 at 9:13 PM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>> I am trying to use the contact-form resource provided by Yanel. As
>> described in the documentation (
>> http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html), I
>> have put this in my local.yanel.xml:
>>
>>  <smtp host=3D"mail.wyona.com <http://mail.wyona.com>" port=3D"25"/>
>>
>>
>> but I still get a
>>
>>    java.net.UnknownHostException: mail.foo.bar
>>
>
> did you restart Yanel after this change?
>
>
>> The same thing happens when I put the line above in the realm.xml of my
>> realm.
>>
>
> where did you get this idea from? IIRC I once wrote an email about this
> that it might make sense that each realm
> could have its own mail server configuration, but I do not think we have
> ever implemented this.
>

obviously I misunderstood, sorry



>
> Cheers
>
> Michi
>
>>
>> Does anyone know why this is happening? Am I doing something wrong?
>>
>> Thanks,
>>
>> Memo
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
1/6927c021/attachment-0001.htm
From michael.wechner at wyona.com  Wed Apr 21 09:04:35 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 21 09:18:24 2010
Subject: [Yanel-dev] Re: Contact Form
In-Reply-To: <x2k5bf1397d1004202344s5398d8acqfaa7a560e6dd7401@mail.gmail.com>
References: <q2v5bf1397d1004200902o2d11b408x9c9f55b11fc67f66@mail.gmail.com>	<r2s5bf1397d1004200933xa9c2b6a5id9503b24217c6cd2@mail.gmail.com>	<4BCDFA01.4080908@wyona.com>
	<x2k5bf1397d1004202344s5398d8acqfaa7a560e6dd7401@mail.gmail.com>
Message-ID: <4BCEA383.6050607@wyona.com>

Mehmet Birgi wrote:
>
>     Do you mean
>
>     http://www.yanel.org/en/documentation/configuration/yanel_xml.html
>
>     or
>
>     http://www.yanel.org/en/documentation/misc/smtp-configuration.html
>
>     I would be glad if you could update both pages.
>
>
> I will, right away

thanks very much

Michi
>
> Cheers,
>
> Memo
>
>  
>
>
>     Thanks
>
>     Michi
>
>
>         Thanks,
>
>         Mehmet
>
>
>
>
>         On Tue, Apr 20, 2010 at 6:02 PM, Mehmet Birgi
>         <mehmet.birgi@wyona.com <mailto:mehmet.birgi@wyona.com>
>         <mailto:mehmet.birgi@wyona.com
>         <mailto:mehmet.birgi@wyona.com>>> wrote:
>
>            I am trying to use the contact-form resource provided by
>         Yanel. As
>            described in the documentation
>          
>          (http://yanel.wyona.org/en/documentation/misc/smtp-configuration.html),
>            I have put this in my local.yanel.xml:
>
>              <smtp host="mail.wyona.com <http://mail.wyona.com>
>         <http://mail.wyona.com>" port="25"/>
>
>
>            but I still get a
>
>                java.net.UnknownHostException: mail.foo.bar
>
>            The same thing happens when I put the line above in the
>         realm.xml
>            of my realm.
>
>            Does anyone know why this is happening? Am I doing
>         something wrong?
>
>            Thanks,
>
>            Memo
>
>
>            --     Mehmet Birgi
>            www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>
>
>         -- 
>         Mehmet Birgi
>         www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From michael.wechner at wyona.com  Wed Apr 21 12:00:38 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 21 12:14:27 2010
Subject: [Yanel-dev] special characters problem within subject of contact
	form
Message-ID: <4BCECCC6.8070601@wyona.com>

Hi

I tried to use the contact form with special characters within the 
subject of the email, but this didn't work.

Any idea what might be wrong?

Shall I create a bug-entry?

Thanks

Michi
From bugzilla at wyona.com  Wed Apr 21 13:48:19 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 13:48:25 2010
Subject: [Yanel-dev] [Bug 7531] resource-types package configurations get
	lost
Message-ID: <20100421114819.3543110CD4E@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7531





------- Comment #2 from guillaume.deflache@wyona.com  2010-04-21 12:43 -------
I changed:
if (!resourceTypeExists(srcAttr, rootElement)) {

to:
if (srcAttr == null || srcAttr.equals("") || !resourceTypeExists(srcAttr,
rootElement)) {

and it seems to work as expected with default development build settings for
me.

The problem was that for a "package" resource-type there is no 'src' attribute,
srcAttr gets empty but this also happens for all other "package"
resource-types, so the RT is seen as a duplicate by the 'resourceTypeExists'
method.

AFAICS this is broken since r42497.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 21 14:13:21 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 14:19:05 2010
Subject: [Yanel-dev] [Bug 7531] resource-types package configurations get
	lost
Message-ID: <20100421121321.AA05310CDB0@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7531





------- Comment #3 from michael.wechner@wyona.org  2010-04-21 13:08 -------
sounds great :-) Can you attach a patch and I will be happy to test/review it
as well?

Thanks

Michi


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 21 14:42:23 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 14:56:17 2010
Subject: [Yanel-dev] [Bug 7531] resource-types package configurations get
	lost
Message-ID: <20100421124223.CE2C210CB8C@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7531





------- Comment #4 from guillaume.deflache@wyona.com  2010-04-21 13:37 -------
Created an attachment (id=1294)
 --> (http://bugzilla.wyona.com/cgi-bin/bugzilla/attachment.cgi?id=1294&action=view)
fix suggested in comment 2 with some debug logging


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 21 16:14:54 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 16:36:29 2010
Subject: [Yanel-dev] [Bug 7573] New: no way to define a policy for all users
Message-ID: <20100421141454.96ED310CB8C@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7573

           Summary: no way to define a policy for all users
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Security
        AssignedTo: michael.wechner@wyona.org
        ReportedBy: guillaume.deflache@wyona.com
         QAContact: yanel-development@wyona.com


In *.policy files there is no way to define a policy for all users registered
in a realm.
This forces to define a group, ensure all users are initially added to this
group and stay in it, and apply the policies to this group.

When the total number of users gets large, this may quickly become a problem!


First we could define a XML format for defining the policy: I'd suggest
"<all-users/>".

Second we may need to change some APIs, for example
org.wyona.security.core.UsecasePolicy only deals with identities (including
WORLD) and groups.
Maybe "all-users" could be a special case of Identity?


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 21 16:34:30 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 16:58:05 2010
Subject: [Yanel-dev] [Bug 7573] no way to define a policy for all users
Message-ID: <20100421143430.AB39610CE23@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7573





------- Comment #1 from guillaume.deflache@wyona.com  2010-04-21 15:29 -------
It just came to me one might be able to implement a virtual Group object
containing all users.
One would get it from the GroupManager when asking it for the group with ID
"yanel:realm:<realm-ID>:all-users" for example.
Not sure the syntax should not be "wyona-security:all-users" instead, as the
GroupManager is and should probably be unaware of realms.
Anyway to do that we would at least need the GroupManager to be aware of the
UserManager.
Beware of infinite loops if we ever want to implement a virtual user that
belongs to all groups! :P


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From mehmet.birgi at wyona.com  Wed Apr 21 17:38:39 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr 21 17:52:31 2010
Subject: [Yanel-dev] special characters problem within subject of contact 
	form
In-Reply-To: <4BCECCC6.8070601@wyona.com>
References: <4BCECCC6.8070601@wyona.com>
Message-ID: <m2j5bf1397d1004210838p9121cda4w6da1d34fcf91231a@mail.gmail.com>

Hi

I have just realized hat this problem is not limited to the subject, but
also occurs  in the body of the email sent. I will make a Bugzilla entry for
this, just in case.

Cheers,

Memo



On Wed, Apr 21, 2010 at 12:00 PM, Michael Wechner <michael.wechner@wyona.com
> wrote:

> Hi
>
> I tried to use the contact form with special characters within the subject
> of the email, but this didn't work.
>
> Any idea what might be wrong?
>
> Shall I create a bug-entry?
>
> Thanks
>
> Michi
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
1/0e7a014d/attachment.htm
From bugzilla at wyona.com  Wed Apr 21 17:56:37 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 21 17:56:39 2010
Subject: [Yanel-dev] [Bug 7574] New: Special character problem in contact
	form resource
Message-ID: <20100421155637.77D2B10CBFB@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7574

           Summary: Special character problem in contact form resource
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal (C)
          Priority: P2
         Component: General
        AssignedTo: michael.wechner@wyona.org
        ReportedBy: mehmet.birgi@wyona.com
         QAContact: yanel-development@wyona.com


The contact form resource (.../src/contributions/resources/contact-form/) does
not convey special characters (e.g. umlauts) correctly into the generated
email. It looks like they are being replaced by other special characters.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From michael.wechner at wyona.com  Wed Apr 21 22:52:59 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 21 23:10:14 2010
Subject: [Yanel-dev] special characters problem within subject of contact
	form
In-Reply-To: <m2j5bf1397d1004210838p9121cda4w6da1d34fcf91231a@mail.gmail.com>
References: <4BCECCC6.8070601@wyona.com>
	<m2j5bf1397d1004210838p9121cda4w6da1d34fcf91231a@mail.gmail.com>
Message-ID: <4BCF65AB.6080307@wyona.com>

Mehmet Birgi wrote:
> Hi
>
> I have just realized hat this problem is not limited to the subject, 
> but also occurs  in the body of the email sent. I will make a Bugzilla 
> entry for this, just in case.

yes, please do, but please be aware that this might be a Mac OS X 
related issue, because I know in other cases that this
works fine and I think it is rather a locale thing instead a generic 
problem. So either test it on other platforms, e.g. Ubuntu Linux
and german locale or at least specify your OS within Bugzilla.

Thanks

Michi
>
> Cheers,
>
> Memo
>
>
>
> On Wed, Apr 21, 2010 at 12:00 PM, Michael Wechner 
> <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>     Hi
>
>     I tried to use the contact form with special characters within the
>     subject of the email, but this didn't work.
>
>     Any idea what might be wrong?
>
>     Shall I create a bug-entry?
>
>     Thanks
>
>     Michi
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From bugzilla at wyona.com  Thu Apr 22 08:42:21 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Thu Apr 22 08:43:12 2010
Subject: [Yanel-dev] [Bug 7574] Special character problem in contact form
	resource
Message-ID: <20100422064221.2E95010CE4A@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7574





------- Comment #1 from mehmet.birgi@wyona.com  2010-04-22 07:37 -------
Note: This issue has so far been detected on Mac OSX with locale set to
english, and not yet tested with other configurations.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From mehmet.birgi at wyona.com  Thu Apr 22 08:29:25 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr 22 08:43:18 2010
Subject: [Yanel-dev] special characters problem within subject of contact 
	form
In-Reply-To: <4BCF65AB.6080307@wyona.com>
References: <4BCECCC6.8070601@wyona.com>
	<m2j5bf1397d1004210838p9121cda4w6da1d34fcf91231a@mail.gmail.com>
	<4BCF65AB.6080307@wyona.com>
Message-ID: <n2y5bf1397d1004212329p337c8a41lb27fe0c2e7336760@mail.gmail.com>

On Wed, Apr 21, 2010 at 10:52 PM, Michael Wechner <michael.wechner@wyona.com
> wrote:

> Mehmet Birgi wrote:
>
>> Hi
>>
>> I have just realized hat this problem is not limited to the subject, but
>> also occurs  in the body of the email sent. I will make a Bugzilla entry=
 for
>> this, just in case.
>>
>
> yes, please do, but please be aware that this might be a Mac OS X related
> issue, because I know in other cases that this
> works fine and I think it is rather a locale thing instead a generic
> problem. So either test it on other platforms, e.g. Ubuntu Linux
> and german locale or at least specify your OS within Bugzilla.
>

I have made a comment about this in Bugzilla, please let me know if you want
me to look deeper into the issue.

Thanks,

Memo



> Thanks
>
> Michi
>
>>
>> Cheers,
>>
>> Memo
>>
>>
>>
>>
>> On Wed, Apr 21, 2010 at 12:00 PM, Michael Wechner <
>> michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>>
>>    Hi
>>
>>    I tried to use the contact form with special characters within the
>>    subject of the email, but this didn't work.
>>
>>    Any idea what might be wrong?
>>
>>    Shall I create a bug-entry?
>>
>>    Thanks
>>
>>    Michi
>>    --     Yanel-development mailing list Yanel-development@wyona.com
>>    <mailto:Yanel-development@wyona.com>
>>
>>    http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>>
>>
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
2/23584fd2/attachment-0001.htm
From michael.wechner at wyona.com  Thu Apr 22 09:16:30 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr 22 09:30:19 2010
Subject: [Yanel-dev] special characters problem within subject of contact
	form
In-Reply-To: <n2y5bf1397d1004212329p337c8a41lb27fe0c2e7336760@mail.gmail.com>
References: <4BCECCC6.8070601@wyona.com>	<m2j5bf1397d1004210838p9121cda4w6da1d34fcf91231a@mail.gmail.com>	<4BCF65AB.6080307@wyona.com>
	<n2y5bf1397d1004212329p337c8a41lb27fe0c2e7336760@mail.gmail.com>
Message-ID: <4BCFF7CE.5030403@wyona.com>

Mehmet Birgi wrote:
>
>
> On Wed, Apr 21, 2010 at 10:52 PM, Michael Wechner 
> <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>     Mehmet Birgi wrote:
>
>         Hi
>
>         I have just realized hat this problem is not limited to the
>         subject, but also occurs  in the body of the email sent. I
>         will make a Bugzilla entry for this, just in case.
>
>
>     yes, please do, but please be aware that this might be a Mac OS X
>     related issue, because I know in other cases that this
>     works fine and I think it is rather a locale thing instead a
>     generic problem. So either test it on other platforms, e.g. Ubuntu
>     Linux
>     and german locale or at least specify your OS within Bugzilla.
>
>
> I have made a comment about this in Bugzilla, please let me know if 
> you want me to look deeper into the issue.

not right now, but you might want to keep it in the back of your mind.

Cheers

Michi
>
> Thanks,
>
> Memo
>
>
>
>     Thanks
>
>     Michi
>
>
>         Cheers,
>
>         Memo
>
>
>
>
>         On Wed, Apr 21, 2010 at 12:00 PM, Michael Wechner
>         <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>
>         <mailto:michael.wechner@wyona.com
>         <mailto:michael.wechner@wyona.com>>> wrote:
>
>            Hi
>
>            I tried to use the contact form with special characters
>         within the
>            subject of the email, but this didn't work.
>
>            Any idea what might be wrong?
>
>            Shall I create a bug-entry?
>
>            Thanks
>
>            Michi
>            --     Yanel-development mailing list
>         Yanel-development@wyona.com <mailto:Yanel-development@wyona.com>
>            <mailto:Yanel-development@wyona.com
>         <mailto:Yanel-development@wyona.com>>
>
>          
>          http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
>         -- 
>         Mehmet Birgi
>         www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From guillaume.deflache at wyona.com  Thu Apr 22 13:39:49 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-15?Q?Guillaume_D=E9flache?=)
Date: Thu Apr 22 13:56:24 2010
Subject: [Yanel-dev] simplifying development of project-specific
 resource-types and project file-layout
Message-ID: <4BD03585.6060406@wyona.com>

Hi!

For some time now it has been possible in Yanel to specific 
project-specific resource-types (RTs) in a resource-types.xml in your 
realm-directory, cf. 
http://yanel.wyona.org/en/documentation/configuration/resource-types_xml.html

Also even before that it was already possible to gather several RTs 
under a single directory, using resource-*.xml files alongside the usual 
resource.xml file (unfortunately it may not be documented anywhere ATM :/).
AFAICU this was done to avoid having to create and adapt a lot of files 
and directories (to the very minimal build.xml, 
src/build/build.properties, src/build/dependencies.xml, htdocs/, 
src/java/tld/project/) just to define some new routing logic in Java, in 
addition to the absolutely needed *Resource.java Java source file and 
resource*.xml resource-type definition XML file.

IMHO project-specific RTs that are unlikely to be reused elsewhere (in 
Yanel or in other projects) do not need the kind of file-based 
modularity that generic Yanel RTs do.
So in the project I am currently working on I tried to make it even 
simpler by putting the Java source file and the XML definition file for 
project-specific RTs simply under their own package (as one must always 
do anyway) along with the other Java sources of the project (for example 
next to the Java source file for the project-specific Yanel toolbar menu).

Advantages:
- project-specific Java source files are all located under the same 
source directory (but in can still arrange them by feature as you would 
otherwise do)
- it is impossible for project-specific RTs to "collide" because they 
use the same package: there can only be one "resource.xml" per 
directory, so only one RT per Java package
- one does not need to declare dependencies between project-specific RTs 
and/or the realm, because they all are available together in the same 
realm JAR
- under Eclipse as all sources live in the same Eclipse project, one can 
source-debug and do hot-code replacement the whole application without 
any glitches (cf in 
http://yanel.wyona.org/en/documentation/development/build_setup_eclipse_ide.html 
the final TODO: "Document how to create a debug configuration andhow to 
debug across multiple resource-types, which may still be tricky.")
- it is easier to move code from one RT to another or to and from the 
common project code
- maybe more?

Disadvantages:
- one does not have one separate "htdocs" per directory, but this was 
already the case when putting several resource-types under a single 
directory
- it needs getting used to
- probably more I didn't think about, but I think it's well worth trying

HTH,
    Guillaume
From michael.wechner at wyona.com  Thu Apr 22 23:56:06 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 23 00:10:03 2010
Subject: [Yanel-dev] Google analytics integration documentation started
Message-ID: <4BD0C5F6.7030602@wyona.com>

Hi

I have started the Google analytics integration documentation at

http://www.yanel.org/en/documentation/misc/google-analytics-integration.html

whereas I have listed the relevant files how this used within the Yanel 
website realm.

Cheers

Michi
From michael.wechner at wyona.com  Fri Apr 23 09:59:11 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 23 10:21:25 2010
Subject: [Yanel-dev] simplifying development of project-specific
	resource-types and project file-layout
In-Reply-To: <4BD03585.6060406@wyona.com>
References: <4BD03585.6060406@wyona.com>
Message-ID: <4BD1534F.3030104@wyona.com>

Guillaume D?flache wrote:
> Hi!
>
> For some time now it has been possible in Yanel to specific 
> project-specific resource-types (RTs) in a resource-types.xml in your 
> realm-directory, cf. 
> http://yanel.wyona.org/en/documentation/configuration/resource-types_xml.html 
>
>
> Also even before that it was already possible to gather several RTs 
> under a single directory, using resource-*.xml files alongside the 
> usual resource.xml file (unfortunately it may not be documented 
> anywhere ATM :/).
> AFAICU this was done to avoid having to create and adapt a lot of 
> files and directories (to the very minimal build.xml, 
> src/build/build.properties, src/build/dependencies.xml, htdocs/, 
> src/java/tld/project/) just to define some new routing logic in Java, 
> in addition to the absolutely needed *Resource.java Java source file 
> and resource*.xml resource-type definition XML file.
>
> IMHO project-specific RTs that are unlikely to be reused elsewhere (in 
> Yanel or in other projects) do not need the kind of file-based 
> modularity that generic Yanel RTs do.

not really. It happens that one is developing a resource within a realm 
and then realizes that this is quite generic and hence
it is being factored into a more generic location.




> So in the project I am currently working on I tried to make it even 
> simpler by putting the Java source file and the XML definition file 
> for project-specific RTs simply under their own package (as one must 
> always do anyway

only if referenced as package


> ) along with the other Java sources of the project (for example next 
> to the Java source file for the project-specific Yanel toolbar menu).
>
> Advantages:
> - project-specific Java source files are all located under the same 
> source directory (but in can still arrange them by feature as you 
> would otherwise do)
> - it is impossible for project-specific RTs to "collide" because they 
> use the same package: there can only be one "resource.xml" per 
> directory, so only one RT per Java package

you can still have different realms using the same package name hence 
producing collisions. I am mentioning this, because
people should not rely on this



> - one does not need to declare dependencies between project-specific 
> RTs and/or the realm, because they all are available together in the 
> same realm JAR

again this is a question if one want might want to re-use resource types 
in a more generic way.

It's like defining interfaces and libs. More work, but better re-usability.


> - under Eclipse as all sources live in the same Eclipse project, one 
> can source-debug and do hot-code replacement the whole application 
> without any glitches (cf in 
> http://yanel.wyona.org/en/documentation/development/build_setup_eclipse_ide.html 
> the final TODO: "Document how to create a debug configuration andhow 
> to debug across multiple resource-types, which may still be tricky.")
> - it is easier to move code from one RT to another or to and from the 
> common project code
> - maybe more?

I strongly disagree to shape technology after specific IDEs


>
> Disadvantages:
> - one does not have one separate "htdocs" per directory, but this was 
> already the case when putting several resource-types under a single 
> directory
> - it needs getting used to
> - probably more I didn't think about, but I think it's well worth trying

have you checked re resource types documentation if this still works?

In certain cases (e.g. very specific realm resource types) the above 
might make sense, but I think one has to be aware of the following:

- Re-usability out of realm becomes very hard
- Documentation is needed
- Some features might not be supported anymore (remains to be seen)

Cheers

Michi


>
> HTH,
>    Guillaume

From michael.wechner at wyona.com  Fri Apr 23 10:41:34 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 23 10:55:25 2010
Subject: [Yanel-dev] Location of realm files/directories: realm.xml,
 resource-types.xml, build.xml and build directory
Message-ID: <4BD15D3E.6070001@wyona.com>

Hi

If you do not want to experience any surprises, then it is important to 
keep the following files within your ROOT realm directory:

- realm.xml
- resource-types.xml
- build.xml

because otherwise the generic Yanel build process might not do what you 
expect it to do.

Also make sure that your realm build directory is located on the same 
level, because otherwise your realm-jar is built, but
not copied into the Yanel webapps lib folder.

I agree that it would be nice if these conventions could be a bit more 
relaxed, but it would need some work
on the build processes. Any contributions are of course welcome.

Thanks

Michi
From michael.wechner at wyona.com  Fri Apr 23 14:56:07 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 23 15:09:58 2010
Subject: [Yanel-dev] Google analytics exit link onclick problem
Message-ID: <4BD198E7.7090209@wyona.com>

Hi

I have refactored the Google analytics code slightly and have noticed 
that it currently does not allow re onlick() to differentiate
between external and internal links starting with http or https, e.g. 
let's assume we have have a page

http://localhost:8080/yanel/foo/bar.html

which contains the following links

http://localhost:8080/yanel/foo/bob.html
http://www.nyt.com/yanel/foo/bob.html

then both links will be sent to Google analytics as

/yanel/foo/bob.html

because the method/function Yanel_requestURIFromFQURL within

src/webapp/htdocs/Google-Analytics/GA.xslt

is cuttinng off the protocol and the hostname, because AFAIK Google does not
allow protocol and hostname to be sent.

Any idea how to improve this, because it would actually be nice to 
analyze exit links?

(in particular re goals/funnels: 
http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55515)

Thanks

Michi


From bruno.vonrotz at wyona.com  Fri Apr 23 15:37:55 2010
From: bruno.vonrotz at wyona.com (Bruno von Rotz)
Date: Fri Apr 23 16:00:02 2010
Subject: [Yanel-dev] Google analytics exit link onclick problem
In-Reply-To: <4BD198E7.7090209@wyona.com>
References: <4BD198E7.7090209@wyona.com>
Message-ID: <4BD1A2B3.7090604@wyona.com>

couldn't we alter the suffix?
We could have html_e or htmle to highlight external links. The problem 
though is that you still wouldn't know where it went.
Bruno

Michael Wechner schrieb:
> Hi
>
> I have refactored the Google analytics code slightly and have noticed 
> that it currently does not allow re onlick() to differentiate
> between external and internal links starting with http or https, e.g. 
> let's assume we have have a page
>
> http://localhost:8080/yanel/foo/bar.html
>
> which contains the following links
>
> http://localhost:8080/yanel/foo/bob.html
> http://www.nyt.com/yanel/foo/bob.html
>
> then both links will be sent to Google analytics as
>
> /yanel/foo/bob.html
>
> because the method/function Yanel_requestURIFromFQURL within
>
> src/webapp/htdocs/Google-Analytics/GA.xslt
>
> is cuttinng off the protocol and the hostname, because AFAIK Google 
> does not
> allow protocol and hostname to be sent.
>
> Any idea how to improve this, because it would actually be nice to 
> analyze exit links?
>
> (in particular re goals/funnels: 
> http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55515) 
>
>
> Thanks
>
> Michi
>
>


-- 
______________________________
Bruno von Rotz
WYONA
Hardstrasse 219 
CH-8005 Z?rich 
Switzerland 
P: +41 44 272 91 61 
F: +41 44 272 91 62 
skype: wyona-switzerland
email: bruno.vonrotz@wyona.com
www.wyona.com 

From michael.wechner at wyona.com  Fri Apr 23 23:59:13 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Sat Apr 24 00:13:13 2010
Subject: [Yanel-dev] Google analytics exit link onclick problem
In-Reply-To: <4BD1A2B3.7090604@wyona.com>
References: <4BD198E7.7090209@wyona.com> <4BD1A2B3.7090604@wyona.com>
Message-ID: <4BD21831.5010905@wyona.com>

Bruno von Rotz wrote:
> couldn't we alter the suffix?
> We could have html_e or htmle to highlight external links. The problem 
> though is that you still wouldn't know where it went.

I think we should introduce a "reserved prefix" and map an URL like for 
example

http://www.nyt.com/yanel/foo/bob.html

to

/EXIT_www.nyt.com/yanel/foo/bob.html

which is similar as described here

http://groups.google.com/group/analytics-help-tracking/browse_thread/thread/f44df0d094752c28
http://seogadget.co.uk/how-to-count-your-outbound-click-stats-with-onclick-in-google-analytics/

WDYT?

Thanks

Michi
> Bruno
>
> Michael Wechner schrieb:
>> Hi
>>
>> I have refactored the Google analytics code slightly and have noticed 
>> that it currently does not allow re onlick() to differentiate
>> between external and internal links starting with http or https, e.g. 
>> let's assume we have have a page
>>
>> http://localhost:8080/yanel/foo/bar.html
>>
>> which contains the following links
>>
>> http://localhost:8080/yanel/foo/bob.html
>> http://www.nyt.com/yanel/foo/bob.html
>>
>> then both links will be sent to Google analytics as
>>
>> /yanel/foo/bob.html
>>
>> because the method/function Yanel_requestURIFromFQURL within
>>
>> src/webapp/htdocs/Google-Analytics/GA.xslt
>>
>> is cuttinng off the protocol and the hostname, because AFAIK Google 
>> does not
>> allow protocol and hostname to be sent.
>>
>> Any idea how to improve this, because it would actually be nice to 
>> analyze exit links?
>>
>> (in particular re goals/funnels: 
>> http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55515) 
>>
>>
>> Thanks
>>
>> Michi
>>
>>
>
>

From guillaume.deflache at wyona.com  Mon Apr 26 19:33:34 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Mon Apr 26 19:47:18 2010
Subject: [Yanel-dev] Google analytics exit link onclick problem
In-Reply-To: <4BD198E7.7090209@wyona.com>
References: <4BD198E7.7090209@wyona.com>
Message-ID: <4BD5CE6E.2010407@wyona.com>

Hi!

Michael Wechner schrieb:
> Hi
> 
> I have refactored the Google analytics code slightly and have noticed 
> that it currently does not allow re onlick() to differentiate
> between external and internal links starting with http or https, e.g. 
> let's assume we have have a page
> 
> http://localhost:8080/yanel/foo/bar.html
> 
> which contains the following links
> 
> http://localhost:8080/yanel/foo/bob.html
> http://www.nyt.com/yanel/foo/bob.html
> 
> then both links will be sent to Google analytics as
> 
> /yanel/foo/bob.html
> 
> because the method/function Yanel_requestURIFromFQURL within
> 
> src/webapp/htdocs/Google-Analytics/GA.xslt
> 
> is cuttinng off the protocol and the hostname, because AFAIK Google does 
> not
> allow protocol and hostname to be sent.

I found why I excluded full URLs original: the documentation for the 
'_trackPageview' method at 
http://code.google.com/intl/en/apis/analytics/docs/gaJS/gaJSApiBasicConfiguration.html#_gat.GA_Tracker_._trackPageview 
says to "use a beginning slash (/) to indicate the page URL."
Also see http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7169 
for the initial design ideas.


> Any idea how to improve this, because it would actually be nice to 
> analyze exit links?
> 
> (in particular re goals/funnels: 
> http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=55515) 

Google recommends using event tracking, cf. 
http://www.google.com/support/googleanalytics/bin/answer.py?answer=55527


Google also documents how to use event tracking also for downloads, 
which may be less of a hack than the above method, and can apparently do 
more: in 
http://code.google.com/intl/en/apis/analytics/docs/tracking/eventTrackerGuide.html 
search for "download"

HTH,
    Guillaume
From mehmet.birgi at wyona.com  Tue Apr 27 19:53:48 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Tue Apr 27 20:07:49 2010
Subject: [Yanel-dev] Login/Register
Message-ID: <m2h5bf1397d1004271053v8b3acab5q8065617be0871d42@mail.gmail.com>

Hi

On my current project, we need a way to refer anonymous users to a page
where they can login or - in case they are not registered yet - register. Of
course, after doing either one of these, they should be returned to the
original page they were visiting (the redirect resource seems to be doing
this, but only almost, as I couldn't find a way to make the redirect dynamic
instead of defining it in the res-config).

Afaics, there is no way to do either of these at the moment, but maybe I'm
overlooking something? If there is no ready solution, how would you embark
on implementing these features?

Thanks,

Memo


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
7/bdf86e9d/attachment.htm
From michael.wechner at wyona.com  Wed Apr 28 07:50:09 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Wed Apr 28 08:04:19 2010
Subject: [Yanel-dev] Login/Register
In-Reply-To: <m2h5bf1397d1004271053v8b3acab5q8065617be0871d42@mail.gmail.com>
References: <m2h5bf1397d1004271053v8b3acab5q8065617be0871d42@mail.gmail.com>
Message-ID: <4BD7CC91.8090305@wyona.com>

Mehmet Birgi wrote:
> Hi
>
> On my current project, we need a way to refer anonymous users to a 
> page where they can login or - in case they are not registered yet - 
> register.

you mean there is a login/register link on the page somewhere?


> Of course, after doing either one of these, they should be returned to 
> the original page they were visiting (the redirect resource seems to 
> be doing this, but only almost, as I couldn't find a way to make the 
> redirect dynamic instead of defining it in the res-config).
>
> Afaics, there is no way to do either of these at the moment, but maybe 
> I'm overlooking something? If there is no ready solution, how would 
> you embark on implementing these features?

one way would be to use the referer, but this only works if the person 
first accessed your site, but not via email link or something
similar.

Or what about an overlay (at least for the login)?

But yes, none of the above exists out-of-the-box yet, but the pieces are 
all there and "just" need to be assembled.

Cheers

Michi
>
> Thanks,
>
> Memo
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From bugzilla at wyona.com  Wed Apr 28 09:36:49 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 28 09:36:51 2010
Subject: [Yanel-dev] [Bug 7579] New: TinyMCE garbles special characters
Message-ID: <20100428073649.81C2210CA42@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7579

           Summary: TinyMCE garbles special characters
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal (C)
          Priority: P2
         Component: General
        AssignedTo: michael.wechner@wyona.org
        ReportedBy: mehmet.birgi@wyona.com
         QAContact: yanel-development@wyona.com


When I opened an existing HTML page (marked UTF-8, containing umlauts) for
editing with TinyMCE for the first time, it seems to have converted all the
umlauts to "some" numbered entities, but not the correct ones, so that
afterwards the text was quite illegible. When I enter the umlauts in TinyMCE,
or when I change those incorrect ones to the correct ones, it seems to work.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 28 09:45:41 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 28 09:45:43 2010
Subject: [Yanel-dev] [Bug 7581] New: sending E-mails using a remote SMTP
	server
Message-ID: <20100428074541.B0F4910CA48@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7581

           Summary: sending E-mails using a remote SMTP server
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Security
        AssignedTo: michael.wechner@wyona.org
        ReportedBy: guillaume.deflache@wyona.com
         QAContact: yanel-development@wyona.com


In <http://lists.wyona.org/cgi-bin/mailman/private/dev/2010-April/001495.html>
I provided an *unsecure* patch to send E-mails using login/password using a
remote SMTP server without using SSL or TLS, so AFAIK sending easy to sniff
login and password!

I am about to add the patch there anyway, IMHO the minimal improvements needed
for inclusion into Yanel are:
- the parametrization has to be improved so that the login and password are
read from a separate file with minimal read permissions
- we should (at least try to) use encryption


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From bugzilla at wyona.com  Wed Apr 28 09:49:24 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 28 09:49:25 2010
Subject: [Yanel-dev] [Bug 7581] sending E-mails using a remote SMTP server
Message-ID: <20100428074924.24E8910CA47@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7581





------- Comment #1 from guillaume.deflache@wyona.com  2010-04-28 08:43 -------
Created an attachment (id=1297)
 --> (http://bugzilla.wyona.com/cgi-bin/bugzilla/attachment.cgi?id=1297&action=view)
*unsecure* patch to send E-mails using login/password using a remote SMTP
server without using SSL or TLS


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From mehmet.birgi at wyona.com  Wed Apr 28 09:39:33 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Wed Apr 28 09:53:35 2010
Subject: [Yanel-dev] Login/Register
In-Reply-To: <4BD7CC91.8090305@wyona.com>
References: <m2h5bf1397d1004271053v8b3acab5q8065617be0871d42@mail.gmail.com>
	<4BD7CC91.8090305@wyona.com>
Message-ID: <q2j5bf1397d1004280039h5846ba7chfd44a21c9fb5e8e4@mail.gmail.com>

On Wed, Apr 28, 2010 at 7:50 AM, Michael Wechner
<michael.wechner@wyona.com>wrote:

> Mehmet Birgi wrote:
>
>> Hi
>>
>> On my current project, we need a way to refer anonymous users to a page
>> where they can login or - in case they are not registered yet - register.
>>
>
> you mean there is a login/register link on the page somewhere?


Yes. This appears for example when a user is not logged in and requests a
page where he/she can only see limited content while anonymous. In this
case, there is a part in the line of:

"This content is only available to registered users. Please *login* or *
register*."

These links should point to the login/registration pages respectively, and
after that, take the user back to the previously unavailable page, which, if
the user is logged in now, would show the content.


>
>
>  Of course, after doing either one of these, they should be returned to t=
he
>> original page they were visiting (the redirect resource seems to be doing
>> this, but only almost, as I couldn't find a way to make the redirect dyn=
amic
>> instead of defining it in the res-config).
>>
>> Afaics, there is no way to do either of these at the moment, but maybe I=
'm
>> overlooking something? If there is no ready solution, how would you emba=
rk
>> on implementing these features?
>>
>
> one way would be to use the referer, but this only works if the person
> first accessed your site, but not via email link or something
> similar.
>

maybe we could implement a check to see if the referer is part of our site,
and if not, redirect to the start page?


>
> Or what about an overlay (at least for the login)?
>

how would that work?

also, afaics, there is no specific URL to call the login page, which would
probably be needed?

cheers,

memo





>
> But yes, none of the above exists out-of-the-box yet, but the pieces are
> all there and "just" need to be assembled.
>
> Cheers
>
> Michi
>
>>
>> Thanks,
>>
>> Memo
>>
>>
>> --
>> Mehmet Birgi
>> www.wyona.com <http://www.wyona.com>
>>
>>
> --
> Yanel-development mailing list Yanel-development@wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>



-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
8/50a4615b/attachment.htm
From bugzilla at wyona.com  Wed Apr 28 10:20:53 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 28 10:20:56 2010
Subject: [Yanel-dev] [Bug 7582] New:
	yanelrepo:<realm-ID>:<repo-ID>:<repo-path> URIs break realm
	modularity and encapsulation
Message-ID: <20100428082053.F1C0910C9C8@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7582

           Summary: yanelrepo:<realm-ID>:<repo-ID>:<repo-path> URIs break
                    realm modularity and encapsulation
           Product: Yanel
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Protocol
        AssignedTo: yanel-development@wyona.com
        ReportedBy: guillaume.deflache@wyona.com
         QAContact: yanel-development@wyona.com


One may use e.g. a yanelrepo:from-scratch:my-repo:/ URL, where "from-scratch"
is the identifier of a realm as defined in realms.xml (and "my-repo" the
identifier of a repository as defined in the realm definition file, e.g.
realm.xml).
The problem is that if realm IDs collide when adding another realm or one
simply wants to use another IDs all similar URL will fail.

One want to limit this would be to make such URLs work: yanelrepo::my-repo:/
These would use the current realm, instead of looking for the realm with ID ""
as they currently do. (I am not sure it is currently even possible to define
realms with empty IDs.)

And maybe we want to forbid use of the URIs with explicit realm IDs, as I am
not sure it is useful, and it is also kind of a security concern as realms can
peek into one another's repositories.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are the assignee for the bug, or are watching the assignee.
From bugzilla at wyona.com  Wed Apr 28 13:39:00 2010
From: bugzilla at wyona.com (bugzilla@wyona.com)
Date: Wed Apr 28 13:39:44 2010
Subject: [Yanel-dev] [Bug 7531] resource-types package configurations get
	lost
Message-ID: <20100428113900.4854810CA27@server1.example.com>

http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7531


guillaume.deflache@wyona.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |next-release




------- Comment #5 from guillaume.deflache@wyona.com  2010-04-28 12:33 -------
I committed the patch in r49096 (debug logging was removed): we needed it badly
for our project! I will monitor Hudson for failures in the next minutes, hope
it's OK that way.


-- 
Configure bugmail: http://bugzilla.wyona.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
From michael.wechner at wyona.com  Thu Apr 29 07:45:13 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr 29 07:59:19 2010
Subject: [Yanel-dev] Login/Register
In-Reply-To: <q2j5bf1397d1004280039h5846ba7chfd44a21c9fb5e8e4@mail.gmail.com>
References: <m2h5bf1397d1004271053v8b3acab5q8065617be0871d42@mail.gmail.com>	<4BD7CC91.8090305@wyona.com>
	<q2j5bf1397d1004280039h5846ba7chfd44a21c9fb5e8e4@mail.gmail.com>
Message-ID: <4BD91CE9.1020707@wyona.com>

Mehmet Birgi wrote:
>
>
> On Wed, Apr 28, 2010 at 7:50 AM, Michael Wechner 
> <michael.wechner@wyona.com <mailto:michael.wechner@wyona.com>> wrote:
>
>     Mehmet Birgi wrote:
>
>         Hi
>
>         On my current project, we need a way to refer anonymous users
>         to a page where they can login or - in case they are not
>         registered yet - register.
>
>
>     you mean there is a login/register link on the page somewhere?
>
>
> Yes. This appears for example when a user is not logged in and 
> requests a page where he/she can only see limited content while 
> anonymous. In this case, there is a part in the line of:
>
> "This content

which content? (I assume the user can see part of the page, but does not 
know which content he/she does not see, right?)
> is only available to registered users. Please _login_ or _register_."
>
> These links should point to the login/registration pages respectively, 
> and after that, take the user back to the previously unavailable page, 
> which, if the user is logged in now, would show the content.

I guess we could enhance the login screen by using the referer
>
>
>
>
>         Of course, after doing either one of these, they should be
>         returned to the original page they were visiting (the redirect
>         resource seems to be doing this, but only almost, as I
>         couldn't find a way to make the redirect dynamic instead of
>         defining it in the res-config).
>
>         Afaics, there is no way to do either of these at the moment,
>         but maybe I'm overlooking something? If there is no ready
>         solution, how would you embark on implementing these features?
>
>
>     one way would be to use the referer, but this only works if the
>     person first accessed your site, but not via email link or something
>     similar.
>
>
> maybe we could implement a check to see if the referer is part of our 
> site, and if not, redirect to the start page?

I guess that would make sense
>  
>
>
>     Or what about an overlay (at least for the login)?
>
>
> how would that work?
>
> also, afaics, there is no specific URL to call the login page, which 
> would probably be needed?

create one.

Cheers

Michi
>
> cheers,
>
> memo
>
>
>
>  
>
>
>     But yes, none of the above exists out-of-the-box yet, but the
>     pieces are all there and "just" need to be assembled.
>
>     Cheers
>
>     Michi
>
>
>         Thanks,
>
>         Memo
>
>
>         -- 
>         Mehmet Birgi
>         www.wyona.com <http://www.wyona.com> <http://www.wyona.com>
>
>
>     -- 
>     Yanel-development mailing list Yanel-development@wyona.com
>     <mailto:Yanel-development@wyona.com>
>     http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
>
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From mehmet.birgi at wyona.com  Thu Apr 29 14:16:09 2010
From: mehmet.birgi at wyona.com (Mehmet Birgi)
Date: Thu Apr 29 14:33:52 2010
Subject: [Yanel-dev] tail -f on Mac OS X
Message-ID: <w2s5bf1397d1004290516kaf27d509rab534c2f8d6f963@mail.gmail.com>

Hi all

For some time now I had the problem that when tailing the Yanel log file (on
Mac OS X Snow Leopard) with "tail -f Yanel/logs/log4j-cnode1.log", after a
while the tail would stop, and new log entries would not get printed on the
screen anymore. The only thing to do was to stop the tail with Ctrl-C, and
restart it. I finally found out the reason: although the log file's name did
not change due to log file rotation, on the mac, its inode number would
change (which apparently may not happen on other filesystems). So, the fix
is really simple: use option -F instead of -f. The manpage for tail says:

"The -F option implies the -f option, but tail will also check to see if the
file being followed has been renamed or rotated.  The file is closed and
reopened when tail detects that the filename being read from has a new inode
number."

It's been working for several hours now, so I thought I would share this
information.

Happy coding,

Memo


-- =

Mehmet Birgi
www.wyona.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wyona.org/pipermail/yanel-development/attachments/2010042=
9/87f4437a/attachment.htm
From michael.wechner at wyona.com  Thu Apr 29 22:42:45 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr 29 22:57:07 2010
Subject: [Yanel-dev] Version change date
Message-ID: <4BD9EF45.7030509@wyona.com>

Hi Guillaume

I assume the version change date is a typo:

http://lists.wyona.org/pipermail/yanel-commits/2010-April/006399.html

I guess it should read 2010042600, right?

Thanks

Michi


From michael.wechner at wyona.com  Thu Apr 29 22:47:07 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr 29 23:01:28 2010
Subject: [Yanel-dev] What is the reason for commit 49051?
Message-ID: <4BD9F04B.1040808@wyona.com>

Hi Guillaume

Why did you reduce the scope of the try-catch block?

http://lists.wyona.org/pipermail/yanel-commits/2010-April/006400.html

Thanks

Michi
From michael.wechner at wyona.com  Thu Apr 29 23:33:24 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Thu Apr 29 23:47:46 2010
Subject: [Yanel-dev] tail -f on Mac OS X
In-Reply-To: <w2s5bf1397d1004290516kaf27d509rab534c2f8d6f963@mail.gmail.com>
References: <w2s5bf1397d1004290516kaf27d509rab534c2f8d6f963@mail.gmail.com>
Message-ID: <4BD9FB24.4020200@wyona.com>

Mehmet Birgi wrote:
> Hi all
>
> For some time now I had the problem that when tailing the Yanel log 
> file (on Mac OS X Snow Leopard) with "tail -f 
> Yanel/logs/log4j-cnode1.log", after a while the tail would stop, and 
> new log entries would not get printed on the screen anymore. The only 
> thing to do was to stop the tail with Ctrl-C, and restart it. I 
> finally found out the reason: although the log file's name did not 
> change due to log file rotation, on the mac, its inode number would 
> change (which apparently may not happen on other filesystems). So, the 
> fix is really simple: use option -F instead of -f. The manpage for 
> tail says:
>
> "The -F option implies the -f option, but tail will also check to see 
> if the file being followed has been renamed or rotated.  The file is 
> closed and reopened when tail detects that the filename being read 
> from has a new inode number."
>
> It's been working for several hours now, so I thought I would share 
> this information.

thanks very much for sharing this info. I have updated

http://www.yanel.org/en/documentation/debugging.html

Thanks

Michi
>
> Happy coding,
>
> Memo
>
>
> -- 
> Mehmet Birgi
> www.wyona.com <http://www.wyona.com>
>

From guillaume.deflache at wyona.com  Fri Apr 30 09:13:04 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Fri Apr 30 09:27:08 2010
Subject: [Yanel-dev] Version change date
In-Reply-To: <4BD9EF45.7030509@wyona.com>
References: <4BD9EF45.7030509@wyona.com>
Message-ID: <4BDA8300.4050105@wyona.com>

Michael Wechner schrieb:
> Hi Guillaume

Hi Michi

> I assume the version change date is a typo:
> 
> http://lists.wyona.org/pipermail/yanel-commits/2010-April/006399.html
> 
> I guess it should read 2010042600, right?

Ooops, yes that's a typo, thanks for spotting it!
SHall I change it now?


Cheers,
    Guillaume
From guillaume.deflache at wyona.com  Fri Apr 30 09:19:02 2010
From: guillaume.deflache at wyona.com (=?ISO-8859-1?Q?Guillaume_D=E9flache?=)
Date: Fri Apr 30 09:33:07 2010
Subject: [Yanel-dev] What is the reason for commit 49051?
In-Reply-To: <4BD9F04B.1040808@wyona.com>
References: <4BD9F04B.1040808@wyona.com>
Message-ID: <4BDA8466.1060802@wyona.com>

Michael Wechner schrieb:
> Hi Guillaume
> 
> Why did you reduce the scope of the try-catch block?
> 
> http://lists.wyona.org/pipermail/yanel-commits/2010-April/006400.html

I did it only to try to make the code easier to understand while working 
on http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7581 and 
because AFAIK reducing scope is generally a good thing, isn't it?

HTH
    Guillaume
From michael.wechner at wyona.com  Fri Apr 30 09:58:35 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 30 10:12:37 2010
Subject: [Yanel-dev] Version change date
In-Reply-To: <4BDA8300.4050105@wyona.com>
References: <4BD9EF45.7030509@wyona.com> <4BDA8300.4050105@wyona.com>
Message-ID: <4BDA8DAB.4050402@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Hi Guillaume
>
> Hi Michi
>
>> I assume the version change date is a typo:
>>
>> http://lists.wyona.org/pipermail/yanel-commits/2010-April/006399.html
>>
>> I guess it should read 2010042600, right?
>
> Ooops, yes that's a typo, thanks for spotting it!
> SHall I change it now?

I have changed the change|/@version now (commit 49146), but did not 
change the actual version, because it has already been used
at various places (e.g. our own server), but I have added a comment how 
to deal with it.

Thanks

Michi
>
>
> Cheers,
>    Guillaume

From michael.wechner at wyona.com  Fri Apr 30 10:46:06 2010
From: michael.wechner at wyona.com (Michael Wechner)
Date: Fri Apr 30 11:00:11 2010
Subject: [Yanel-dev] What is the reason for commit 49051?
In-Reply-To: <4BDA8466.1060802@wyona.com>
References: <4BD9F04B.1040808@wyona.com> <4BDA8466.1060802@wyona.com>
Message-ID: <4BDA98CE.3050209@wyona.com>

Guillaume D?flache wrote:
> Michael Wechner schrieb:
>> Hi Guillaume
>>
>> Why did you reduce the scope of the try-catch block?
>>
>> http://lists.wyona.org/pipermail/yanel-commits/2010-April/006400.html
>
> I did it only to try to make the code easier to understand while 
> working on 
> http://bugzilla.wyona.com/cgi-bin/bugzilla/show_bug.cgi?id=7581 and 
> because AFAIK reducing scope is generally a good thing, isn't it?

I think it depends:

- First of all I think it's always very important to specify a reason 
(and not just say "I did this", and I know I also forget this sometimes, 
but I am glad if people let me know such that I can improve it)

- Second it's kind of like an API, which one relies on.

Cheers

Michi
>
> HTH
>    Guillaume