[Aplaws-devel] [aplaws - Developing on APLAWS+] RE: trunk back in a working condition

[Aplaws D. L. <apl...@li...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=7402532
By: pboy

Some remarks about the current state and the problems which came up yesterday.

a)
The URL resource: protocol extension is still in use. 

I had the same idea as Brett how to eliminate it (using ResourceProtocol), but
overlooked the unsuficient implementation of AbstractParameter providing the
default value which resulted in a casting error. Thanks to Brett's patch the
problem is resolved now.

I'll provide a patch over the weekend which replaces the URL resource extension
in all trunk modules. In the meantime the solution suggested
in ~/tools-ng/ecdc/README.txt should be used (copying the ccm-core-system-x.y.z.jar
into $JAVA_HOME/jre/lib/ext).

Many thanks to Brett for providing the patch!

b)
Validation error regarding project.xml

There was an entry in the example file project.xml.complete which ponited to
a wrong location. (~/tools/devel/... instead of ~/tools-ng/common/xsd/...).
It is corrected thanks to Terry.

Developers who have their own project.xml in place have to adjust it:
In ccm:project
- modify the scheme file location: tag xsi:schemaLocation= ...
- add webapp=ROOT
- optional: add prettyName
- optional: provide version and release (osed in war file generation)

c)
Load-bundle information

ECDC is meant to require minimal steps in the development cycle to be entered
over and over again. Therefore all information required in the load-bundle step
is taken from a bundle file. In contrast to the well known "ccm load-bundle"
command there is no interactive mechanism to enter required information for
database connection and administrator name and password.

The example local.ccm.properties points to ~/ccm-ldn-aplaws/bundles/devel where
all those informations are included in .../cfg/integration.properties (at the
end of the file).

It is best practice to create one's one bundle file, e.g. myAuth, and maintain
a devel version, which includes those information, e.g. myAuth-devel, and a
production version, which duplicates all the files of the devel version leaving
off the database connection and administration information for security reasons,
e.g. myAuth-prod.

The latter is useless at the moment because we don't have a user installation
procedure yet, but will be used when we have one (see milestone (3) on fedorahosted
trac).


Hope this helps.

Peter





______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=368401