You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Murray Altheim <mu...@altheim.com> on 2018/11/11 19:58:01 UTC
Some dev questions getting started again...
Hi,
I'm just starting again, rebuilding my dev environment for JSPWiki. I'm
running Eclipse JEE version 2018-09 with Java 8 (Oracle 1.8.0_172).
I imported the entire 'develop' tree off of the GIT repository, and found
23 compile errors (actually 4 unique), namely:
att cannot be resolved in AttachmentTab.jsp
BASE_URL cannot be resolved or is not a field in Install.jsp
searchref cannot be resolved in AJAXSearch.jsp
web.xml is missing and <failOnMissingWebXml> is set to true
in pom.xml
My questions are:
1. should I be developing (adding plugins, etc.) in the 'develop' branch,
or somewhere else? I didn't see a 2.10.x branch. I'm assuming we don't
work against 'master' (?). Or should I begin working in a new branch?
2. are the above errors actually in the branch or are they a product of
some error in my configuration? I'm kinda assuming the latter since
I'm guessing we don't normally leave the build broken...
I've set up JDK 1.6 as I see the parent POM uses 1.6 but this didn't
have any effect on the above-described compile errors.
3. There's a dev note that states all work should be done against a JIRA
issue. Is this true of greenfield (new plugin) work as well? I.e.,
should I/we be creating a JIRA item for this work?
4. Where can I find any road map info on migration to more current
versions of Java 8, as well as various libraries?
While my plugins aren't (to my memory) version-dependent, I'm working
on several providers, where many of the classes require Java 7's
"try-with-resources" feature and several requires Java 8, e.g., the
ability to refer to interface static methods (this is a requirement
of one of my core dependencies, not my owh code), so this would be my
highest priority (rather than re-write those classes for an EOL'd Java
or abandon the dependency, which would cripple the project).
5. Any other advice on getting set up properly so I don't bork the
build accidentally.
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: Some dev questions getting started again...
Posted by Murray Altheim <mu...@altheim.com>.
[My apologies, I wasn't meaning to burden the group with that message;
nothing in it is a secret. Just a mistake due to trying to post during
my lunch hour while using a rather sorry excuse for a webmail.]
If I can find the time I'll post a better description of the provider
project. For now I'm simply trying to get myself up and running to
post the wiki plugins described a bit earlier.
Cheers,
Murray
> [offline]
>
> Hi Juan Pablo,
>
> Thanks for the info, that's very helpful. I've updated my Eclipse from
> the master but still get one error, a generics mismatch on rss.jsp. But
> for whatever reason that's there it won't stop me from continuing.
>
> It does sound like I should work from a branch though, not necessarily
> for the plugins, but for the providers, as there might be some contention
> there. How does one go about creating a branch, and what might be an
> appropriate name?
>
> To give you an idea of what I'm working on, it's a set of three providers,
> based on a text-based format for wiki pages called a "Ned" (as my parent
> project is called 'ne' and it's referred to as a "ne node"), A Ned is a
> text format, using a model influenced by the original Macintosh file
> format,
> which divided the file content into a "resource fork" (file metadata) and
> a
> "data fork" (file content). This uses an untypeable delimiter character to
> separate the forks.
>
> I've currently got four providers, three of which are finished:
>
> 1. an in-memory provider for testing only
> 2. a Berkeley DB JE based provider
> 3. a Neo4j Embedded graph database provider
> 4. a Neo4j OGM graph database provider (unfinished)
>
> It wouldn't be too difficult to develop a file-based provider since there
> are already Ned serialiser and deserialiser methods in the code.
>
> The Neo4j providers have a 32K data limitation on any single property,
> (due to a current limitation in Neo4j) so wiki pages over 32K get
> segmented
> and re-built when pulled from the repository.
>
> Full-text and field-based search is currently via Lucene using a separate,
> non-JSPWiki API, not sure what to do about that.
>
> I haven't advertised this project to the group yet because I'm not sure
> I'll
> have enough time to actually convert it over to JSPWiki and get it up and
> running on my own. I can probably publish some of the plugins but the
> providers are a significantly larger venture. While the benefits of a
> graph
> database backend for a wiki may be apparent to some, the Berkeley DB
> version
> is probably enough of a win to promote the basic Ned project, even without
> the Neo4j providers. It's exceedingly fast and is a very stable DB.
>
> This all comes out of a project called 'ne', a CLI-based application I've
> written to capture and store text-based notes. Basically, the idea is that
> one could write notes that are easily turned directly into wiki pages,
> without needing to use a wiki. Ne also has a directory watcher that can
> auto-ingest anything dropped into it. It's got more features than that,
> suffice it to say that the Neo4j providers are coming out of ne's storage
> backend, which is an embedded Neo4j.
>
> Ne's metadata model is configurable via a JSON file. Ne uses a more
> complicated model than JSPWiki but they're by design compatible.
>
> As you may imagine, the enemy in all this is, as always, time available.
>
> ...enough for now.
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: Some dev questions getting started again...
Posted by Murray Altheim <mu...@altheim.com>.
[offline]
Hi Juan Pablo,
Thanks for the info, that's very helpful. I've updated my Eclipse from
the master but still get one error, a generics mismatch on rss.jsp. But
for whatever reason that's there it won't stop me from continuing.
It does sound like I should work from a branch though, not necessarily
for the plugins, but for the providers, as there might be some contention
there. How does one go about creating a branch, and what might be an
appropriate name?
To give you an idea of what I'm working on, it's a set of three providers,
based on a text-based format for wiki pages called a "Ned" (as my parent
project is called 'ne' and it's referred to as a "ne node"), A Ned is a
text format, using a model influenced by the original Macintosh file format,
which divided the file content into a "resource fork" (file metadata) and a
"data fork" (file content). This uses an untypeable delimiter character to
separate the forks.
I've currently got four providers, three of which are finished:
1. an in-memory provider for testing only
2. a Berkeley DB JE based provider
3. a Neo4j Embedded graph database provider
4. a Neo4j OGM graph database provider (unfinished)
It wouldn't be too difficult to develop a file-based provider since there
are already Ned serialiser and deserialiser methods in the code.
The Neo4j providers have a 32K data limitation on any single property,
(due to a current limitation in Neo4j) so wiki pages over 32K get segmented
and re-built when pulled from the repository.
Full-text and field-based search is currently via Lucene using a separate,
non-JSPWiki API, not sure what to do about that.
I haven't advertised this project to the group yet because I'm not sure I'll
have enough time to actually convert it over to JSPWiki and get it up and
running on my own. I can probably publish some of the plugins but the
providers are a significantly larger venture. While the benefits of a graph
database backend for a wiki may be apparent to some, the Berkeley DB version
is probably enough of a win to promote the basic Ned project, even without
the Neo4j providers. It's exceedingly fast and is a very stable DB.
This all comes out of a project called 'ne', a CLI-based application I've
written to capture and store text-based notes. Basically, the idea is that
one could write notes that are easily turned directly into wiki pages,
without needing to use a wiki. Ne also has a directory watcher that can
auto-ingest anything dropped into it. It's got more features than that,
suffice it to say that the Neo4j providers are coming out of ne's storage
backend, which is an embedded Neo4j.
Ne's metadata model is configurable via a JSON file. Ne uses a more
complicated model than JSPWiki but they're by design compatible.
As you may imagine, the enemy in all this is, as always, time available.
...enough for now.
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
Re: Some dev questions getting started again...
Posted by Juan Pablo Santos RodrÃguez <ju...@gmail.com>.
Hi Murray,
currently we don't have any "official" way of working with branches other
than master should be releasable at any given
moment. Note that this doesn't mean feature-complete, but releasable.
Given that the pace of development is slow, most of the time the commits go
directly to master, using other branches
for changes that affect most of the codebase, to discuss them (and IIRC
there've only been a couple so far..) Development
is quite behind master, I'd say it haven't been used on a long time. It is
much safer to start, or branch, from master, which
btw currently uses JDK8.
Also, almost a year (?) ago we began to follow a release train model,
meaning we should be able to release master every
three months. Speaking of that, november is a release month so more sooner
than later we should begin a [VOTE] for the
new version.
As for versions, we're in the middle of switching to 2.11, meaning breaking
changes from 2.10 would be allowed. But, instead of
releasing 2.11.0, we're going with release 2.11.0.M1, 2.11.0.M2, etc (don't
know how may milestones). The idea there is that
M# releases would allow us to keep breaking compatibility with 2.10 within
several releases, but other than that should be
as ready for production as normal releases. Currently, the following
breaking changes from 2.10 have happened:
* switching to java 8 / maven 3.5
* switching to servlet 3.1 / jsp 2.3 (i.e. tomcat 8.5+)
* haddock as default template (renaming 2.10 default template to "210")
* begin to move to a multi-module build (right now, the css, js, jsp stuff
is on the war module, with all the java files on there on
their own -main- module, but I expect to begin to break it in smaller
modules somewhere soon)
* a handful of backwards incompatible changes regarding classes moved from
package, method with different signatures, etc.
As for the build, there's a Jenkins build on ASF infrastructure at [#1],
which should be always green/blue. This build also
triggers a Sonar analysis, reachable at [#2], which right now is only
informative.
Finally, as for the JIRA issues, I'm not the best one to say, because I
still have it pending to do with latest commits on master,
but it'd help a lot: people go there to see what is contained on each
release, helps to see on what you're working, etc.
don't know if I'm leaving something, but HTH
juan pablo
[#1] https://builds.apache.org/blue/organizations/jenkins/jspwiki/activity
[#2]
https://builds.apache.org/analysis/overview?id=org.apache.jspwiki%3Ajspwiki-builder
On Sun, Nov 11, 2018 at 8:58 PM Murray Altheim <mu...@altheim.com> wrote:
> Hi,
>
> I'm just starting again, rebuilding my dev environment for JSPWiki. I'm
> running Eclipse JEE version 2018-09 with Java 8 (Oracle 1.8.0_172).
> I imported the entire 'develop' tree off of the GIT repository, and found
> 23 compile errors (actually 4 unique), namely:
>
> att cannot be resolved in AttachmentTab.jsp
> BASE_URL cannot be resolved or is not a field in Install.jsp
> searchref cannot be resolved in AJAXSearch.jsp
> web.xml is missing and <failOnMissingWebXml> is set to true
> in pom.xml
>
> My questions are:
>
> 1. should I be developing (adding plugins, etc.) in the 'develop' branch,
> or somewhere else? I didn't see a 2.10.x branch. I'm assuming we don't
> work against 'master' (?). Or should I begin working in a new branch?
>
> 2. are the above errors actually in the branch or are they a product of
> some error in my configuration? I'm kinda assuming the latter since
> I'm guessing we don't normally leave the build broken...
>
> I've set up JDK 1.6 as I see the parent POM uses 1.6 but this didn't
> have any effect on the above-described compile errors.
>
>
> 3. There's a dev note that states all work should be done against a JIRA
> issue. Is this true of greenfield (new plugin) work as well? I.e.,
> should I/we be creating a JIRA item for this work?
>
> 4. Where can I find any road map info on migration to more current
> versions of Java 8, as well as various libraries?
>
> While my plugins aren't (to my memory) version-dependent, I'm working
> on several providers, where many of the classes require Java 7's
> "try-with-resources" feature and several requires Java 8, e.g., the
> ability to refer to interface static methods (this is a requirement
> of one of my core dependencies, not my owh code), so this would be my
> highest priority (rather than re-write those classes for an EOL'd Java
> or abandon the dependency, which would cripple the project).
>
> 5. Any other advice on getting set up properly so I don't bork the
> build accidentally.
>
> Cheers,
>
> Murray
>
> ...........................................................................
> Murray Altheim <murray18 at altheim dot com> = = ===
> http://www.altheim.com/murray/ ===
> ===
> = = ===
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut.
> -- Minamoto no Tsunenobu
>
>
>
>