*grin*
I completely missed this email the first time around. I think JSPWiki
would certainly benefit from the attention - we're fairly close to
having all the bits and pieces in place (minus a release or two).
It's just that we're slightly unsure as to what to do... When I
collected the
The podling Status page hasn't been updated in ages.
http://incubator.apache.org/projects/jspwiki.html
Personally i would at least add some News items in there.
That would help to encourage more participants and helps
the IPMC at graduation review time.
There are some items that i expect are alrea
On Aug 10, 2009, at 06:49 , David Crossley wrote:
Gee, i hope that more people will assist with this offer
to review your project status. That was supposed to be
your week to have some special attention.
It's holiday season - I myself haven't had anything but cellphone
access to the intahwe
I remember when the policy regarding @author tags was set several
years ago. Plenty of projects were using them to identify developers.
Is this documented anywhere? All I could find was a number of
discussions referencing such a decision, but I could not find an
actual document which state
I think a big cause of frustration for poddlings and mentors is the
unpredictable nature of release reviews with each vote for a release
or RC respin getting a different set of best practice requirements
depending on who is around to review.
Yes. If knowing about the policy means wading through
JSPWiki has lost a massive amount of steam in the last year or so due to
committers lives interfering with contributions. No known cure exists for life,
unfortunately.
Simply put, I don't think anyone has the capacity right now to do the
graduation. I do not know whether the situation will ch
+1.
On 16 Apr 2012, at 01:46, Juan Pablo Santos RodrÃguez wrote:
> Hello all,
>
> The Apache JSPWiki project entered Incubator in October of 2007. Since then
> we have added two new committers from diverse organizations. The codebase
> of our product has been growing slowly but surely, and we t
Hello all!
I am Janne Jalkanen, the lead developer of the open source wiki
engine called JSPWiki, and I have a proposal for your enjoyment.
This proposal is available in the web at http://www.jspwiki.org/wiki/
ApacheJSPWikiProposal, should you wish to help us to make it better.
/Janne
This is interesting. Have you seen, that we are currently voting on
the
Jackrabbit list to enter Sling into the incubator. You may find more
information at [1].
Yes, actually I did. I think it is something we can consider
later. JSPWiki needs to do quite a lot of things internally than
I believe Janne has already looked into this and has a good list of
all former contributors. Janne, can you comment on the difficulty of
this challenge?
Already ahead of you. We have all but one tracked down and all have
already agreed. The question is whether they need to sign CLAs or
whe
IANAL, but I am pretty sure you are right. However, I think there
is an issue
on "how simple is simple?". It seems common to talk about 10 lines
of code
are not infringements, but then noone give any hint of an upper
limit. I
think it would be good if it could be documented somehow, to get a
What do you mean? Apache does not have needed lower level projects to
run JSPWiki?
How about Tomcat+Harmony?
Well, let me put it this way: it would be kinda dumb to run our
public wiki site on another wiki engine. ;-)
We also have separate documentation and sandbox wikis.
http://www.jspwiki
In my (totally non-lawyer) opinion, the cleanest way to change the
JSPWiki code to the Apache License might be for the project to release
an Apache License version of their code, before coming to the
Incubator, using their existing release channels.
This would mean that the existing community has
Well, let me put it this way: it would be kinda dumb to run our
public wiki site on another wiki engine. ;-)
Dumb? So we must already be dumb, then, to be running other things
like JVMs
that don't come from the ASF, rather than our own.
Nonono, what I meant was that it would be odd to have
On 6 Sep 2007, at 17:20, Gwyn Evans wrote:
While agreeing that it's something that needs looking at closely, I'm
not I'm not sure it's downbeat as I think you're suggesting. The
3rd-party licencing policy at http://www.apache.org/legal/3party.html
redirects to the draft at http://people.apache.
Is there a roadmap for when JSPWiki will have all of the features and
functionality of both Confluence and MoinMoin, including the
Confluence
macros we use, and the migration tools so that we can move all the
existing
data from these existing wikis to JSPWiki? Without that, I don't
see us
re
Thank you for your vote of confidence. We shall endeavour to be
worth your trust! :-)
/Janne
On 17 Sep 2007, at 23:53, Dave wrote:
On 9/12/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Are we ready to incubate?
Time to sum up the vote:
Votes:
+1 Matthieu Riou
+1 Alexey Petrenko
+1 Ma
JSPWiki could certainly use it! +1 from me...
/Janne
On Nov 15, 2007, at 03:08 , Jukka Zitting wrote:
Hi,
Ben Litchfield, the author of the PDFBox library, has been working
with us at the ApacheCon preparing a proposal to bring PDFBox into the
Apache Incubator. See http://wiki.apache.org/in
> How? Just curious.
We don't have built-in PDF generation from pages, which is one of the
more requested features. Apparently many companies like the ability
to create documentation on a wiki, and then dumping it to a PDF for
shipping.
/Janne
---
r.
Jeremias Maerki
On 15.11.2007 08:41:19 Janne Jalkanen wrote:
How? Just curious.
We don't have built-in PDF generation from pages, which is one of the
more requested features. Apparently many companies like the ability
to create documentation on a wiki, and then dumping it
Hiya!
One of my contributors is asking if either the CLA or the Software
Grant are available in other languages than English (French, Dutch or
German preferred).
Couldn't find anything directly off the Apache website... Any knowledge?
/Janne
---
You might find interpretations or explanations in other languages,
but those would of course not be legally binding. Who would be
willing to expose him- or herself to the legal liability resulting
from a translation error?
I suppose anybody whose English is not strong enough - after all, you
Who would be willing to publish a translation claiming
that it is authoritative, and thereby expose him- or
herself to legal liability towards people that rely
on this translation instead of the original?
Ah, gotcha. Yup, you're right.
Maybe one could collect some donations and then
hire a la
very much agreed and I guess if one can show a migration path (as I
have suggested) which doesn't break too much, then I think nobody
should mind renaming the packages.
But with the ASF member hat on I think the package org.apache.*
is something which the ASF should protect, just as the l
No, there was no vote and is not vote, nor is there any choice.
Subversion is one of the few things that the Board has mandated,
imposed on all projects. Period. Pretty much end of discussion.
I would assume though that if there is enough interest among the
community, the subject of supp
Hi!
During the relicensing efforts of JSPWiki, some people returned
Software Grants, some ICLAs. ICLAs I can find at http://
people.apache.org/~jim/committers.html, but how do I check that ASF
has received the SGAs? How about corporate CCLAs?
/Janne
-
Hm. JSPWiki is missing from the list - but I don't see it anywhere
else either. According to my calculations, our last report was three
months ago, so this is our month also, yes?
/Janne
On 13 Apr 2008, at 00:14, Noel J. Bergman wrote:
Reminder: last chance before we send in the Board r
I also have not received an answer to my question about SVN. When
existing projects are moved into Apache, is their full VCS history
normally imported, or just the latest version. If the former, I will
need to talk to an SVN expert because Thrift's SVN history is a bit
complicated.
We discusse
This seems logical provided the java package names also contain the
incubator keyword to avoid classpath conflicts if the jar gets
included twice.
Which would, obviously, kill backwards compatibility for third party
extensions when moving out of incubation.
Is not nice if you've built you
As an end user, I would _hate_ to have to change all of my code to
reference a totally new package structure after the podling graduates.
That's a major pain...
With JSPWiki we have plenty of plugins and other extensions donated
by people over the years. Every binary break means that we obso
The package names have to change when a podling comes into the
incubator (to the org.apache namespace). So, the "blow" has to happen
anyway. I'm not suggesting we enforce this for existing podlings
necessarily, but future ones should probably do it. Once the podling
graduates, the plugins would
In fact, JAAS was _the_ primary driving factor in what eventually
became JSecurity: I had to execute a number of security operations
for an application, and the only thing out there was JAAS. I found
myself drowning in their mish-mash of incomprehensible APIs and
obscure VM-level security constr
It sounds as if waiting at the last possible second to move from
org.jsecurity.* to org.apache.jsecurity.* is the best option for us.
That way we can move over to the Apache SVN as soon as possible, but
impact the existing community only when absolutely necessary.
This is what we decided with JS
+1
I think this is good, as it codifies an existing practice.
/Janne
On 3 Jul 2008, at 20:42, Craig L Russell wrote:
Hi,
Many projects that come to Apache already have existing releases.
Some are still beta but others have already shipped a few
production versions.
This raises the iss
So, to make this a little more clear, when Wicket performed a few
non-ASF
releases on their old project site was their old Subversion
repository
shutdown and the ASF Subversion repository exclusively used?
Yes. We are volunteers. Having to maintain 2 repositories would have
been prohibitive.
Just in case nobody mentioned this to you yet: "Olio" is the Finnish
word for "object" as in "object relational database" or "object-
oriented programming". You may or may not find this suitable. :-)
Unfortunately, it also means that there are quite a few Finnish IT
companies with the wo
So you assume that that www.apache.org can not be hacked? What if a
signing key *IS* in KEYS but not signed by anyone (because the
developer
has never attended an Apache key signing event)?
Which reminds me - if one does not attend an Apache key signing event
(which tend to be in faraway co
> So the first thing that happens post graduation is that you piss off the
> entire community by breaking all backwords compatibility by changing all
> the package names? Ick. Not a good "first experience" once out of the
> incubator.
We (JSPWiki) will do this by taking advantage of the pack
Hi ho folks!
We were preparing for a massive rename from our old jspwiki name
space to the "org.apache.jspwiki.*" -package to prepare for our first
Apache release when we hit a major snag.
Turns out that Jasper JSP compiler has a bug in it, and it thinks all
classes with their FQN startin
Where are the reports for BlueSky, Cassandra, Imperius, JSPWiki,
Stonehenge,
Lucene.net, Sanselan, Tashi, Thrift, and VCL? This is unacceptable
to have
so many projects disregarding the need to report.
JSPWiki has been added.
Sorry guys, the report has been ready for a few days in the
* you'll need to relicense from LGPL to ASL 2.0, can you have a
written
agreement from all the copyright holders (probably all past
committers)?
At least for JSPWiki this was a fairly big job. You might want to
look at http://www.jspwiki.org/wiki/ApacheRelicensing for the kind of
trackin
> My pet hypothesis (or maybe I'm just looking for excuses) is
> this: UIMA is heavily used in academia. Now academics have no
> problems with open source, to the contrary. But they have an
> overwhelming need to publish and build up a reputation. So
> they like to publish their source code on t
I don't mind championing you but as mentioned by others, there will be
several hurdles to overcome. To change the license, you will have to
get an
agreement from everybody who ever contributed a patch to the source
you plan
to incubate, even for a minor bug fix. I don't know how painful that
> Jaffre does not need skeletons/stubs. The endpoints are pojos, parameters
> and return values are java.io.Serializable objects.
>
> No registry is required.
>
> Jaffre Connectors listen well-defined ports that can easily be bound to a
> specific address. They are firewall friendly.
>
> An exp
Heya!
Voting a new PPMC member guide at http://incubator.apache.org/guides/ppmc.html#Voting+in+a+new+PPMC+member
says that new PPMC members should be added to https://svn.apache.org/repos/private/committers/board/incubator-info.txt
. However, neither I nor the project mentors seem to be able t
I don't remember adding PPMC members to such a file in the podlings
that I've been mentoring - my guess would be that we just stopped
maintaining that file.
Can anyone confirm?
AFAICT we udpdate the poddling status page with the PPMC members.
Should I file a JIRA issue to get it fixed from
46 matches
Mail list logo
