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 <at...@douma.nu> on 2007/08/24 15:02:42 UTC
Re: [M2 build design] Refactoring
David Sean Taylor wrote:
> I would also like to discuss trimming down the core Jetspeed, removing
> any old stuff, and moving out applications to its own subversion repository
> IMO, the core portal should only be basically:
>
> * jetspeed api
> * components
> * commons
+1
I also agree to your proposed changes below, but like to provide a little (but not much) different solution which might help us to easier manage the different
parts of the jetspeed-2 project without having to expand the Portals project itself (for now).
Instead of moving out several parts to separate svn trunk folders above/besides our current jetspeed-2(/trunk) svn root, I like to propose keeping most (or
everything) under this same root folder for now.
I think we can also achieve our goal by instead create a new root subfolder called "portal".
Under this "portal" folder, we can move the above mentioned folders, and probably some new folders for portal assembly projects (like the installer) etc.
This new portal folder then can become the main checkout root for core portal development.
On the same (root) level as the "portal" project, I'd like to keep the new maven and the jetspeed-portal-resources projects.
I've discovered that having those as sub projects inside the main portal build is kind of tricky with respect of circular dependencies as the artifacts from
these are also used within the build itself. Moving these out of the main build (and allow independent lifecylce management) will make our dependency management
much cleaner and easier.
Our current applications sub project (and in particular j2-admin) can also be moved to the same root level. This will make them also more independent of the
(release) lifecycle of the "core" portal. Not all end-users/integrators use or need these applications.
I do think j2-admin clearly belongs and should be kept under the jetspeed-2 svn root as it is an intrinsically jetspeed-2 specific application.
The other current applications element like the gems, rss and demo (?) are not really tied to jetspeed-2, and I would be in favor of moving those to a new and
more general Apache Portals Applications project (I also like to start developing other portlet applications for Forums, Wiki, Blogs, Mail, etc. and those will
also be better placed under such a new Portals Applications project).
Layout porlets maybe can also be moved under our (jetspeed-2) applications root folder.
And other root folders can be docs and tutorials.
The main benefits of having these separate root folders (applications,portal,maven,jetspeed-portal-resources,docs,tutorials, site):
- separate and independent checkout
- possibility of managing their lifecyle independently (e.g. independent newer/bugfix releases of jetspeed-maven-plugin, j2-admin, portal, docs)
Note though the one thing missing for (easy) independent lifecycle management is our current JIRA project setup.
I think we might want to split/expand our current JIRA project and add new projects for:
- j2-admin (J2ADMIN)
- other applications (layouts?) (J2APPS)
- jetspeed-maven-plugins (J2MAVEN)
- jetspeed-portal-resources (J2RESOURCES)
- site, docs & tutorials (J2DOC)
- ...
So, summarizing, my proposed new directory structure would be:
jetspeed-2/trunk
/applications
/j2-admin
/layout-portlets
/demo (for now)
/gems (for now)
/rss (for now)
/docs
/jetspeed-portal-resources
/maven
/jetspeed-maven-plugins
/portal
/jetspeed-api
/jetspeed-commons
/components
/... (all components)
/assembly
/base-portal
/demo-portal
/jetspeed-installer
/...
/site?
/tutorials
WDYT?
Ate
>
> Proposed changes:
>
> * applications -- move to new svn project called "applications"
> including j2-admin
> * app-servers -- not entirely sure whats here, but I think it should be
> a "configuration" of some sort
> * archives -- remove it
> * design-docs -- this needs review and deletion of old artifacts (man I
> can hear echoes of Kent Beck talking about the code being the only real
> artifact...)
> * docs -- same as above, combine design-docs + docs --> docs
> * etc -- I would think this should be moved into the "configuration"
> layer to be discussed
> * graphic_design -- a few logos..
> * jetspeed-ant-tasks -- i understand this is used for the installer, but
> this is also an area that needs further discussion, should Jetspeed
> provide Ant tasks ... I think the answer may be yes
> * jetspeed-installer - that is written in Maven-1, going to be
> interesting to see if we can port it to Maven-2 (yes I am being skeptical)
> * jetspeed-portal-resources -- this is new, I will let Ate comment on it
> * layout-portlets -- I think layouts need to be refactored but thats
> another discusson
> * maven -- this is new, I will let Ate explain it to us
> * patched-jars -- its empty
> * taglibs -- thats one ugly tree view taglib, i think we should get this
> out of the portal as its not the right place and look into porting
> j2-admin portlets that use it to something more standard like Wicket or
> JDSF
> * tutorial -- move to new svn project called "tutorials"
>
>
>
>
> ---------------------------------------------------------------------
> 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: [M2 build design] Refactoring
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Aug 24, 2007, at 6:02 AM, Ate Douma wrote:
>
<snip/>
>>
>> Note though the one thing missing for (easy) independent lifecycle
>> management is our current JIRA project setup.
>> I think we might want to split/expand our current JIRA project and add
>> new projects for:
>> - j2-admin (J2ADMIN)
>> - other applications (layouts?) (J2APPS)
>> - jetspeed-maven-plugins (J2MAVEN)
>> - jetspeed-portal-resources (J2RESOURCES)
>> - site, docs & tutorials (J2DOC)
>> - ...
>
> Well, maybe. Do you know if other projects also create this many project
> tags per project?
> I don't want to create too many tags if there is no precedent
>
Not really (yet) at Apache JIRA, although something similar is proposed/requested by the Cocoon team too although not executed as of yet.
A big and better "example" probably is the maven-2 plugins svn sub tree at: http://svn.apache.org/viewvc/maven/plugins/trunk/
All of those plugins are versioned independently and have separate JIRA projects... at codehaus ...
It seems strange that they don't use the Apache JIRA, but that probably has an historical reason I guess.
Anyway, I'm not 100% sure we should or need to version those independently, there are some downsides of course.
I like to hear others opinions (experiences?) on this first.
For restructuring our svn tree it doesn't really matter yet.
Only when we start versioning one of those above independently it becomes important as we "tag" releases by copying a svn folder to the /releases folder so we
cannot have "overlapping" tagged folders.
>>
>> So, summarizing, my proposed new directory structure would be:
>>
>> jetspeed-2/trunk
>> /applications
>> /j2-admin
>> /layout-portlets
>> /demo (for now)
>> /gems (for now)
>> /rss (for now)
>> /docs
>> /jetspeed-portal-resources
>> /maven
>> /jetspeed-maven-plugins
>> /portal
>> /jetspeed-api
>> /jetspeed-commons
>> /components
>> /... (all components)
>> /assembly
>> /base-portal
>> /demo-portal
>> /jetspeed-installer
>> /...
>> /site?
>> /tutorials
>>
>> WDYT?
>>
> +1 Looks good.
> It makes sense to more slowly move towards a clean separation from the
> portal and all other projects
> That said, I believe we should move forward in creating a Portals
> Applications project under Portalst
+1
We should start drafting up a proposal for the PMC.
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] Refactoring
Posted by Mohan K R <km...@gmail.com>.
David wrote:
"
IMO, the core portal should only be basically:
* jetspeed api
* components
* commons
"
+1 keeping the core simple, I like it.
Re: [M2 build design] Refactoring
Posted by Mohan K R <km...@gmail.com>.
Comments inlined
On 8/27/07, Ate Douma <at...@douma.nu> wrote:
>
> Mohan K R wrote:
>
> <snip/>
> >
> >
> > I am still playing with the trunk, trying from a clean IDE environment
> to
> > see how easy the above structure is from a
> > developers perspective (unfortunately, eclipse and most other IDE's do
> not
> > support hierarchical projects, so there
> > will be pain I guess). I do endorse, David's proposal to have a separate
> > applications and move j2-admin there.
> Me too, as long as we keep it under our jetspeed-2 svn root (e.g. tied to
> the jetspeed-2 project itself).
I believe the intention here is to Maven-2 "aggregation" rather than
"inheritance", in that case it really does not
matter physically where the j2-admin lives.
> Further, how about refactoring j2-admin into sub components by functional
> > groups, as it stands right now it is
> > a monolithic beast, it has hard to rip out components we don't need (I
> > understand we can hide them from the psml,s).
> Yeah, j2-admin has become quite a mixture of different technologies (JSF,
> Struts, JSP. Velocity, dojo, etc.) and application features.
>
> I'm considering we should rebuild/rewrite the j2-admin using one chosen
> technology.
> For that I think JSF or Wicket are the best candidates.
> Note though, the portlet support I added to Wicket is still on a separate
> branch and has been stalled since I've been working on Jetspeed and away on
> holiday.
> But, I've allocated time this week on bringing Wicket portlet support up
> to date with the current Wicket trunk development.
>
> At my company we're building a new version of our CMS using Wicket which
> allows "pluggable" extensions like for managing specific content types,
> workflow etc.
> Maybe a neat idea to develop something similar for j2-admin, e.g. a
> generic "console" portlet which can "manage" a certain jetspeed "feature"
> based on runtime
> discovery of provided "extensions" (jars containing Wicket components).
> Just drop an extension jar in j2-admin/WEB-INF/lib and you are ready to
> go...
> It seems to be working out quite nicely for our CMS (also runnable as
> portlet) so we should be able to apply the same technique for j2-admin.
>
> Also note: I expected Wicket 1.3.0 to be released by now when I started
> adding the portlet support but its still in beta (3) right now.
> Therefore I will start discussing with the Wicket team about bringing
> portlet support into the trunk sooner, if possible before the Wicket 1.3.0release instead
> of afterwards as originally planned.
>
> I think Wicket is the best framework for these type of applications but we
> do need a reliable build and API to work with.
>
> Regards,
>
> Ate
I am really beginning to like the idea of extensions for the j2-admin
console (from what you wrote above), I am very much interested in pursuing
this option, can we open a j2-admin discussion thread to bounce some ideas
of the community. Way cool.
Cheers
mohan
Re: [M2 build design] Refactoring
Posted by Ate Douma <at...@douma.nu>.
Weaver, Scott wrote:
> Ate,
>
> I like the Wicket idea and the pluggable extensions is also very
> interesting. It sounds very much like it works very similar to the OSGi
> model.
Maybe somewhat, but it definitely shouldn't be regarded as an alternative to OSGi.
The solution we're developing at my office does not intend to support lifecyle management (e.g. start/stop/update/remove etc.), just simple auto-discovery of
provided extensions. So, you will be able to package new extensions with the application (e.g. jars in WEB-INF/lib) and a generic console portlet could be
written to pick it up and allow you to (re)configure its primary function to execute such an extension through portlet edit mode.
With just one generic console portlet in j2-admin, we could then provide an unlimited and extendable set of admin features.
The j2-admin core could provide base features like navigation (trees) and detail panels, inter-portlet communication/state synchronization, cache management
etc. for concrete admin "extensions" like security, pa, registry maintenance etc.
Well, that is the general idea at least. But first I will need to bring portlet support in Wicket up to an acceptable, reliable and (trunk) maintained state...
I'll be working full-time on that for the next two days and time beyond: there are still lots of uncovered issues to look into.
Today and tomorrow I'll be working on bringing the current portlet support branch back inline with the Wicket trunk and then move from there.
As soon as I've a new baseline ready I'll notify on this list too so hopefully others can spend some cycles on it for testing and reviewing.
Portlet usage and demand in the Wicket community isn't very big yet, so I can use some help here...
Regards,
Ate
>
> -scott
>
> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Monday, August 27, 2007 4:44 PM
> To: Jetspeed Developers List
> Subject: Re: [M2 build design] Refactoring
>
> Mohan K R wrote:
>
> <snip/>
>>
>> I am still playing with the trunk, trying from a clean IDE environment
> to
>> see how easy the above structure is from a
>> developers perspective (unfortunately, eclipse and most other IDE's do
> not
>> support hierarchical projects, so there
>> will be pain I guess). I do endorse, David's proposal to have a
> separate
>> applications and move j2-admin there.
> Me too, as long as we keep it under our jetspeed-2 svn root (e.g. tied
> to the jetspeed-2 project itself).
>
>> Further, how about refactoring j2-admin into sub components by
> functional
>> groups, as it stands right now it is
>> a monolithic beast, it has hard to rip out components we don't need (I
>> understand we can hide them from the psml,s).
> Yeah, j2-admin has become quite a mixture of different technologies
> (JSF, Struts, JSP. Velocity, dojo, etc.) and application features.
>
> I'm considering we should rebuild/rewrite the j2-admin using one chosen
> technology.
> For that I think JSF or Wicket are the best candidates.
> Note though, the portlet support I added to Wicket is still on a
> separate branch and has been stalled since I've been working on Jetspeed
> and away on holiday.
> But, I've allocated time this week on bringing Wicket portlet support up
> to date with the current Wicket trunk development.
>
> At my company we're building a new version of our CMS using Wicket which
> allows "pluggable" extensions like for managing specific content types,
> workflow etc.
> Maybe a neat idea to develop something similar for j2-admin, e.g. a
> generic "console" portlet which can "manage" a certain jetspeed
> "feature" based on runtime
> discovery of provided "extensions" (jars containing Wicket components).
> Just drop an extension jar in j2-admin/WEB-INF/lib and you are ready to
> go...
> It seems to be working out quite nicely for our CMS (also runnable as
> portlet) so we should be able to apply the same technique for j2-admin.
>
> Also note: I expected Wicket 1.3.0 to be released by now when I started
> adding the portlet support but its still in beta (3) right now.
> Therefore I will start discussing with the Wicket team about bringing
> portlet support into the trunk sooner, if possible before the Wicket
> 1.3.0 release instead
> of afterwards as originally planned.
>
> I think Wicket is the best framework for these type of applications but
> we do need a reliable build and API to work with.
>
> Regards,
>
> Ate
>
> ---------------------------------------------------------------------
> 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: [M2 build design] Refactoring
Posted by "Weaver, Scott" <we...@ugs.com>.
Ate,
I like the Wicket idea and the pluggable extensions is also very
interesting. It sounds very much like it works very similar to the OSGi
model.
-scott
-----Original Message-----
From: Ate Douma [mailto:ate@douma.nu]
Sent: Monday, August 27, 2007 4:44 PM
To: Jetspeed Developers List
Subject: Re: [M2 build design] Refactoring
Mohan K R wrote:
<snip/>
>
>
> I am still playing with the trunk, trying from a clean IDE environment
to
> see how easy the above structure is from a
> developers perspective (unfortunately, eclipse and most other IDE's do
not
> support hierarchical projects, so there
> will be pain I guess). I do endorse, David's proposal to have a
separate
> applications and move j2-admin there.
Me too, as long as we keep it under our jetspeed-2 svn root (e.g. tied
to the jetspeed-2 project itself).
> Further, how about refactoring j2-admin into sub components by
functional
> groups, as it stands right now it is
> a monolithic beast, it has hard to rip out components we don't need (I
> understand we can hide them from the psml,s).
Yeah, j2-admin has become quite a mixture of different technologies
(JSF, Struts, JSP. Velocity, dojo, etc.) and application features.
I'm considering we should rebuild/rewrite the j2-admin using one chosen
technology.
For that I think JSF or Wicket are the best candidates.
Note though, the portlet support I added to Wicket is still on a
separate branch and has been stalled since I've been working on Jetspeed
and away on holiday.
But, I've allocated time this week on bringing Wicket portlet support up
to date with the current Wicket trunk development.
At my company we're building a new version of our CMS using Wicket which
allows "pluggable" extensions like for managing specific content types,
workflow etc.
Maybe a neat idea to develop something similar for j2-admin, e.g. a
generic "console" portlet which can "manage" a certain jetspeed
"feature" based on runtime
discovery of provided "extensions" (jars containing Wicket components).
Just drop an extension jar in j2-admin/WEB-INF/lib and you are ready to
go...
It seems to be working out quite nicely for our CMS (also runnable as
portlet) so we should be able to apply the same technique for j2-admin.
Also note: I expected Wicket 1.3.0 to be released by now when I started
adding the portlet support but its still in beta (3) right now.
Therefore I will start discussing with the Wicket team about bringing
portlet support into the trunk sooner, if possible before the Wicket
1.3.0 release instead
of afterwards as originally planned.
I think Wicket is the best framework for these type of applications but
we do need a reliable build and API to work with.
Regards,
Ate
---------------------------------------------------------------------
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: [M2 build design] Refactoring
Posted by Ate Douma <at...@douma.nu>.
Mohan K R wrote:
<snip/>
>
>
> I am still playing with the trunk, trying from a clean IDE environment to
> see how easy the above structure is from a
> developers perspective (unfortunately, eclipse and most other IDE's do not
> support hierarchical projects, so there
> will be pain I guess). I do endorse, David's proposal to have a separate
> applications and move j2-admin there.
Me too, as long as we keep it under our jetspeed-2 svn root (e.g. tied to the jetspeed-2 project itself).
> Further, how about refactoring j2-admin into sub components by functional
> groups, as it stands right now it is
> a monolithic beast, it has hard to rip out components we don't need (I
> understand we can hide them from the psml,s).
Yeah, j2-admin has become quite a mixture of different technologies (JSF, Struts, JSP. Velocity, dojo, etc.) and application features.
I'm considering we should rebuild/rewrite the j2-admin using one chosen technology.
For that I think JSF or Wicket are the best candidates.
Note though, the portlet support I added to Wicket is still on a separate branch and has been stalled since I've been working on Jetspeed and away on holiday.
But, I've allocated time this week on bringing Wicket portlet support up to date with the current Wicket trunk development.
At my company we're building a new version of our CMS using Wicket which allows "pluggable" extensions like for managing specific content types, workflow etc.
Maybe a neat idea to develop something similar for j2-admin, e.g. a generic "console" portlet which can "manage" a certain jetspeed "feature" based on runtime
discovery of provided "extensions" (jars containing Wicket components).
Just drop an extension jar in j2-admin/WEB-INF/lib and you are ready to go...
It seems to be working out quite nicely for our CMS (also runnable as portlet) so we should be able to apply the same technique for j2-admin.
Also note: I expected Wicket 1.3.0 to be released by now when I started adding the portlet support but its still in beta (3) right now.
Therefore I will start discussing with the Wicket team about bringing portlet support into the trunk sooner, if possible before the Wicket 1.3.0 release instead
of afterwards as originally planned.
I think Wicket is the best framework for these type of applications but we do need a reliable build and API to work with.
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] Refactoring
Posted by Mohan K R <km...@gmail.com>.
Comments inline
On 8/24/07, David Sean Taylor <da...@bluesunrise.com> wrote:
>
>
> On Aug 24, 2007, at 6:02 AM, Ate Douma wrote:
>
> > David Sean Taylor wrote:
>
> >
> > Layout porlets maybe can also be moved under our (jetspeed-2)
> > applications root folder.
>
> +1 although the portal will not run without them
> The fate of layout portlets is still undetermined for 2.2
+1, for layout-portlets refactoring. I believe the structure we are moving
towards is
a portal "assembly" for the lack of a better word (from previous e-mail from
Ate's),
which is a good plan. As it will help both the developers and the
integrators. So a default
portal assembly will have the minimum resources required
(users/roles,default layouts,pages,
etc.). Also, I would like to pursue an option where we can have pluggable
theming, I have a
situation where we have a HTML/CSS designer who has no interest in learning
Java/JSP/Velocity
/<insert fav. templ.>, so if we could provide a clean separation that will
be awesome. I can definitely
devote some cycles on this effort.
>
> > So, summarizing, my proposed new directory structure would be:
> >
> > jetspeed-2/trunk
> > /applications
> > /j2-admin
> > /layout-portlets
> > /demo (for now)
> > /gems (for now)
> > /rss (for now)
> > /docs
> > /jetspeed-portal-resources
> > /maven
> > /jetspeed-maven-plugins
> > /portal
> > /jetspeed-api
> > /jetspeed-commons
> > /components
> > /... (all components)
> > /assembly
> > /base-portal
> > /demo-portal
> > /jetspeed-installer
> > /...
> > /site?
> > /tutorials
> >
> > WDYT?
> >
> +1 Looks good.
> It makes sense to more slowly move towards a clean separation from
> the portal and all other projects
> That said, I believe we should move forward in creating a Portals
> Applications project under Portalst
I am still playing with the trunk, trying from a clean IDE environment to
see how easy the above structure is from a
developers perspective (unfortunately, eclipse and most other IDE's do not
support hierarchical projects, so there
will be pain I guess). I do endorse, David's proposal to have a separate
applications and move j2-admin there.
Further, how about refactoring j2-admin into sub components by functional
groups, as it stands right now it is
a monolithic beast, it has hard to rip out components we don't need (I
understand we can hide them from the psml,s).
Cheers
Mohan K R
Re: [M2 build design] Refactoring
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 24, 2007, at 6:02 AM, Ate Douma wrote:
> David Sean Taylor wrote:
>> I would also like to discuss trimming down the core Jetspeed,
>> removing any old stuff, and moving out applications to its own
>> subversion repository
>> IMO, the core portal should only be basically:
>> * jetspeed api
>> * components
>> * commons
>
> +1
>
> I also agree to your proposed changes below, but like to provide a
> little (but not much) different solution which might help us to
> easier manage the different parts of the jetspeed-2 project without
> having to expand the Portals project itself (for now).
> Instead of moving out several parts to separate svn trunk folders
> above/besides our current jetspeed-2(/trunk) svn root, I like to
> propose keeping most (or everything) under this same root folder
> for now.
>
> I think we can also achieve our goal by instead create a new root
> subfolder called "portal".
> Under this "portal" folder, we can move the above mentioned
> folders, and probably some new folders for portal assembly projects
> (like the installer) etc.
> This new portal folder then can become the main checkout root for
> core portal development.
>
> On the same (root) level as the "portal" project, I'd like to keep
> the new maven and the jetspeed-portal-resources projects.
> I've discovered that having those as sub projects inside the main
> portal build is kind of tricky with respect of circular
> dependencies as the artifacts from these are also used within the
> build itself. Moving these out of the main build (and allow
> independent lifecylce management) will make our dependency
> management much cleaner and easier.
>
> Our current applications sub project (and in particular j2-admin)
> can also be moved to the same root level. This will make them also
> more independent of the (release) lifecycle of the "core" portal.
> Not all end-users/integrators use or need these applications.
> I do think j2-admin clearly belongs and should be kept under the
> jetspeed-2 svn root as it is an intrinsically jetspeed-2 specific
> application.
> The other current applications element like the gems, rss and demo
> (?) are not really tied to jetspeed-2, and I would be in favor of
> moving those to a new and more general Apache Portals Applications
> project (I also like to start developing other portlet applications
> for Forums, Wiki, Blogs, Mail, etc. and those will also be better
> placed under such a new Portals Applications project).
+1
>
> Layout porlets maybe can also be moved under our (jetspeed-2)
> applications root folder.
+1 although the portal will not run without them
The fate of layout portlets is still undetermined for 2.2
> And other root folders can be docs and tutorials.
>
> The main benefits of having these separate root folders
> (applications,portal,maven,jetspeed-portal-
> resources,docs,tutorials, site):
> - separate and independent checkout
> - possibility of managing their lifecyle independently (e.g.
> independent newer/bugfix releases of jetspeed-maven-plugin, j2-
> admin, portal, docs)
>
> Note though the one thing missing for (easy) independent lifecycle
> management is our current JIRA project setup.
> I think we might want to split/expand our current JIRA project and
> add new projects for:
> - j2-admin (J2ADMIN)
> - other applications (layouts?) (J2APPS)
> - jetspeed-maven-plugins (J2MAVEN)
> - jetspeed-portal-resources (J2RESOURCES)
> - site, docs & tutorials (J2DOC)
> - ...
Well, maybe. Do you know if other projects also create this many
project tags per project?
I don't want to create too many tags if there is no precedent
>
> So, summarizing, my proposed new directory structure would be:
>
> jetspeed-2/trunk
> /applications
> /j2-admin
> /layout-portlets
> /demo (for now)
> /gems (for now)
> /rss (for now)
> /docs
> /jetspeed-portal-resources
> /maven
> /jetspeed-maven-plugins
> /portal
> /jetspeed-api
> /jetspeed-commons
> /components
> /... (all components)
> /assembly
> /base-portal
> /demo-portal
> /jetspeed-installer
> /...
> /site?
> /tutorials
>
> WDYT?
>
+1 Looks good.
It makes sense to more slowly move towards a clean separation from
the portal and all other projects
That said, I believe we should move forward in creating a Portals
Applications project under Portalst
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] Refactoring
Posted by David Jencks <da...@yahoo.com>.
This looks really good to me
thanks
david jencks
On Aug 24, 2007, at 6:02 AM, Ate Douma wrote:
> David Sean Taylor wrote:
>> I would also like to discuss trimming down the core Jetspeed,
>> removing any old stuff, and moving out applications to its own
>> subversion repository
>> IMO, the core portal should only be basically:
>> * jetspeed api
>> * components
>> * commons
>
> +1
>
> I also agree to your proposed changes below, but like to provide a
> little (but not much) different solution which might help us to
> easier manage the different parts of the jetspeed-2 project without
> having to expand the Portals project itself (for now).
> Instead of moving out several parts to separate svn trunk folders
> above/besides our current jetspeed-2(/trunk) svn root, I like to
> propose keeping most (or everything) under this same root folder
> for now.
>
> I think we can also achieve our goal by instead create a new root
> subfolder called "portal".
> Under this "portal" folder, we can move the above mentioned
> folders, and probably some new folders for portal assembly projects
> (like the installer) etc.
> This new portal folder then can become the main checkout root for
> core portal development.
>
> On the same (root) level as the "portal" project, I'd like to keep
> the new maven and the jetspeed-portal-resources projects.
> I've discovered that having those as sub projects inside the main
> portal build is kind of tricky with respect of circular
> dependencies as the artifacts from these are also used within the
> build itself. Moving these out of the main build (and allow
> independent lifecylce management) will make our dependency
> management much cleaner and easier.
>
> Our current applications sub project (and in particular j2-admin)
> can also be moved to the same root level. This will make them also
> more independent of the (release) lifecycle of the "core" portal.
> Not all end-users/integrators use or need these applications.
> I do think j2-admin clearly belongs and should be kept under the
> jetspeed-2 svn root as it is an intrinsically jetspeed-2 specific
> application.
> The other current applications element like the gems, rss and demo
> (?) are not really tied to jetspeed-2, and I would be in favor of
> moving those to a new and more general Apache Portals Applications
> project (I also like to start developing other portlet applications
> for Forums, Wiki, Blogs, Mail, etc. and those will also be better
> placed under such a new Portals Applications project).
>
> Layout porlets maybe can also be moved under our (jetspeed-2)
> applications root folder.
>
> And other root folders can be docs and tutorials.
>
> The main benefits of having these separate root folders
> (applications,portal,maven,jetspeed-portal-
> resources,docs,tutorials, site):
> - separate and independent checkout
> - possibility of managing their lifecyle independently (e.g.
> independent newer/bugfix releases of jetspeed-maven-plugin, j2-
> admin, portal, docs)
>
> Note though the one thing missing for (easy) independent lifecycle
> management is our current JIRA project setup.
> I think we might want to split/expand our current JIRA project and
> add new projects for:
> - j2-admin (J2ADMIN)
> - other applications (layouts?) (J2APPS)
> - jetspeed-maven-plugins (J2MAVEN)
> - jetspeed-portal-resources (J2RESOURCES)
> - site, docs & tutorials (J2DOC)
> - ...
>
> So, summarizing, my proposed new directory structure would be:
>
> jetspeed-2/trunk
> /applications
> /j2-admin
> /layout-portlets
> /demo (for now)
> /gems (for now)
> /rss (for now)
> /docs
> /jetspeed-portal-resources
> /maven
> /jetspeed-maven-plugins
> /portal
> /jetspeed-api
> /jetspeed-commons
> /components
> /... (all components)
> /assembly
> /base-portal
> /demo-portal
> /jetspeed-installer
> /...
> /site?
> /tutorials
>
> WDYT?
>
> Ate
>
>> Proposed changes:
>> * applications -- move to new svn project called "applications"
>> including j2-admin
>> * app-servers -- not entirely sure whats here, but I think it
>> should be a "configuration" of some sort
>> * archives -- remove it
>> * design-docs -- this needs review and deletion of old artifacts
>> (man I can hear echoes of Kent Beck talking about the code being
>> the only real artifact...)
>> * docs -- same as above, combine design-docs + docs --> docs
>> * etc -- I would think this should be moved into the
>> "configuration" layer to be discussed
>> * graphic_design -- a few logos..
>> * jetspeed-ant-tasks -- i understand this is used for the
>> installer, but this is also an area that needs further discussion,
>> should Jetspeed provide Ant tasks ... I think the answer may be yes
>> * jetspeed-installer - that is written in Maven-1, going to be
>> interesting to see if we can port it to Maven-2 (yes I am being
>> skeptical)
>> * jetspeed-portal-resources -- this is new, I will let Ate comment
>> on it
>> * layout-portlets -- I think layouts need to be refactored but
>> thats another discusson
>> * maven -- this is new, I will let Ate explain it to us
>> * patched-jars -- its empty
>> * taglibs -- thats one ugly tree view taglib, i think we should
>> get this out of the portal as its not the right place and look
>> into porting j2-admin portlets that use it to something more
>> standard like Wicket or JDSF
>> * tutorial -- move to new svn project called "tutorials"
>> ---------------------------------------------------------------------
>> 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