El mar, 27-09-2005 a las 20:33 +0800, James Liao escribió: > I work for a company who ships j2 as its portal implementation. I make a > continue building every time j2 update, once I find problem, I will report > to j2 dev team. Hope it is helpful. >
It is. Cool to have some sort of automated build system warning us. > - James Liao > > On 9/27/05, Santiago Gala <[EMAIL PROTECTED]> wrote: > > > > El mar, 27-09-2005 a las 16:32 +0800, James Liao escribió: > > > Hi, > > > Now the problem comes to myfaces-1.1.0.jar. > > > I did find a directory like " > > > http://www.ibiblio.org/maven/myfaces/jars/myfaces-1.1.0/";, but there is > > not > > > myfaces-1.1.0.jar. > > > > > > The SVN head remain broken. > > > > > > > Sorry a lot. I have mixed changes (for updating pluto dependency to > > 1.0.1 when they finally release it) and I missed some commits. This got > > complicated by the fact that the id in pluto changes from pluto to > > org.apache.pluto (as recommended), so I should not do this change until > > the end. I'm building from a clean repositoy and committing the changed > > project.xml files to ensure this is fixed. > > > > The global thing I'm doing is finishing the restructuring of portals > > bridges. To this aim: > > > > - applications/struts-demo will move to somewhere in > > portals-bridges/struts/ > > - applications/jpetstore will move to somewhere in the struts bridge > > too, as a separate war > > - applications/jsf-demo and applications/jsf-demo-myfaces will be joined > > into a single jar (little difference between those two) and moved to > > portals-bridges/jsf/ > > - applications/perl will move to portals-bridges/perl > > - applications/php will move to portals/bridges/php > > > > After this I will propose a formal (not SNAPSHOT) release in bridges > > that will make more stable dependencies for J2-2.0-M4, as the demos will > > be imported as built wars, and decoupled from the portal itself. > > > > security, pam and palm will remain in jetspeed, as they are the > > administration portlets. David suggested to put together pam and palm. > > > +1 > I wanted also to split the pam page into two, one with the Portlet Application Manager proper, and the other with the Portlet Entity Manager. This will make them more usable as a whole, as page space is short with two columns. > > This will leave only the gems applications and demo.war remaining, for > > further restructuring and clean up preparing the M4 (and then 2.0) > > release. > > > > Other missing (implicit) dependency that we should aim to break is that > > the .psml pages are referencing those demos. For this I think we need a > > way for a portlet war to specify a pages area, and for the deployment > > tool to "mount" this pages area in a specific place in the sitemap for > > the portal. The idea here is that, if a portal does *not* contain the > > faces demos, no broken faces page will appear. Ditto for php, perl, > > python, struts, jpetstore, whatever. > > > > Ideas on specifying or implementing this? Let's say that a portlet can contain jetspeed specific data (it contains metadata already). The jetspeed-portlet.xml or other similar file could point to a directory containing pages (.psml, .link, folder.metadata) The deployer could, as part of the process, copy (or refer to) those pages in the sitemap, starting at a configurable mount point. Say, pam contains a pointer to /WEB-INF/pages/, and that there is a directory called Administrative there, containing a pam.psml, a palm.psml and a pem.psml files, which point to the portlets. I'd make those pages *not* shadow pages with the same name in the site map (but emit a warning for the admin or rename them as <original>-N.psml, and probably merge directories, using folder.metadata from the original one in the sitemap. This is due to security. I would keep the "mount point" as "/" in jetspeed, which means pages moved to the different .war would end up in the same place as they are now. This is not perfect, specially as two different .war containing directories with the same name would install folder.metadata and common pages differently depending on deployment sequence, which violates the "least surprise" principle. Also, the system would have to deal gracefully with not-present layout, so that a page expecting a certain layout will not fail to render. But I can't suggest something better because I don't know well the page manager. Any ideas from those who know? I know David had a lot of ideas on how to organize the site management, and Randy is integrating latest Graffito with J2-HEAD, so we should at least have them telling something about the issue. I read something about layouts being deployable as wars, so the process could also take layouts from the .war, but this looks overly complex and would probably break a lot more things, including the look and feel of the portal as a whole. Not to mention that pages, while used in the portal context, are not executable per se, but deploying a layout would give portal permissions to portal-external code. > > > > This makes sense because all demos are, in principle, runnable in any > > JSR-168 portal (most of the just depend on generic bridges stuff and the > > respective framework/bridge). It will bring the additional benefit of > > reducing the build time in J2 a lot (6 less projects to build, and > > stable dependency points means less wait in online builds) > > > This is great! > > We were discussing yesterday too that a very interesting possibility for > > documentation is that the demo wars carry html documentation (via xdoc > > in their build) *both* for the bridges site and inside the war, so that > > people looking around knows what is going on in the different demos. > > > > I'm still figuring out the concrete places to put the builds in > > portals-bridges, and how to add them to the main jetspeed build. I'm no > > maven expert (I actually hate a lot of things it does, and never voted > > to use it, in fact my vote was, back then, contingent to keep a working > > ant build, which never happened), but someone needs to do this un-sexy > > tasks if we want to have a reasonable environment for programmers to > > build/modify jetspeed. > > > > I also added variables to keep a global log4j.version and log4j.include > > (it was missing in some directories), and the same for struts.(version| > > include) and commons.logging.(version|include), so that it is easier to > > keep track of versions. > > > > I bumped the release of jsf due to a classloading bug there that was > > causing problems, then I discovered that 1.1.0 has changed the names of > > the artifacts, and it has also a similar problem which requires using > > the separate parts (-api, -impl and tomahawk.jar) instead of the global > > myfaces-all-1.1.0.jar. Solving this is causing some (hopefully > > transient) trouble. > > > > What do you (all) think? > > > > > -James Liao > > > > > > On 9/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > Author: sgala > > > > Date: Tue Sep 27 00:47:14 2005 > > > > New Revision: 291845 > > > > > > > > URL: http://svn.apache.org/viewcvs?rev=291845&view=rev > > > > Log: > > > > fix name change in myfaces, from myfaces-jsf-api to myfaces-api > > > > > > > > Modified: > > > > portals/jetspeed-2/trunk/applications/jsf-demo-myfaces/project.xml > > > > portals/jetspeed-2/trunk/applications/jsf-demo/project.xml > > > > > > > > Modified: > > > > portals/jetspeed-2/trunk/applications/jsf-demo-myfaces/project.xml > > > > URL: > > > > > > http://svn.apache.org/viewcvs/portals/jetspeed-2/trunk/applications/jsf-demo-myfaces/project.xml?rev=291845&r1=291844&r2=291845&view=diff > > > > > > > > > > ============================================================================== > > > > --- portals/jetspeed-2/trunk/applications/jsf-demo-myfaces/project.xml > > > > (original) > > > > +++ portals/jetspeed-2/trunk/applications/jsf-demo-myfaces/project.xml > > Tue > > > > Sep 27 00:47:14 2005 > > > > @@ -99,7 +99,7 @@ > > > > </properties> > > > > </dependency> > > > > <dependency> > > > > - <id>myfaces:myfaces-jsf-api</id> > > > > + <id>myfaces:myfaces-api</id> > > > > <version>${myfaces.version}</version> > > > > <properties> > > > > <war.bundle>true</war.bundle> > > > > > > > > Modified: portals/jetspeed-2/trunk/applications/jsf-demo/project.xml > > > > URL: > > > > > > http://svn.apache.org/viewcvs/portals/jetspeed-2/trunk/applications/jsf-demo/project.xml?rev=291845&r1=291844&r2=291845&view=diff > > > > > > > > > > ============================================================================== > > > > --- portals/jetspeed-2/trunk/applications/jsf-demo/project.xml > > (original) > > > > +++ portals/jetspeed-2/trunk/applications/jsf-demo/project.xml Tue Sep > > 27 > > > > 00:47:14 2005 > > > > @@ -91,7 +91,7 @@ > > > > </dependency> > > > > > > > > <dependency> > > > > - <id>myfaces:myfaces-jsf-api</id> > > > > + <id>myfaces:myfaces-api</id> > > > > <version>${myfaces.version}</version> > > > > <properties> > > > > <war.bundle>true</war.bundle> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -- > > VP and Chair, Apache Portals (http://portals.apache.org) > > Apache Software Foundation > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.2 (GNU/Linux) > > > > iD8DBQBDOSC0ZAeG2a2/nhoRAsh4AJ4gHXmuAJG0GW1pXJTaWCJZz4wA5gCghWRE > > 6GrUen4czSOU93fjXThXA1M= > > =w6f3 > > -----END PGP SIGNATURE----- > > > > > > -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation
signature.asc
Description: This is a digitally signed message part
