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/22 04:40:01 UTC
Re: [M2 build design] Getting started - status update
The trunk is now (partly) buildable *and* testable again!
You need to update you the local m2 settings.xml with the following required properties for your selected database (I've updated settings.xml.sample with
example values):
<org.apache.jetspeed.test.jdbc.driver.groupId>SETGROUPID</org.apache.jetspeed.test.jdbc.driver.groupId>
<org.apache.jetspeed.test.jdbc.driver.artifactId>SETARTIFACTID</org.apache.jetspeed.test.jdbc.driver.artifactId>
<org.apache.jetspeed.test.jdbc.driver.version>SETVERSION</org.apache.jetspeed.test.jdbc.driver.version>
<org.apache.jetspeed.production.jdbc.driver.groupId>SETGROUPID</org.apache.jetspeed.test.jdbc.driver.groupId>
<org.apache.jetspeed.production.jdbc.driver.artifactId>SETARTIFACTID</org.apache.jetspeed.test.jdbc.driver.artifactId>
<org.apache.jetspeed.production.jdbc.driver.version>SETVERSION</org.apache.jetspeed.test.jdbc.driver.version>
Then create a new portal test database schema:
$ mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
And finally, you then can build *and* test the jetspeed-api and the components with:
$ mvn -P test install
Happy testing :)
Regards,
Ate
Ate Douma wrote:
> Dear community,
>
> I'm back from holiday and ready to get my hands dirty again :)
>
> I want to start with the new maven-2 build solution as I outlined
> before, see:
>
> http://www.nabble.com/-M2-build-design----research-branch-M2-J2-REDUX-experiences-tf4114611.html
>
>
> Although I wasn't able to finish my initial plans for the J2-M2-REDUX
> branch, I think it will be a good starting point for others to join in.
> I'm planning to repeat the steps I did for that branch on the current
> trunk (2.2-SNAPSHOT), starting later today or early tomorrow.
>
> This means (globally) the following:
> - deleting *all* current M1 and M2 build configurations
> - refactoring the (source and resource) directory structures to get into
> line with the M2 recommendated setup
> - factor out the common portal resources (now scattered under etc/ and
> src/webapp/) in a new sub project
> - adding new M2 plugins for managing, distributing and executing these
> resources as needed
> - refactor the JetspeedSerializer component to allow better separation
> of concerns,
> e.g. it needs to become independent of other components which need a
> configured database for (Unit) testing
> - define new M2 project descriptors for building and testing (at least)
> the based portal components
>
> This requires a full overhaul of the current code base, so I need to be
> able to perform the above steps undisturbed by other changes.
> Other committers: please hold off changes to the trunk from now on until
> I'm ready.
> As I've already done all of the above before on the J2-M2-REDUX branch,
> I think I can complete this in a few days time.
>
> Now, after all of this, we're still far away from a new (fully) working
> build environment, especially with regards to building a working portal.
> Also, I'm still not 100% sure the solution for management of the portal
> resources I created is the best way to do so.
> It will need further review and discussion and possibly be changed again.
> For that and for completing the new M2 setup, I will need others to step
> up and help out.
> Especially with setting up basic and custom portal assembly and possibly
> archetype projects, migration guides and tools and of course a overhaul
> of our (build) documentation.
>
> As soon as I think I have a minimal new build setup ready for others to
> join in, I'll notify again on the list and ask for you help.
>
> For now, please all be warned the state of the trunk will be in turmoil
> and mostly unusable for the next few days and beyond.
> Developers currently still hooked up on the trunk best move to the
> 2.1.3-dev branch which is maintained for minor bugfixes and improvements
> to the latest 2.1.2 release.
>
> 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 David Sean Taylor <da...@bluesunrise.com>.
On Aug 27, 2007, at 9:16 AM, Ate Douma wrote:
> David Sean Taylor wrote:
>> Scott,
>> Nesting is an absolute requirement.
> +1
> Same goes for a (inline) layout-customizer solution.
>
>> We ripped out the content-server a while back
>> I don't really care what technology (portlets, templates, JSP,
>> Velocity ..) is used to implement them.
> My preference is that we (at least) allow to use portlets as main
> entry point for layout rendering.
> Being able to render and manage the layout through our core
> technology (portlets) is in my opinion important to maintain, both
> for support as well as presentation/communication purposes.
> Allowing additional layout (technology) solutions on the other hand
> would be great of course (as long as it integrates well and is easy
> to maintain).
> A new "layout and decoration api" as I proposed earlier in another
> mail might be a good starting point to provide a better abstraction
> for this.
>
>> I think the main thing we need to consider with layouts is:
>> * making layouts very easy to deploy to the system
>> * making layouts extensible. I don't want to create a new portlet
>> just to go from 3 column 33,33,33 to 25,50,25
> Which isn't needed anyway, you can configure/override that using
> psml fragment properties although those cannot be set through the
> inline layout customizer.
Yes it can, but only with the desktop customizer
>
>> * making layouts completely editable from the customizer (like the
>> Desktop supports, but not quite with the portal)
>> I think the main problem with portlet based layouts is that it
>> doesn't extend well.
>> Say I want to create my own layout, I have to get the jar
>> dependencies from the base jetspeed, and build my own layout war
>> I guess that is OK if I am writing my own layout algorithms, but I
>> have found that I usually just need to extend the base layouts
>> Another possible issue I see is that the customization code is
>> directly built into the layouts due to the fact that we wanted
>> "edit in place"
>> We also need to discuss how people will map the old layouts to new
>> layouts
> Yes.
> In my view, we should strive to be at least backwards compatible on
> layouts for the 2.2 release.
> We are already going to change a lot in 2.2 which might result in
> quite a few upgrade issues.
> Layouts and decorations are likely the most customized elements of
> a custom portal, so lets try to keep the pain minimal in that area.
> Deprecating our current layout solution (if need be) would be an
> alternative allowing end users time to upgrade until at least
> release >= 2.3.
>
Agree on backward compatibility as a must
That said, I really think we can improve on the current solution. I
just want to make sure we consider from the start:
* complete customization of all features of the layout, such as
easily replacing the logo or color themes with the customizer
* lots of code reviews before acceptance
* performance issues. Lets hits the performance issues earlier in the
cycle this time, from past experience
* strive to make layouts more usable from designer tools. Im afraid
that using Velocity is just not going to cut it with this requirement
---------------------------------------------------------------------
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 Sean Taylor <da...@bluesunrise.com>.
On Aug 28, 2007, at 7:17 AM, Weaver, Scott wrote:
> I think a side by side would be the way to go. The reason I yanked
> portlet-based layouts is that, at the time, they were some clunky and
> auto-deployment wasn't working consistently, at least for me. I went
> with the simplest approach using just Velocity running is a valve and
> directly interacting with the aggregation engine. This eliminates the
> need to for theme designers to pack each, new layout/theme as a
> portlet.
> There is also no need for a specific, deployment mechanism for
> themes as
> they just sit in a /theme directory right off the root of the
> application. This approach also allows me to easily proxy static
> content through Apache for performance's sake.
> The theme system provides for localized and device/content-type
> specific
> (which I am pretty sure was in the previous layout mechanism) themes.
>
> /themes/html/page.html
> /themes/html/de/page.html
> /themes/xml/page.xml
>
> It also supports fall back.
Yes the previous approach supported language and media type fallback
for templates.
In retrospect, although this feature is useful, it should be optional
as its often not used at all
>
> /themes/html/en/ <--page.html not found here so move up one level.
> /themes/html/page.html <-- found here, so use it.
>
>
---------------------------------------------------------------------
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>.
I think a side by side would be the way to go. The reason I yanked
portlet-based layouts is that, at the time, they were some clunky and
auto-deployment wasn't working consistently, at least for me. I went
with the simplest approach using just Velocity running is a valve and
directly interacting with the aggregation engine. This eliminates the
need to for theme designers to pack each, new layout/theme as a portlet.
There is also no need for a specific, deployment mechanism for themes as
they just sit in a /theme directory right off the root of the
application. This approach also allows me to easily proxy static
content through Apache for performance's sake.
The theme system provides for localized and device/content-type specific
(which I am pretty sure was in the previous layout mechanism) themes.
/themes/html/page.html
/themes/html/de/page.html
/themes/xml/page.xml
It also supports fall back.
/themes/html/en/ <--page.html not found here so move up one level.
/themes/html/page.html <-- found here, so use it.
-----Original Message-----
From: Mohan K R [mailto:kmoh.raj@gmail.com]
Sent: Tuesday, August 28, 2007 9:40 AM
To: Jetspeed Developers List
Subject: Re: [M2 build design] Refactoring
On 8/27/07, Ate Douma <at...@douma.nu> wrote:
>
> David Sean Taylor wrote:
> > Scott,
> >
> > Nesting is an absolute requirement.
> +1
> Same goes for a (inline) layout-customizer solution.
>
> > We ripped out the content-server a while back
> >
> > I don't really care what technology (portlets, templates, JSP,
Velocity
> > ..) is used to implement them.
> My preference is that we (at least) allow to use portlets as main
entry
> point for layout rendering.
> Being able to render and manage the layout through our core technology
> (portlets) is in my opinion important to maintain, both for support as
well
> as
> presentation/communication purposes.
> Allowing additional layout (technology) solutions on the other hand
would
> be great of course (as long as it integrates well and is easy to
maintain).
> A new "layout and decoration api" as I proposed earlier in another
mail
> might be a good starting point to provide a better abstraction for
this.
>
> > I think the main thing we need to consider with layouts is:
> >
> > * making layouts very easy to deploy to the system
> > * making layouts extensible. I don't want to create a new portlet
just
> > to go from 3 column 33,33,33 to 25,50,25
> Which isn't needed anyway, you can configure/override that using psml
> fragment properties although those cannot be set through the inline
layout
> customizer.
>
> > * making layouts completely editable from the customizer (like the
> > Desktop supports, but not quite with the portal)
> >
> > I think the main problem with portlet based layouts is that it
doesn't
> > extend well.
> > Say I want to create my own layout, I have to get the jar
dependencies
> > from the base jetspeed, and build my own layout war
> > I guess that is OK if I am writing my own layout algorithms, but I
have
> > found that I usually just need to extend the base layouts
> >
> > Another possible issue I see is that the customization code is
directly
> > built into the layouts due to the fact that we wanted "edit in
place"
> >
> > We also need to discuss how people will map the old layouts to new
> layouts
> Yes.
> In my view, we should strive to be at least backwards compatible on
> layouts for the 2.2 release.
> We are already going to change a lot in 2.2 which might result in
quite a
> few upgrade issues.
> Layouts and decorations are likely the most customized elements of a
> custom portal, so lets try to keep the pain minimal in that area.
> Deprecating our current layout solution (if need be) would be an
> alternative allowing end users time to upgrade until at least release
>=
> 2.3.
Can't we preserve the current layout implementation and still provide a
*new* layout solution that is independent and not the default, so
existing
layout would still function?
---------------------------------------------------------------------
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:
> On 8/27/07, Ate Douma <at...@douma.nu> wrote:
>> David Sean Taylor wrote:
<snip/>
>>> We also need to discuss how people will map the old layouts to new
>> layouts
>> Yes.
>> In my view, we should strive to be at least backwards compatible on
>> layouts for the 2.2 release.
>> We are already going to change a lot in 2.2 which might result in quite a
>> few upgrade issues.
>> Layouts and decorations are likely the most customized elements of a
>> custom portal, so lets try to keep the pain minimal in that area.
>> Deprecating our current layout solution (if need be) would be an
>> alternative allowing end users time to upgrade until at least release >=
>> 2.3.
>
>
> Can't we preserve the current layout implementation and still provide a
> *new* layout solution that is independent and not the default, so existing
> layout would still function?
Well, we haven't even started properly discuss and design what the new layout and decoration api should look like so its a bit speculative right now, but my
preferred solution would be reimplementing our current layout implementation on top of such a new api besides providing a new direct/more advanced solution of
course. That way, we will have only one layout and decoration engine to maintain while maintaining (temporarily) backwards compatibility.
The out-dated current solution could then be deprecated and possibly dropped after release >= 2.3.
But as said, this is quite speculative right now.
Furthermore, I think we are talking about two different approaches here.
I think what Scott is proposing is a radical different way how layout and decoration is *executed* while my original proposal concerns more about a new layout
and decoration engine how to write/define new layout and decoration templating in a somewhat similar way as Wicket does it but still executed from (new) layout
portlets.
There is probably some overlap in features so they might go hand in hand, but not necessarily so.
My first impression is that a radical new layout/decoration execution model might be difficult to support backwards compatibility resulting in two separate
engines which I find less ideal. But if Scotts solution can match all our current features and turns out to be easier to work with and extend upon, it might be
worthwhile to (temporarily) maintain two different solutions.
---------------------------------------------------------------------
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>.
On 8/27/07, Ate Douma <at...@douma.nu> wrote:
>
> David Sean Taylor wrote:
> > Scott,
> >
> > Nesting is an absolute requirement.
> +1
> Same goes for a (inline) layout-customizer solution.
>
> > We ripped out the content-server a while back
> >
> > I don't really care what technology (portlets, templates, JSP, Velocity
> > ..) is used to implement them.
> My preference is that we (at least) allow to use portlets as main entry
> point for layout rendering.
> Being able to render and manage the layout through our core technology
> (portlets) is in my opinion important to maintain, both for support as well
> as
> presentation/communication purposes.
> Allowing additional layout (technology) solutions on the other hand would
> be great of course (as long as it integrates well and is easy to maintain).
> A new "layout and decoration api" as I proposed earlier in another mail
> might be a good starting point to provide a better abstraction for this.
>
> > I think the main thing we need to consider with layouts is:
> >
> > * making layouts very easy to deploy to the system
> > * making layouts extensible. I don't want to create a new portlet just
> > to go from 3 column 33,33,33 to 25,50,25
> Which isn't needed anyway, you can configure/override that using psml
> fragment properties although those cannot be set through the inline layout
> customizer.
>
> > * making layouts completely editable from the customizer (like the
> > Desktop supports, but not quite with the portal)
> >
> > I think the main problem with portlet based layouts is that it doesn't
> > extend well.
> > Say I want to create my own layout, I have to get the jar dependencies
> > from the base jetspeed, and build my own layout war
> > I guess that is OK if I am writing my own layout algorithms, but I have
> > found that I usually just need to extend the base layouts
> >
> > Another possible issue I see is that the customization code is directly
> > built into the layouts due to the fact that we wanted "edit in place"
> >
> > We also need to discuss how people will map the old layouts to new
> layouts
> Yes.
> In my view, we should strive to be at least backwards compatible on
> layouts for the 2.2 release.
> We are already going to change a lot in 2.2 which might result in quite a
> few upgrade issues.
> Layouts and decorations are likely the most customized elements of a
> custom portal, so lets try to keep the pain minimal in that area.
> Deprecating our current layout solution (if need be) would be an
> alternative allowing end users time to upgrade until at least release >=
> 2.3.
Can't we preserve the current layout implementation and still provide a
*new* layout solution that is independent and not the default, so existing
layout would still function?
Re: [M2 build design] Refactoring
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> Scott,
>
> Nesting is an absolute requirement.
+1
Same goes for a (inline) layout-customizer solution.
> We ripped out the content-server a while back
>
> I don't really care what technology (portlets, templates, JSP, Velocity
> ..) is used to implement them.
My preference is that we (at least) allow to use portlets as main entry point for layout rendering.
Being able to render and manage the layout through our core technology (portlets) is in my opinion important to maintain, both for support as well as
presentation/communication purposes.
Allowing additional layout (technology) solutions on the other hand would be great of course (as long as it integrates well and is easy to maintain).
A new "layout and decoration api" as I proposed earlier in another mail might be a good starting point to provide a better abstraction for this.
> I think the main thing we need to consider with layouts is:
>
> * making layouts very easy to deploy to the system
> * making layouts extensible. I don't want to create a new portlet just
> to go from 3 column 33,33,33 to 25,50,25
Which isn't needed anyway, you can configure/override that using psml fragment properties although those cannot be set through the inline layout customizer.
> * making layouts completely editable from the customizer (like the
> Desktop supports, but not quite with the portal)
>
> I think the main problem with portlet based layouts is that it doesn't
> extend well.
> Say I want to create my own layout, I have to get the jar dependencies
> from the base jetspeed, and build my own layout war
> I guess that is OK if I am writing my own layout algorithms, but I have
> found that I usually just need to extend the base layouts
>
> Another possible issue I see is that the customization code is directly
> built into the layouts due to the fact that we wanted "edit in place"
>
> We also need to discuss how people will map the old layouts to new layouts
Yes.
In my view, we should strive to be at least backwards compatible on layouts for the 2.2 release.
We are already going to change a lot in 2.2 which might result in quite a few upgrade issues.
Layouts and decorations are likely the most customized elements of a custom portal, so lets try to keep the pain minimal in that area.
Deprecating our current layout solution (if need be) would be an alternative allowing end users time to upgrade until at least release >= 2.3.
>
> On Aug 23, 2007, at 1:06 PM, Weaver, Scott wrote:
>
>> David,
>>
>> * layout-portlets -- I think layouts need to be refactored but thats
>> another discusson
>>
>> I have a portlet-free layout/theme system (inspired loosely by how
>> Drupal does their themes) that I can donate to Jetspeed. It has worked
>> very well for me for the last year and a half. It is easy to relatively
>> to understand and work with, and doesn't require a content-server for
>> images, javascript, etc. I am currently working on a migration to 2.1.3
>> so that will give me cause to make sure it works with the latest and
>> greatest Jetspeed. I don't do any nesting or anything like that as
>> there has never been a requirement for me, so that might need to be
>> addressed.
>>
>> -scott
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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 David Sean Taylor <da...@bluesunrise.com>.
Scott,
Nesting is an absolute requirement.
We ripped out the content-server a while back
I don't really care what technology (portlets, templates, JSP,
Velocity ..) is used to implement them.
I think the main thing we need to consider with layouts is:
* making layouts very easy to deploy to the system
* making layouts extensible. I don't want to create a new portlet
just to go from 3 column 33,33,33 to 25,50,25
* making layouts completely editable from the customizer (like the
Desktop supports, but not quite with the portal)
I think the main problem with portlet based layouts is that it
doesn't extend well.
Say I want to create my own layout, I have to get the jar
dependencies from the base jetspeed, and build my own layout war
I guess that is OK if I am writing my own layout algorithms, but I
have found that I usually just need to extend the base layouts
Another possible issue I see is that the customization code is
directly built into the layouts due to the fact that we wanted "edit
in place"
We also need to discuss how people will map the old layouts to new
layouts
On Aug 23, 2007, at 1:06 PM, Weaver, Scott wrote:
> David,
>
> * layout-portlets -- I think layouts need to be refactored but thats
> another discusson
>
> I have a portlet-free layout/theme system (inspired loosely by how
> Drupal does their themes) that I can donate to Jetspeed. It has
> worked
> very well for me for the last year and a half. It is easy to
> relatively
> to understand and work with, and doesn't require a content-server for
> images, javascript, etc. I am currently working on a migration to
> 2.1.3
> so that will give me cause to make sure it works with the latest and
> greatest Jetspeed. I don't do any nesting or anything like that as
> there has never been a requirement for me, so that might need to be
> addressed.
>
> -scott
>
---------------------------------------------------------------------
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>.
David,
* layout-portlets -- I think layouts need to be refactored but thats
another discusson
I have a portlet-free layout/theme system (inspired loosely by how
Drupal does their themes) that I can donate to Jetspeed. It has worked
very well for me for the last year and a half. It is easy to relatively
to understand and work with, and doesn't require a content-server for
images, javascript, etc. I am currently working on a migration to 2.1.3
so that will give me cause to make sure it works with the latest and
greatest Jetspeed. I don't do any nesting or anything like that as
there has never been a requirement for me, so that might need to be
addressed.
-scott
-----Original Message-----
From: David Sean Taylor [mailto:david@bluesunrise.com]
Sent: Thursday, August 23, 2007 12:03 PM
To: Jetspeed Developers List
Subject: [M2 build design] Refactoring
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
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>.
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 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 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
Re: [M2 build design] Refactoring
Posted by Ate Douma <at...@douma.nu>.
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
[M2 build design] Refactoring
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
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
Re: [M2 build design] Getting started - status update
Posted by Ate Douma <at...@douma.nu>.
Small update to the current status.
One think I forgot to mention in my initial status update mail is that the Jetspeed-2 trunk now requires maven-2.0.7.
Additionally, David encountered several problems with building the current trunk which are related to bootstrapping the build itself and initializing the database.
I've commited some changes to the root pom.xml a few minutes agao to "solve" these issues.
Note though, as we depend on both our own maven plugins as well as on sql scripts generated from our own schema definitions before (database related) testcases
can be run, kick starting the build from scratch as well as being able to run the test cases is and will remain tricky to say the least...
The changes revolves around moving our root pom modules configuration to separate profiles.
I've created an "all" profile containing all the modules which will be activedByDefault.
So you can build and install the whole shebang right after checkout if you don't care for running the testcases.
This should do for most non-core developers and users.
Run this profile with:
$ mvn install
Additionally, I've created an "init" profile which you can/need to run as first if you need to run the testcases and/or made changes to either the plugin or
portal resources. This profile will only include the plugin and portal-resources modules.
Run this profile with:
$ mvn -P init install
Then, I also added a new profile "init-db". This profile doesn't have any modules configured, but the init-db plugin goal is hooked up on the "test-compile"
phase and configured to initialize the *test* database, and will only actually do anything when run within the root project.
Run this profile with:
$ mvn -P init-db test
Finally, I had to modify the "test" profile which previously only configured the maven.test.skip=true property, but as maven-2 has the "nice" behavior of
disabling any other profile when you explicitly invoke one on the command line using -P, the "test" profile now also needs to have all modules configured.
Initializing the test or production database by direct calling the plugin from the command line also still works, but I slightly renamed the profiles needed to
active them. You can call this from the root project or any sub project.
For the production database the profile is now called "prod-db" and likewise for the test database "test-db".
Run these profiles with:
$ mvn -P prod-db org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
or
$ mvn -P test-db org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
Note, the above is a bit long command to type in, but you can make it much easier if you add the following to your local m2 settings.xml (I'll add this to the
settings.xml.sample as well):
<pluginGroups>
<pluginGroup>org.apache.portals.jetspeed-2</pluginGroup>
</pluginGroups>
Once you've done that, the above commands can be executed with:
$ mvn -P prod-db jetspeed:init-db
or
$ mvn -P test-db jetspeed:init-db
Regards,
Ate
Ate Douma wrote:
> David Sean Taylor wrote:
>
>>> [ERROR] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Unable to build project 'jetspeed-2/pom.xml; it requires Maven
>>> version 2.0.7
>>>
>> OK, I installed 2.0.7
> Ugh, yes I should have mentioned that.
> I was also discussed before:
>
> http://www.nabble.com/Further-Jetspeed-2-development-plans-tf4087420.html#a11669880
>
>>
>> Try again:
>>
>> mvn -P test-setup
>> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>>
>> Now I get:
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] A required plugin was not found: Plugin could not be found -
>> check that the goal name is correct: Unable to download the artifact
>> from any repository
>>
>> Try downloading the file manually from the project website.
>>
>> Then, install it using the command:
>> mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
>> -DartifactId=jetspeed-maven-plugins \
>> -Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin
>> -Dfile=/path/to/file
>> Alternatively, if you host your own repository you can deploy the file
>> there: mvn deploy:deploy-file
>> -DgroupId=org.apache.portals.jetspeed-2
>> -DartifactId=jetspeed-maven-plugins \
>> -Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin
>> -Dfile=/path/to/file \
>> -Durl=[url] -DrepositoryId=[id]
>>
> Jeez, yes I forgot you need to bootstrap the plugin once :(
> If I find the time I'll try writing a more complete "getting started"
> later today...
>
>>
>> So I wasn't sure what to do next, and tried:
>>
>> $ cd maven/jetspeed-maven-plugins/
>> $ mvn install
>>
>> (man that command must have downloaded an army of jar files)
>> tried again:
>>
>> mvn -P test-setup
>> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>>
>> and then I get:
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Failed to resolve artifact.
>>
>> GroupId: org.apache.portals.jetspeed-2
>> ArtifactId: jetspeed-portal-resources
>> Version: 2.2-SNAPSHOT
>>
>> Reason: Unable to download the artifact from any repository
>>
>> Try downloading the file manually from the project website.
>>
>> Then, install it using the command:
>> mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
>> -DartifactId=jetspeed-portal-resources \
>> -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
>> Alternatively, if you host your own repository you can deploy the file
>> there: mvn deploy:deploy-file
>> -DgroupId=org.apache.portals.jetspeed-2
>> -DartifactId=jetspeed-portal-resources \
>> -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \
>> -Durl=[url] -DrepositoryId=[id]
>>
>>
>> org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar:2.2-SNAPSHOT
>>
>>
>> So I tried building the portal resources, but that didn't work either
>> So then I tried going to the jetspeed root directory
>>
>> $ mvn install
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESSFUL
>> [INFO]
>> ------------------------------------------------------------------------
>>
>>
>> back to your instructions:
>>
>> mvn -P test-setup
>> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>>
>> and it got further, it didn't find my jdbc driver:
>>
>> ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Driver class not found: com.mysql.jdbc.Driver
>>
>> The properties are set in my settings.xml to the best of my abilities.
>> However, I think that it fails because the the format of the
>> settings.xml changed, and I need to convert over to your new sample
>> settings.xml
>> I have this kind of thing in there:
>>
>> <activeProfile>jetspeed-db-drivers-path</activeProfile>
>>
>> But now there is some new format like:
>>
>> <profile>
>> <id>jetspeed-mysql</id>
>>
> It should not be because of that.
> Maybe you haven't yet added the new additional properties I described in
> my earlier mail?
> You do need to add those to your current activeProfile, for mysql:
>
>
> <org.apache.jetspeed.test.jdbc.driver.groupId>mysql</org.apache.jetspeed.test.jdbc.driver.groupId>
>
>
> <org.apache.jetspeed.test.jdbc.driver.artifactId>mysql-connector-java</org.apache.jetspeed.test.jdbc.driver.artifactId>
>
>
> <org.apache.jetspeed.test.jdbc.driver.version>5.0.4-bin</org.apache.jetspeed.test.jdbc.driver.version>
>
>
>> I will try to switch to that format next....
>> Is this property required?:
>>
>>
>> <org.apache.jetspeed.test.jdbc.drivers.path>${org.apache.jetspeed.server.home}/shared/lib/mysql-connector-java-5.0.4-bin.jar</org.apache.jetspeed.test.jdbc.drivers.path>
>
> No, its not used anymore with the new build, but you better keep it for
> now as you still need it if you want to build < 2.2-SNAPSHOT (e.g.
> 2.1.3-dev) using m2.
>
>
> ---------------------------------------------------------------------
> 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] Getting started - status update
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Aug 23, 2007, at 12:53 AM, Ate Douma wrote:
>> Maybe you haven't yet added the new additional properties I described
>> in my earlier mail?
>> You do need to add those to your current activeProfile, for mysql:
>>
>>
>> <org.apache.jetspeed.test.jdbc.driver.groupId>mysql</org.apache.jetspeed.test.jdbc.driver.groupId>
>>
>>
>> <org.apache.jetspeed.test.jdbc.driver.artifactId>mysql-connector-java</org.apache.jetspeed.test.jdbc.driver.artifactId>
>>
>>
>> <org.apache.jetspeed.test.jdbc.driver.version>5.0.4-bin</org.apache.jetspeed.test.jdbc.driver.version>
>>
>>
> Right. Already got that from your original email instructions.
> There were some typos in the cut and paste samples. I fixed that and got
> this message on both counts:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 3 minutes 47 seconds
> [INFO] Finished at: Thu Aug 23 08:29:58 PDT 2007
> [INFO] Final Memory: 22M/48M
>
> Excellent. A new Maven build. This is exciting to think the project can
> finally move forward now. Thanks for making this happen.
You're welcome :)
>
> So now Im wondering about a couple of things
> These are not support questions, but just me thinking out loud so excuse
> me if Im not as far into the thinking process about Maven builds as you are
> I am not really so much concerned with the intricacies of mavenology,
> but more concerned with high level questions like:
>
> * How can end users easily remove some (but not all) of the "demo"
> decorators
> * How can end users easily remove some (but not all) of the "demo" pages
> * How can end users easily override the Spring configurations
> * How can an end user have several builds, perhaps a production build
> with full production level database, and then a developers build with a
> Jetspeed Lite like configuration
> * How to manage the jar dependencies in these different configurations.
> I think that the Serializer showed us some of the challenges
These are the real use-cases we need to provide proper solutions for, and I can easily come up with lots of other but similar use-cases too.
The real challenge isn't so much building the based components (that's working now), but handling the multiple ways users want to incorporate and configure
jetspeed in their project and provide tooling for managing it.
I think it all boils down to configurations and how far we need and can go in providing support to automate that.
The real problem we have with build tools like maven-1, maven-2 and likewise with ant are the multiple areas of configuration we're facing:
- databases (or even not, "jetspeed-light" using xml based persistence?)
- application servers
- spring assembly
- other jetspeed web resources (pages, templates)
- database/xml seeding
- deployment of additional resources (portlet applications, decorators, templates)
- ide integration (e.g. proper WTP support)
I think the reason why maven-1 as well as maven-2 have given us so much trouble is that the number of options are much bigger than with the common maven based
projects.
Even a project like Geronimo, which probably has a bigger codebase, has I think an easier job because end users mostly use it out-of-the-box and configure it
only after installation.
Jetspeed is much more used (in my experience) as a platform and framework for custom portal development.
Maven does provide (somewhat) support for that with archetypes, but that still require us to solve the above issues ourselves.
So, how are we going to provide a (or multiple) solutions which is easy to use, understandable and maintainable, and satisfactory for users of ant, maven-2 or
even still maven-1?
I think the jetspeed-portal-resources artifact I created, which contains *all* optional/configurable resources, can be the base of the solution.
It is just a jar file with everything jarred up in specific folders.
By selectively extracting the resources needed, creating custom portal configurations should become easier to do.
I already use this in the test setups of the components by only extracting needed assembly files and specific database ddl.
I think it is not so much a question how to remove certain parts of the portal resources like some (but not all) decorators/pages/templates/etc. but more how
not providing those in the first place.
It should also be quite easy to create custom maven-2 plugins to extract specific features, something like:
$ mvn jetspeed:resource -Dlayout-decorator=tigris,sunflower -Dportlet-decoration=tigris,blueocean
With regard to assembly configurations we might want to investigate certain common setup/combination parts, like ldap|db, file-pm|db-pm, tomcat|jetty|jboss, and
provide sets of assembly files which go together. And additionally we can provide base setup definitions like standard|light.
Then I can imagine a new plugin allowing you to quickly setup an assembly with:
$ mvn jetspeed:assembly -Dsetup=standard -Dconfig=ldap,db-pm,websphere,
or
$ mvn jetspeed:assembly -Dsetup=light -Dconfig=db,file-pm,jetty
And I think a similar solution could be provided for extracting specific sets of psml pages.
This of course is still low level tooling, but we can also provide higher level support using predefined assembly projects for building full blown portals for
selected application servers, databases and configurations as well as installer(s).
Finally, through archetypes we can provide bootstrapping new custom portal projects from scratch in the same manner.
But, although this might (hopefully) work out quite well for the development team itself and other maven-2 users, for ant (and possibly still maven-1) based
projects we need to go a little further.
Of course, we can provide complete and complex ant scripts doing the same things, but I'm afraid it will end up in a maintenance nightmare and discrepancies
between the different build sets.
I think we might be better off with trying to "bridge" our maven-2 plugins in ant (and maven-1) using the maven-ant-tasks. I haven't really dived into that yet,
but it might be the solution to solve the dependency as well as the configuration management problems.
Anyone with experiences in this area?
>
> I think this somehow ties into the resource plugin that you wrote, so
> maybe you can explain that one in a little detail to get us all up to
> speed such as:
>
> * why is Maven not good enough out of the box, why do we need a custom
> plugin to manage simple things like resource configurations (Im not
> trying to devalue Maven, just would like to understand)
I tried to answer that above already.
> * how does the resource plugin help to meet the needs of the five cases
> listed about
The unpack-resources plugin I wrote is just a simple plugin allowing you to extract resources from an artifact using include/exclude filters to a specific
location. As David Jencks already pointed out earlier, this now might also be possible to do with the latest (alpha-5) dependency plugin, but I haven't yet
tested it out. If that one works and is stable (I'm a bit hesitant here), it might be simpler to use it instead.
The above examples I gave above for possible jetspeed:resource and jetspeed:assembly or likewise plugins will be much easier to realize with extended versions
of our own plugin though...
As I tried to explain above, the (current) plugin by itself isn't going to be enough to solve all the cases you listed above, but by properly separating our
resources in selected sets so they can easily be extract separately, should bring us a lot closer to the solution.
---------------------------------------------------------------------
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] Getting started - status update
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 23, 2007, at 12:53 AM, Ate Douma wrote:
> Maybe you haven't yet added the new additional properties I
> described in my earlier mail?
> You do need to add those to your current activeProfile, for mysql:
>
> <org.apache.jetspeed.test.jdbc.driver.groupId>mysql</
> org.apache.jetspeed.test.jdbc.driver.groupId>
> <org.apache.jetspeed.test.jdbc.driver.artifactId>mysql-connector-
> java</org.apache.jetspeed.test.jdbc.driver.artifactId>
> <org.apache.jetspeed.test.jdbc.driver.version>5.0.4-bin</
> org.apache.jetspeed.test.jdbc.driver.version>
>
Right. Already got that from your original email instructions.
There were some typos in the cut and paste samples. I fixed that and
got this message on both counts:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 3 minutes 47 seconds
[INFO] Finished at: Thu Aug 23 08:29:58 PDT 2007
[INFO] Final Memory: 22M/48M
Excellent. A new Maven build. This is exciting to think the project
can finally move forward now. Thanks for making this happen.
So now Im wondering about a couple of things
These are not support questions, but just me thinking out loud so
excuse me if Im not as far into the thinking process about Maven
builds as you are
I am not really so much concerned with the intricacies of mavenology,
but more concerned with high level questions like:
* How can end users easily remove some (but not all) of the "demo"
decorators
* How can end users easily remove some (but not all) of the "demo" pages
* How can end users easily override the Spring configurations
* How can an end user have several builds, perhaps a production build
with full production level database, and then a developers build with
a Jetspeed Lite like configuration
* How to manage the jar dependencies in these different
configurations. I think that the Serializer showed us some of the
challenges
I think this somehow ties into the resource plugin that you wrote, so
maybe you can explain that one in a little detail to get us all up to
speed such as:
* why is Maven not good enough out of the box, why do we need a
custom plugin to manage simple things like resource configurations
(Im not trying to devalue Maven, just would like to understand)
* how does the resource plugin help to meet the needs of the five
cases listed about
---------------------------------------------------------------------
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] Getting started - status update
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Unable to build project 'jetspeed-2/pom.xml; it requires Maven
>> version 2.0.7
>>
> OK, I installed 2.0.7
Ugh, yes I should have mentioned that.
I was also discussed before:
http://www.nabble.com/Further-Jetspeed-2-development-plans-tf4087420.html#a11669880
>
> Try again:
>
> mvn -P test-setup
> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>
> Now I get:
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] A required plugin was not found: Plugin could not be found -
> check that the goal name is correct: Unable to download the artifact
> from any repository
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
> -DartifactId=jetspeed-maven-plugins \
> -Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin
> -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there: mvn deploy:deploy-file
> -DgroupId=org.apache.portals.jetspeed-2
> -DartifactId=jetspeed-maven-plugins \
> -Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin
> -Dfile=/path/to/file \
> -Durl=[url] -DrepositoryId=[id]
>
Jeez, yes I forgot you need to bootstrap the plugin once :(
If I find the time I'll try writing a more complete "getting started" later today...
>
> So I wasn't sure what to do next, and tried:
>
> $ cd maven/jetspeed-maven-plugins/
> $ mvn install
>
> (man that command must have downloaded an army of jar files)
> tried again:
>
> mvn -P test-setup
> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>
> and then I get:
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> GroupId: org.apache.portals.jetspeed-2
> ArtifactId: jetspeed-portal-resources
> Version: 2.2-SNAPSHOT
>
> Reason: Unable to download the artifact from any repository
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
> -DartifactId=jetspeed-portal-resources \
> -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there: mvn deploy:deploy-file
> -DgroupId=org.apache.portals.jetspeed-2
> -DartifactId=jetspeed-portal-resources \
> -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \
> -Durl=[url] -DrepositoryId=[id]
>
> org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar:2.2-SNAPSHOT
>
>
> So I tried building the portal resources, but that didn't work either
> So then I tried going to the jetspeed root directory
>
> $ mvn install
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
>
>
> back to your instructions:
>
> mvn -P test-setup
> org.apache.portals.jetspeed-2:jetspeed-maven-plugins:init-db
>
> and it got further, it didn't find my jdbc driver:
>
> ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Driver class not found: com.mysql.jdbc.Driver
>
> The properties are set in my settings.xml to the best of my abilities.
> However, I think that it fails because the the format of the
> settings.xml changed, and I need to convert over to your new sample
> settings.xml
> I have this kind of thing in there:
>
> <activeProfile>jetspeed-db-drivers-path</activeProfile>
>
> But now there is some new format like:
>
> <profile>
> <id>jetspeed-mysql</id>
>
It should not be because of that.
Maybe you haven't yet added the new additional properties I described in my earlier mail?
You do need to add those to your current activeProfile, for mysql:
<org.apache.jetspeed.test.jdbc.driver.groupId>mysql</org.apache.jetspeed.test.jdbc.driver.groupId>
<org.apache.jetspeed.test.jdbc.driver.artifactId>mysql-connector-java</org.apache.jetspeed.test.jdbc.driver.artifactId>
<org.apache.jetspeed.test.jdbc.driver.version>5.0.4-bin</org.apache.jetspeed.test.jdbc.driver.version>
> I will try to switch to that format next....
> Is this property required?:
>
>
> <org.apache.jetspeed.test.jdbc.drivers.path>${org.apache.jetspeed.server.home}/shared/lib/mysql-connector-java-5.0.4-bin.jar</org.apache.jetspeed.test.jdbc.drivers.path>
No, its not used anymore with the new build, but you better keep it for now as you still need it if you want to build < 2.2-SNAPSHOT (e.g. 2.1.3-dev) using m2.
---------------------------------------------------------------------
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] Getting started - status update
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 23, 2007, at 12:03 AM, David Sean Taylor wrote:
>
> On Aug 21, 2007, at 7:40 PM, Ate Douma wrote:
>
>> The trunk is now (partly) buildable *and* testable again!
>>
>> You need to update you the local m2 settings.xml with the
>> following required properties for your selected database (I've
>> updated settings.xml.sample with example values):
>>
>> <org.apache.jetspeed.test.jdbc.driver.groupId>SETGROUPID</
>> org.apache.jetspeed.test.jdbc.driver.groupId>
>>
>> <org.apache.jetspeed.test.jdbc.driver.artifactId>SETARTIFACTID</
>> org.apache.jetspeed.test.jdbc.driver.artifactId>
>> <org.apache.jetspeed.test.jdbc.driver.version>SETVERSION</
>> org.apache.jetspeed.test.jdbc.driver.version>
>>
>> <org.apache.jetspeed.production.jdbc.driver.groupId>SETGROUPID</
>> org.apache.jetspeed.test.jdbc.driver.groupId>
>>
>> <org.apache.jetspeed.production.jdbc.driver.artifactId>SETARTIFACTID<
>> /org.apache.jetspeed.test.jdbc.driver.artifactId>
>>
>> <org.apache.jetspeed.production.jdbc.driver.version>SETVERSION</
>> org.apache.jetspeed.test.jdbc.driver.version>
>>
>> Then create a new portal test database schema:
>> $ mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-
>> plugins:init-db
>>
>
> [ERROR] BUILD FAILURE
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Unable to build project 'jetspeed-2/pom.xml; it requires
> Maven version 2.0.7
>
OK, I installed 2.0.7
Try again:
mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-
plugins:init-db
Now I get:
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] A required plugin was not found: Plugin could not be found -
check that the goal name is correct: Unable to download the artifact
from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
-DartifactId=jetspeed-maven-plugins \
-Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/
to/file
Alternatively, if you host your own repository you can deploy the
file there: mvn deploy:deploy-file -
DgroupId=org.apache.portals.jetspeed-2 -DartifactId=jetspeed-maven-
plugins \
-Dversion=2.2-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/
to/file \
-Durl=[url] -DrepositoryId=[id]
So I wasn't sure what to do next, and tried:
$ cd maven/jetspeed-maven-plugins/
$ mvn install
(man that command must have downloaded an army of jar files)
tried again:
mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-
plugins:init-db
and then I get:
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
GroupId: org.apache.portals.jetspeed-2
ArtifactId: jetspeed-portal-resources
Version: 2.2-SNAPSHOT
Reason: Unable to download the artifact from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.portals.jetspeed-2
-DartifactId=jetspeed-portal-resources \
-Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the
file there: mvn deploy:deploy-file -
DgroupId=org.apache.portals.jetspeed-2 -DartifactId=jetspeed-portal-
resources \
-Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
org.apache.portals.jetspeed-2:jetspeed-portal-resources:jar:2.2-
SNAPSHOT
So I tried building the portal resources, but that didn't work either
So then I tried going to the jetspeed root directory
$ mvn install
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
------------------------------------------------------------------------
back to your instructions:
mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-
plugins:init-db
and it got further, it didn't find my jdbc driver:
ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Driver class not found: com.mysql.jdbc.Driver
The properties are set in my settings.xml to the best of my abilities.
However, I think that it fails because the the format of the
settings.xml changed, and I need to convert over to your new sample
settings.xml
I have this kind of thing in there:
<activeProfile>jetspeed-db-drivers-path</activeProfile>
But now there is some new format like:
<profile>
<id>jetspeed-mysql</id>
I will try to switch to that format next....
Is this property required?:
<org.apache.jetspeed.test.jdbc.drivers.path>$
{org.apache.jetspeed.server.home}/shared/lib/mysql-connector-
java-5.0.4-bin.jar</org.apache.jetspeed.test.jdbc.drivers.path>
Re: [M2 build design] Getting started - status update
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 21, 2007, at 7:40 PM, Ate Douma wrote:
> The trunk is now (partly) buildable *and* testable again!
>
> You need to update you the local m2 settings.xml with the following
> required properties for your selected database (I've updated
> settings.xml.sample with example values):
>
> <org.apache.jetspeed.test.jdbc.driver.groupId>SETGROUPID</
> org.apache.jetspeed.test.jdbc.driver.groupId>
> <org.apache.jetspeed.test.jdbc.driver.artifactId>SETARTIFACTID</
> org.apache.jetspeed.test.jdbc.driver.artifactId>
> <org.apache.jetspeed.test.jdbc.driver.version>SETVERSION</
> org.apache.jetspeed.test.jdbc.driver.version>
> <org.apache.jetspeed.production.jdbc.driver.groupId>SETGROUPID</
> org.apache.jetspeed.test.jdbc.driver.groupId>
>
> <org.apache.jetspeed.production.jdbc.driver.artifactId>SETARTIFACTID</
> org.apache.jetspeed.test.jdbc.driver.artifactId>
> <org.apache.jetspeed.production.jdbc.driver.version>SETVERSION</
> org.apache.jetspeed.test.jdbc.driver.version>
>
> Then create a new portal test database schema:
> $ mvn -P test-setup org.apache.portals.jetspeed-2:jetspeed-maven-
> plugins:init-db
>
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Unable to build project 'jetspeed-2/pom.xml; it requires Maven
version 2.0.7
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org