There is an issue report for it now, so in time if noone has done anything
about it I will. But at the moment I'm trying to get this license header
"fun task" done. So anyone please submit patches for WICKET-87 if you feel
like it :)
Frank
On 11/18/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
But rewriting that.. its a file with almost only static finals.. rewriting
that means that you pretty much type it over
What we could do, and what imo would be a bit nicer, is instead of a
general bucket of client properties (backed by a map), just implement
those properties as actual JavaBe
that's one of the strangest requirements if you ask me.
Why oh why do you want to force that it needs to be a binary inclusion only?
Thats very strange for an opensource thing...
But rewriting that.. its a file with almost only static finals.. rewriting
that means that you pretty much type it ove
http://issues.apache.org/jira/browse/WICKET-87
On 11/17/06, Frank Bille <[EMAIL PROTECTED]> wrote:
I'll add an issue and hope someone volunteers :)
Frank
On 11/17/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote:
>
> You're right. I was confused with BSD. Damn. Seems like we have to
> rewrite i
I'll add an issue and hope someone volunteers :)
Frank
On 11/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
You're right. I was confused with BSD. Damn. Seems like we have to
rewrite it then. To the upside, this isn't very difficult.
Eelco
On 11/17/06, Frank Bille <[EMAIL PROTECTED]> wro
You're right. I was confused with BSD. Damn. Seems like we have to
rewrite it then. To the upside, this isn't very difficult.
Eelco
On 11/17/06, Frank Bille <[EMAIL PROTECTED]> wrote:
On 11/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> ClientProperties is MPL, which should be ok, right
On 11/17/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
ClientProperties is MPL, which should be ok, right?
If I understand [1] correctly then no. We must only have binary inclusion.
So this actually means that we will have to either use it as a library
(include echo as dependency, yeah right
ClientProperties is MPL, which should be ok, right?
Eelco
On 11/16/06, Frank Bille <[EMAIL PROTECTED]> wrote:
All,
I was a little too quick placing ASL2 headers in all the .java files in 2.0.
When looking trough 1.x I found some thirdparty code. I have therefore
looked through all java files w
On 11/16/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
These are public domain, taken from Doug Lea's concurrent utils. Sun
has adopted these for Java 1.5. So for 1.x they need to be there, 2.0
they could be removed in favor of the JDK provided
java.util.concurrent collections.
I don't know h
src/main/java/wicket/util/concurrent/ConcurrentReaderHashMap.java (SUN)
src/main/java/wicket/util/concurrent/ConcurrentHashMap.java (SUN)
src/main/java/wicket/util/concurrent/CopyOnWriteArrayList.java (SUN)
These are public domain, taken from Doug Lea's concurrent utils. Sun
has adopted these for
I think that is too cumbersome. I'd prefer a really simple solution.
Either a one (1) line license header or nothing at all. Based on what
I understood from the mailing discussing there doesn't seem to be a
clear understanding within Apache if Wicket markup is required to have
the license header o
On 11/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
And it increases memory usage. We might not transfer it to the client
but we cache the markup.
Yes thats right. That sounds like stripping license headers (or replacing
with small one-line notices) at build time is the right solution.
And it increases memory usage. We might not transfer it to the client
but we cache the markup.
Juergen
On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote:
But you are right though that we still have that issue with were and if we
strip headers. All pages .html (not extended), .css and .js files
But you are right though that we still have that issue with were and if we
strip headers. All pages .html (not extended), .css and .js files *will*
have the license header and until we come to an agreement between us and ASF
they stay. And that sucks IMO
Frank
On 11/13/06, Igor Vaynberg <[EMAIL
duh
-igor
On 11/13/06, Frank Bille <[EMAIL PROTECTED]> wrote:
Hmm Will you get it returned? It's a panel so it's only the content of it
that gets returned, right?
Frank
On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> just noticed the below
>
> this is a bad joke right?
>
> markup:
Hmm Will you get it returned? It's a panel so it's only the content of it
that gets returned, right?
Frank
On 11/13/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
just noticed the below
this is a bad joke right?
markup: 1line
license: 14 lines
are we stripping the license block somewhere? or
My point is that in checkstyle you are free to enforce both the presence
_and absence_ of anything that can be expressed as a regular expression.
So that includes the $Id$ tag.
That I always enforce inclusion of an $Id$ is just an example. In most
of my projects I don't have a lot of merging t
On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
...i don't hope that #Id# is mandatory!..
It is not required by the ASF license header requirements, if that's
what you mean.
-Bertrand
i don't hope that #Id# is mandatory!
I hate those things. Because those things mess up merging of branches
because they constantly change.
It is totally stupid that this is the case. A merge should ignore those
completely.
johan
On 11/6/06, Erik van Oosten <[EMAIL PROTECTED]> wrote:
Hi Martij
Hi Martijn,
There are checkstyle plugins for Eclipse and for IDEA. Don't know about
Netbeans.
In addition checkstyle is able to check for a header (even as a RE), or
check for the presence/absence of any RE.
I used checkstyle frequently to enforce a correct copyright header, the
presence of
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
Good idea let me play around with that. :)
Don't let me hold you back, it is all yours! (I only want to play with
your toys at a later time)
Martijn
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Anyhow, the check could also be a unit test, and the actual
checking/file scanner could be implemented in Wicket core (though it
is not a specific framework concern imo).
Good idea let me play around with that. :)
Frank
Their site is now out of order, so I couldn't check it. I thought you
could supply a file pattern.
Anyhow, the check could also be a unit test, and the actual
checking/file scanner could be implemented in Wicket core (though it
is not a specific framework concern imo).
All sub projects could the
I don't know checkstyle very well, but doesn't it only handle java code?
Frank
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
> The bad thing about having it as a unittest is that it has to be copied
to
> every subproject and can't j
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
The bad thing about having it as a unittest is that it has to be copied to
every subproject and can't just be run off wicket-parent.
True, that is an argument for using checkstyle.
Martijn
--
http://www.thebeststuffintheworld.com/vote_for/wic
But yeah I forgot the .js files. I'll add them right away.
The bad thing about having it as a unittest is that it has to be copied to
every subproject and can't just be run off wicket-parent.
What to do with all these license headers when "building binaries"/"sending
output to client"/etc. is an
I was going to propose to use checkstyle instead. Problem with
checkstyle is that it is not a unit test and doesn't run inside
Eclipse, NetBeans or IDEA :-).
I would also (as a preliminary action) add javascript to the list
(.js). We can always remove them, but at the moment, they need to be
in t
BTW, all our .java files needs to have it's license updated anyway, because
of [2].
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
Last night when I couldn't sleep I got this crazy idea to write a unittest
for checking the source files in the project for correct license headers.
When I wok
On Oct 3, 2006, at 10:50 PM, Martijn Dashorst wrote:
I ran the RAT tool from Apache on our distribution for 1.2.2, and it
came up with the following files that don't have an ASL header. I
haven't looked into it closely but I think we should clear these up.
These are from the main src directory,
go ahead.
Is there a tool that can quick fix everything?
johan
On 10/3/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
I ran the RAT tool from Apache on our distribution for 1.2.2, and it
came up with the following files that don't have an ASL header. I
haven't looked into it closely but I t
30 matches
Mail list logo
