David Le Strat wrote:
Ate,
I am trying to test your branch. I decided to build
with the unit test. So I start my DB - maven
j2:start.test.server after running maven
initMavenPlugin and get:
BUILD FAILED
File...... C:\Program Files\Apache Software
Foundation\Maven
1.0\cache\maven-jetspeed2-plugin-2.0-M4-SNAPSHOT\plugin.jelly
Element... fail
Line...... 570
Column.... 42
Required property org.apache.jetspeed.server.home
undefined. See
http://portals.apache.org/jetspeed-2/getting-started.html
Total time: 25 seconds
Finished at: Thu Aug 04 20:59:19 EDT 2005
Now, this used to be in build.properties. Am i
missing something here?
Sorry David, I'm not exactly sure what the problem is.
The check for org.apache.server.home isn't new.
So yes, you should have it defined in *your* build.properties.
As that is under your own control, you should add it (and already have it?)
yourself.
Regards,
David Le Strat.
--- Ate Douma <[EMAIL PROTECTED]> wrote:
A first comment I'd forgot to add to the info
provided below:
The JS2-319 branch was created a few days ago and
does not yet contain the recent changes
for JS2-281, JS2-231 or JS2-233, but contains the
fix for JS2-232 as I detected that problem
while working on this branch.
Furthermore, I've tested out the fix for JS2-233 on
this branch and confirmed it works.
Regards,
Ate
Ate Douma wrote:
All,
Below is a copy of the comment I posted on
http://issues.apache.org/jira/browse/JS2-319 which
I send to
the jetspeed mailing lists because its much easier
to comment to.
-----------------------------------------------------------------------------------------------------------
Although its already (too) late today, I just
realized I probably won't
have time for a proper description
of this until later tomorrow or even not until
this weekend ...
So, here comes a short summary of my changes as
well as first some
instructions how one can already test out
the new plugin and the genapp goal (note: I'm
gonna send a copy of this
comment to the mailing lists):
a) Checkout the JS2-319 branch from:
http://svn.apache.org/repos/asf/portals/jetspeed-2/branches/JS2-319
b) Run:
- maven initMavenPlugin
- maven allClean allBuild
c) Define the following properties in you
$USER_HOME/build.properties
(forget/remove the old ones):
org.apache.jetspeed.portal.home=<target folder for
the new custom portal
project>
org.apache.jetspeed.portal.groupId=<custom portal
maven groupId>
org.apache.jetspeed.portal.artifactId=<custom
portal maven artifactId>
org.apache.jetspeed.portal.name=<friendly maven
name for you custom portal>
org.apache.jetspeed.portal.currentVersion=<version
of your custom portal>
Note the change from
org.apache.jetspeed.portal.name (trunk) to
org.apache.jetpseed.portal.artifactId (JS2-319)!
For the default jetspeed build, these properties
are set in
jetspeed.properties as follows:
org.apache.jetspeed.portal.home=${org.apache.jetspeed.project.home}
org.apache.jetspeed.portal.groupId=jetspeed2
org.apache.jetspeed.portal.artifactId=jetspeed
org.apache.jetspeed.portal.name=Jetspeed 2
Enterprise Portal
org.apache.jetspeed.portal.currentVersion=${jetspeed.version}
d) Run:
- maven j2:portal.genapp
- cd ${org.apache.jetspeed.portal.home}
- maven war:install
- maven j2:quickStart
e) Done.
You now will have a custom portal installed in
Tomcat (note, you still
need to set the required properties for that as
before).
Where the plugin installs/configures your custom
portal is defined by
the following plugin.properties
which you can override in your build.properties if
you want:
# where the filtered tomcat/context.xml is
stored
org.apache.jetspeed.portal.conf.dir=target/portal-conf
# where the generated and static sql scripts are
stored
org.apache.jetspeed.portal.sql.dir=target/portal-sql
# where the hsql test.script and/or
production.script db is created
org.apache.jetspeed.portal.db.dir=target/portal-db
# target for the (static) portal webapp
org.apache.jetspeed.portal.webapp.dir=target/${org.apache.jetspeed.portal.artifactId}
# target for the filtered ojb config and
jetspeed.properties
org.apache.jetspeed.portal.target.dir=target/${org.apache.jetspeed.portal.artifactId}
This default configuration results in a generated
portal build
configuration similar to what the original
j2:genapp.portal.runtime goal
did.
If you want the effect or the original
j2:genapp.portal goal you should
change the following:
org.apache.jetspeed.portal.webapp.dir=${basedir}/src/webapp
The new j2:portal.genapp thus handles both the old
j2:genapp.portal and
j2:genapp.portal.runtime goals with just a
property change!
The one thing I planned but haven't done is
storing the maven-plugin
data (scripts, webapp src etc.) in a
separate resource jar.
Although I thought about it, it currently isn't
providing much benefit I
think, so I skip that for now.
A remark about the move of the
/portal-webapp/src/webapp to /src/webapp.
I did this because that way the we can (and are
forced) to eat our own
dogfood:
building the default jetspeed portal that way uses
the same maven
project structure
as a generated custom portal setup. The plugin
actually is used for the
default build too.
Another important change I made to the portal
(maven) project structure:
the j2:portal.genapp goal (or better: the invoked
j2:portal.maven goal)
will *not* override
an existing project-info.xml or project.xml, only
an initial one will be
created.
As these two project files don't contain anything
needed for the portal
build itself, a custom portal
setup can easily be extended (with additional
project info, dependencies
and/or resource configurations
for example) by modifying these files, and you
still can upgrade to a
newer version of jetspeed by simply
executing j2:portal.genapp (or any of its sub
goals).
You own custom portal configuration can thus be
preserved and checked in.
For the same reason, no custom
project/build.properties is generated
allowing you to provide your own.
The sql scripts are now (pre) generated in a
configurable location and
only generated for the db you
have specified.
If org.apache.jetspeed.use.test.database = true
(default false, but true
in jetspeed.properties),
and a different test db is specified, two sets of
sql scripts will be
generated.
All previous drop table handling goals are removed
(and no longer
needed) as now one (hardcoded) drop.sql
scripts is executed (with continue on errors)
before the schema scripts
are executed.
=== message truncated ===
________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
