David Le Strat wrote:
Ate,
Big +1, all those proposed changes look great!
Thanks
Regarding the SQL scripts, are you planning to make
them part of your portal-resources.jar?
No, except for the hardcoded seeding scripts we supply.
I intend to generate the SQL scripts for the selected db to the specified
portal (maven) target folder with the genapp goal.
Regards,
David Le Strat.
--- Ate Douma <[EMAIL PROTECTED]> wrote:
David Le Strat wrote:
Glad to see this is working. You had me worried
for a
second.
I know, sorry. I was worried myself :-)
I agree with your point on the maven-plugin. I
noticed
recently that the initMavenPlugin does not always
clean the plugin properly if the test db is
running.
The initMavenPlugin goal therefore needs to be run
stand alone. What changes do you propose to make?
Well, I'll create an issue for it later this
evening.
But this is a list of what I have in mind:
- Create a separate portal-template resource jar and
install it in the repo
as I originally suggested.
This should remove the need to have these stored
within the plugin.
I'd like to see the plugin as generic as
possible:
only functionality, no data (at least, as less as
possible)
Running initMavenPlugin should only be needed
again when something
in plugin.jelly changes.
- delay property filtering in the templates to
plugin goal
execution time.
Now, once you run initMavenPlugin you're stuck
with (most of) the settings you
had at that time. Caused me lots of hair pulling
problems until I understood
what was going on.
- extend/fix different portal name/context handling.
Right now, "jetspeed" is still embedded in
several places causes runtime
problems when you try to use a different portal
name.
I'd like to make "jetspeed" a variable value all
the way, even when used from
the normal (read: non-genapp) context.
- Provide "true" overlay functionality when building
your own portal.
I want to be able to maintain my own portal
configuration and load/run portal.install
to merge the content of the selected
jetspeed-portal-template with my own.
- output schema generation and run Hsqldb (and
hopefully replaced with Derby soon)
in the portal target folder (by default), not
within the plugin context
(see above)
And because of the current problems, I'll try to
start on these changes ASAP.
I really need genapp to work as expected so I can
drop my own custom solution.
Hopefully, I can have most of it ready by Monday.
Any thing you'd like to see different/added/removed
?
Regards,
Ate
Regards,
David Le Strat.
--- Ate Douma <[EMAIL PROTECTED]> wrote:
Ate Douma wrote:
David Le Strat wrote:
Ate,
I just cleaned up everything on my box (cache,
repository, targets and so forth) and reran the
entire
build with tests enabled. All passed, I also
deployed
the application and everything looks good. I
cannot
reproduce the problem you just described :(
Thanks for testing David.
Don't know what goes wrong here.
Maybe my current source is out of order?
With the problems of minotaur (and thus SVN) all
of yesterday I'll
belief anything right now.
I'll go the same route (cleaning out my whole box
now) and see what goes.
Will report back when I'm done.
I've cleaned out repo/plugins, cache and
repository/jetspeed2.
And checked out J2 fresh.
run:
maven initMavenPlugin
maven j2:start.test.server
maven -Dmaven.test.skip=false allBuild (in a
separate console of course)
All tests pass...
So, sorry for sending out the alarm, my setup must
have been hosed somehow yesterday.
A full compare between my newest J2 checkout and
the
previous one (which I had archived first)
showed 0 (zero) changes...
The only thing I now can think of is the
maven-plugin.
But yesterday I did run maven initMavenPlugin
first
before I encountered the reported testcase errors.
All the more reason I think to tackle some (and
now
this) maven-plugin problems as I send a message
about late yesterday evening.
For one, running Hsqldb (by default) from *within*
the installed maven-plugin is troublesome.
The above executed steps *do fail* in the end
because the newly build maven-plugin can't be
installed again
as Hsqldb is keeping a lock on its database file.
Although this only happens when running the test
server and should normally only be a problem for
us developers I'd like to resolve it anyway.
David, again, sorry for the trouble you had to go
through checking this false alarm,
and thanks for the effort.
Regards,
David Le Strat.
--- Ate Douma <[EMAIL PROTECTED]> wrote:
David Le Strat wrote:
This is weird, I have be rerunning the entire
test
suite and the tests pass.
Are you redoing a full build including
reinitializing
your plugin prior to starting (maven
initMavenPlugin)?
Yes
Regards,
David Le Strat.
--- Ate Douma <[EMAIL PROTECTED]> wrote:
=== message truncated ===
________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
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]
