[ http://issues.apache.org/jira/browse/JS2-319?page=comments#action_12317695 ]
Ate Douma commented on JS2-319: ------------------------------- 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. Ant filters are now applied upon the j2:portal.genapp goal (and its sub goals), not when the plugin is created (with initMavenPlugin). This means you can change your build.properties settings and simply call the j2:portal.genapp or one of its subgoals to update your configuration. You don't need to run initMavenPlugin again anymore. Finally, I reorganized and renamed several plugin goals. Mostly prefixing them with an "_", indicating these are meant for internal use by the plugin itself. For public usage, a lot less goals need to be documented that way. Too many public goals is too confusing in my mind. I invite everyone to checkout this branch and tryout the new genapp goals. Hopefully, most if not all current build problems and wishes (for now that is) are covered by this. If you agree/disagree on all or part of my changes, please comment to this message on the mailing list. And if you encounter bugs or unexpected and unwanted behavior, please comment at http://issues.apache.org/jira/browse/JS2-319 With enough support, I'd like to merge these changes ASAP to the trunk. Regards, Ate > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
