You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2005/08/12 17:32:54 UTC
[jira] Closed: (JS2-319) Maven-plugin still too much dependent on hardcoded project configuration
[ http://issues.apache.org/jira/browse/JS2-319?page=all ]
Ate Douma closed JS2-319:
-------------------------
Resolution: Fixed
> 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
RE: [jira] Closed: (JS2-319) Maven-plugin still too much dependent on hardcoded project configuration
Posted by Scott T Weaver <sc...@binary-designs.net>.
Ignore the previous email. Running allClean allBuild seemed to create the
missing "portal-conf" directory. I must have accidentally deleted it while
debugging the previous db scripts issues (Doh!!!).
Regards,
-Scott
> -----Original Message-----
> From: Scott T Weaver [mailto:scotts-jetspeed-list@binary-designs.net]
> Sent: Friday, August 12, 2005 11:44 AM
> To: 'Jetspeed Developers List'
> Subject: RE: [jira] Closed: (JS2-319) Maven-plugin still too much
> dependent on hardcoded project configuration
>
> Ate,
>
> I had to manually run the "j2:portal.conf.tomcat" goal or else
> j2:quickStart
> fails. Is this expected behavior or am I missing something simple? I
> don't
> see this requirement documented as being required, though I do see it
> mentioned but not in the standard list of steps. If this is expected I
> would suggest it would be best to move the call into j2:quickStart.
>
> FYI: I am just building standard Jetspeed and not a custom portal.
>
> Regards,
> -Scott
>
> > -----Original Message-----
> > From: Ate Douma (JIRA) [mailto:jetspeed-dev@portals.apache.org]
> > Sent: Friday, August 12, 2005 11:33 AM
> > To: jetspeed-dev@jakarta.apache.org
> > Subject: [jira] Closed: (JS2-319) Maven-plugin still too much dependent
> on
> > hardcoded project configuration
> >
> > [ http://issues.apache.org/jira/browse/JS2-319?page=all ]
> >
> > Ate Douma closed JS2-319:
> > -------------------------
> >
> > Resolution: Fixed
> >
> > > 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: [jira] Closed: (JS2-319) Maven-plugin still too much dependent on hardcoded project configuration
Posted by Scott T Weaver <sc...@binary-designs.net>.
Ate,
I had to manually run the "j2:portal.conf.tomcat" goal or else j2:quickStart
fails. Is this expected behavior or am I missing something simple? I don't
see this requirement documented as being required, though I do see it
mentioned but not in the standard list of steps. If this is expected I
would suggest it would be best to move the call into j2:quickStart.
FYI: I am just building standard Jetspeed and not a custom portal.
Regards,
-Scott
> -----Original Message-----
> From: Ate Douma (JIRA) [mailto:jetspeed-dev@portals.apache.org]
> Sent: Friday, August 12, 2005 11:33 AM
> To: jetspeed-dev@jakarta.apache.org
> Subject: [jira] Closed: (JS2-319) Maven-plugin still too much dependent on
> hardcoded project configuration
>
> [ http://issues.apache.org/jira/browse/JS2-319?page=all ]
>
> Ate Douma closed JS2-319:
> -------------------------
>
> Resolution: Fixed
>
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org