jandockx / ppwcode-recovered-from-google-code Goto Github PK

When a number of business projects are delivered using the new ppwcode 
vernaculars, decide 
whether or not this project makes any sense anymore. This JSP project might 
contain still some 
things that need to be kept, like error pages, ... If not, or if the code is 
used in other libraries, this 
should be deleted at a given time.

Create the Java part of the website

Cleanup of ppwcode metainfo. First of all, we need to change the license 
headers. Add svn-
annotation code (which is now, amongst others, en Beedraz).

release first version asap

This project is pretty important, and needs to be reactivated and cleaned asap. 
This is not a utility 
libary, and not a vernacular. It should become a project at the top level.

For building and testing of our libraries, we have dependencies on a number of 
external libaries, 
some of which are not in the global maven repositories, for different reasons 
(mainly license 
issues).
For inhouse projects, we normally set up a "missing artifacts" repository, so 
that we only need to 
find and install those libs once for the entire team.

We cannot do this for these public projects. Such a setup requires a settings 
in the maven pom, 
and obviously we cannot make the missing artifacts repo publicly available (for 
license reasons). 
Once the reference to a missing artifacts repo is in the pom however, things 
will stop working of 
that repo is not public.

Users need to do an mvn install of the lib in question in their local repo 
cache by hand. This 
obviously is an escape for our developers too, but to sad.

Is there any solution for our team?

Reactivate plugin settings and standards for code reports on this level.
Clirr? Check sensibility and configure if kept.

add collection code from Toryt

When a number of business projects are delivered using the new ppwcode 
vernaculars, decide 
whether or not this project makes any sense anymore. These things where created 
a number of 
years ago, when JSF was less stable, there was no Seam, and Spring was in its 
infancy. Chances are 
that, with those larger projects available, this code is no longer needed.

Reactivate plugin settings and standards for code reports on this level. 
Configure JavaNCSS: 
evaluate, kill if not sensible.

Reactivate plugin settings and standards for code reports on this level.
CPD settings. Check them.

Describe version numbering scheme + rationale.

From our first weeks in this setup, it becomes clear that a separate snapshot 
library becomes 
sensible. We already decided more or less that "dev" trees in svn will be 
deleted once a stable 
version is deleted. Why then would we keep the snapshot artifacts in the repo? 
Deleting the 
snapshots from the repo is a bit of work. By keeping them in a separate 
snapshot directory, we can 
just delete a subdirectory on the server, and be done with it.

The same applies to the project dev sites.

Cleanup of ppw-code exception. Work will be done in the dev_II branch. First of 
all, we need to 
change the license headers. Further, we need to change the annotations to svn. 
For this, we first 
need to pull the meta-info project from the purgatory, and clean that, and add 
svn-annotation 
code (which is now, amongst others, en Beedraz).

This old project will largely be incorporated in the semantics vernacular and 
an i18n util project or 
the smallfries util project. Once this is done, this part of the purgatory 
should be deleted.

write package documentation and overview

Make license headers ok.

Get waivers from all members, and client companies we work with from now on, 
for ppwcode, and 
for Apache (see http://www.apache.org/licenses/#clas).

Reactivate plugin settings and standards for code reports on this level.
Configure FindBugs (this is a re-evaluation; we decided some years ago not to 
use it since it is 
really over-eager, and Checkstyle + PMD was much better)

explanation of maven2 and pom subprojects in Java part. separate subpages?

release first version

Put existing versions of Java libraries in google code downloads. Copy from 
cvs.peopleware.be 
maven repo.

Decide on version numbering scheme for implementation version (III-n.m.p-N.M). 
It is probably 
better and more simple to do this using a timestamp or the revision number. 
That seems ok, but it 
needs to be implemented in the maven parents.

Reactivate plugin settings and standards for code reports on this level.
Evaluate configuration of StatSCM. This plugin must stay, but might replace 
other plugins, and 
maybe needs a bit of re-configuration.

Reactivate plugin settings and standards for code reports on this level.
PMD: use existing standard, add for java 1.5, activate

Dependency graph of subprojects on Java part of site.

project needs a lot more unit tests

ppwcode grows from the PeopleWare JavaLibraries project. We have a applications 
in the field that 
use the original libraries in a certain version. It is not the intention that 
the libraries are further 
maintained in the original private vcs, but even this week we encountered a 
situation that we did 
need to do a checkout of old code.

What are we going to do with this? Use the old private vcs for that? Or put all 
those things in 
ppwcode, in some subdirectory? In that case, we probably need to do a sizeable 
amount of work, to 
put all the licenses in order, work which we are now doing while refactoring 
the code ...

Set up back up of svn repo.

For Maven 2 builds to be reliable in the future, it is necessary to fix the 
versions of the plugins 
used. This can be done in the root pom once and for all. This is done in the 
pluginManagement tag.

Create util part of Java part of website.
Explanation, list of projects.

Chances are slim that we will do another Struts 1 project. What to do with this 
library?

list todo's

mavenize the project

I would really like a visual representation of the dependency graph in the 
project reports. I believe I 
remember some things on the maven2 mailing lists that say that such a thing 
might exist now.

This project contains a number of classes that are relevant for web 
applications in general. 
Consider reactivating them, possibly in the context of the new exception 
vernacular. If not, or if the 
code is used in other libraries, this should be deleted at a given time.

Verify licenses, notices, etc... for release. Use apache projects as example.

make copied code compile

organize the source in a good new structure using svn move.

Reactivate plugin settings and standards for code reports on this level.
Checkstyle: use existing standard, add for java 1.5, activate

Define mailing lists.

Mavenize

purgatory settings mainly contains old settings files. Once the tasks for 
cleaning the maven2 parent 
poms with respect to the project report settings are done, this should be 
removed. 

On the other hand, this week we had to do some work on the old project, and we 
needed the old 
version of this repo. ... ?

Upload source code from PeopleWare CVS.

Build ppwcode.org website. Include existing maven project sites for existing 
versions of libraries. 
(Move from cvs.peopleware.be/projects/JavaLibraries/).

forReintegration mainly contains old settings files. Once the tasks for 
cleaning the maven2 parent 
poms with respect to the project report settings are done, this should be 
removed.

Create vernacular part of the website. What is this, what are the projects, ...

Reactivate plugin settings and standards for code reports on this level.
Configure JDepend: use existing standard, add for java 1.5, activate

Verify licenses, notices, etc... for release. Use apache projects as example.

Contracts with toryt annotations