portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Commented: (JS2-319) Maven-plugin still too much dependent on hardcoded project configuration
Date Fri, 12 Aug 2005 15:10:54 GMT
    [ http://issues.apache.org/jira/browse/JS2-319?page=comments#action_12318646 ] 

Scott T Weaver commented on JS2-319:
------------------------------------

Okay, I think I see the issue.  The security-schema.sql in target/portal-sql/mssql/schema
is not the one defined in etc/sql/mssql/schema.  It appears that even with the custom sql
defined, the plugin is using with the torque generated one instead.  The only real differences
between the two scripts is the "ON DELETE CASCADE" that is exists on SSO_PRINCIPAL_TO_REMOTE,
SECURITY_USER_ROLE, SECURITY_USER_GROUP and SECURITY_GROUP_ROLE in the Torque-generate sql.

> Maven-plugin still too much dependent on hardcoded project configuration
> ------------------------------------------------------------------------
>
>          Key: JS2-319
>          URL: http://issues.apache.org/jira/browse/JS2-319
>      Project: Jetspeed 2
>         Type: Bug
>   Components: Deployment, Project Build
>     Versions: 2.0-M4
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>      Fix For: 2.0-M4

>
> I'm gonna try to implement the following corrections and improvements to the maven-plugin:
> - Create a separate portal-template resource jar and install it in the repo.
>   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.
>   Currently, once you run initMavenPlugin you're stuck with (most of) the settings you
had at that time.
> - Extend/fix different portal name/context handling.
>   Right now, "jetspeed" is still embedded in several places causing 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
>   If you run a full test build using Hsqldb (maven j2:start.test.server) the test database
is by default run inside the plugin context/environment.
>   This leads to a failure at the end because the newly build plugin cannot be installed
because Hsqldb has a lock on its database file within the current installed plugin.
>   Also, I want the generated sql (as well as the predefined sql) stored in my target
portal project so I can (optionally modify, extend and) distribute it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message