commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: [Hivemind] build hivemind in eclipse?
Date Sun, 07 Mar 2004 14:18:52 GMT
This is why we're going to get away from Maven. The exact version of Maven you have seems very
significant. All I can say is that I'm using 1.0-rc2-SNAPSHOT. Does that help? Maybe not.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://howardlewisship.com


> -----Original Message-----
> From: Geoff Longman [mailto:glongman@intelligentworks.com] 
> Sent: Saturday, March 06, 2004 11:27 PM
> To: commons-dev@jakarta.apache.org
> Subject: [Hivemind] build hivemind in eclipse?
> 
> 
> I got the missing MAVEN_REPO classpath variable errors so I 
> installed maven
> and ran
> 
> >maven full-site
> 
> and added the MAVEN_REPO classpath variable.
> 
> All the errors are gone except this one:
> 
> Error   Missing required library: 'C:Documents and
> Settings/Administrator/.maven/repository/jboss/jars/jboss-jmx-
> 3.0.6.jar'.
> 
> Although, the maven build did tank after a while with this:
> 
> +----------------------------------------
> | Generating site for  HiveMind Framework
> | Memory: 12M/13M
> +----------------------------------------
> 
> BUILD FAILED
> File...... file:/C:/Documents and
> Settings/Administrator/.maven/plugins/maven-multiproject-plugin-1.1/
> Element... maven:reactor
> Line...... 69
> Column.... 7
> Unable to obtain goal [site] -- file:/C:/Documents and
> Settings/Administrator/.maven/plugins/maven-site-plugin-1.3/:22:42:
> <attainGo
> al> Goal [xdoc:register-reports] has no action definition.
> Total time: 46 seconds
> Finished at: Sat Mar 06 22:47:33 EST 2004
> 
> What am I doing wrong? BTW I just pulled the latest code out 
> of CVS and got
> the same error.
> 
> Geoff
> 
> ----- Original Message -----
> From: "Geoff Longman" <glongman@intelligentworks.com>
> To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
> <commons-dev@jakarta.apache.org>
> Sent: Saturday, March 06, 2004 10:27 PM
> Subject: Re: [Hivemind] Tapestry/HttpSession service
> 
> 
> > Ahh, but we're trying to reduce our dependency on the 
> Visit. We have many
> > groups of pages, and each group needs to store a distinct 
> set of data. Our
> > visit class was becoming a mess.
> >
> > Plus, a session local service could also be useful outside 
> of Tapestry
> where
> > there is no Visit! No reason why a JSP couldn't use a session local
> service.
> >
> > Geoff
> >
> > ----- Original Message -----
> > From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> > To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
> > <commons-dev@jakarta.apache.org>
> > Sent: Saturday, March 06, 2004 10:14 PM
> > Subject: Re: [Hivemind] Tapestry/HttpSession service
> >
> >
> > > The way I see it, you simply need a regular service with
> > > ThreadLocalStorage. The servlet filter would set the visit in the
> > > ThreadLocalStorage for every request and the service 
> would simply get
> > > and set the data on the visit in the ThreadLocal. Would that work?
> > >
> > > -Harish
> > >
> > > Geoff Longman wrote:
> > >
> > > >Perhaps, I wish I had more time to read the Hivemind source.
> > > >
> > > >I might be getting this wrong but how about a Factory 
> that makes a
> > session
> > > >local instance of a service? Wait that can't be right. A
> > SessionLocalService
> > > >that pulls a service from a pool and hooks it up to the 
> session. The
> > > >existing servlet filter could be a model for a filter 
> that sets up the
> > > >SessionLocalService with the thread local session.
> > > >
> > > >The above ignores the need to restore/save a service's 
> session local
> > state
> > > >though.
> > > >
> > > >hmm, still thinking..
> > > >
> > > >Geoff
> > > >----- Original Message -----
> > > >From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> > > >To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
> > > ><commons-dev@jakarta.apache.org>
> > > >Sent: Saturday, March 06, 2004 9:54 PM
> > > >Subject: Re: [Hivemind] Tapestry/HttpSession service
> > > >
> > > >
> > > >
> > > >
> > > >>Ah, yes I did miss that part. Seems like you want a 
> wrapper service to
> > > >>the HttpSession like the Visit?
> > > >>
> > > >>Geoff Longman wrote:
> > > >>
> > > >>
> > > >>
> > > >>>I don't think ThreadLocalStorage is sufficient. 
> Perhaps this is too
> > > >>>
> > > >>>
> > > >specific
> > > >
> > > >
> > > >>>to Tapestry and is a topic for Tapestry 3.1 discussion.
> > > >>>
> > > >>>It all boils down to a service that not only is thread 
> local, but is
> > also
> > > >>>session local.
> > > >>>
> > > >>>Geoff
> > > >>>----- Original Message -----
> > > >>>From: "Harish Krishnaswamy" <hkrishnaswamy@comcast.net>
> > > >>>To: "Jakarta Commons Developers List"
> <commons-dev@jakarta.apache.org>
> > > >>>Cc: "Tapestry development" <tapestry-dev@jakarta.apache.org>
> > > >>>Sent: Saturday, March 06, 2004 9:28 PM
> > > >>>Subject: Re: [Hivemind] Tapestry/HttpSession service
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>Have you looked into the ThreadLocalStorage?
> > > >>>>
> > > >>>>-Harish
> > > >>>>
> > > >>>>Geoff Longman wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>The content of this message crosses boundaries so I'm cc'ing
> Tapestry
> > > >>>>>
> > > >>>>>
> > > >dev
> > > >
> > > >
> > > >>>>>too.
> > > >>>>>
> > > >>>>>I have a real problem in a Tapestry application and 
> I'm wondering
> if
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>another
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>'flavour' of Hivemind service approach would be applicable.
> > > >>>>>
> > > >>>>>We have a Tapestry app that has many hundreds of 
> pages. Different
> > > >>>>>
> > > >>>>>
> > > >groups
> > > >
> > > >
> > > >>>>>
> > > >>>>>
> > > >>>of
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>pages need to share different sets of information. 
> We have tried
> > using
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>the
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>Visit  to share data and have also tried explicity 
> passing things
> > > >>>>>
> > > >>>>>
> > > >between
> > > >
> > > >
> > > >>>>>pages but both methods are less than ideal..
> > > >>>>>
> > > >>>>>The visit approach ends up being like a big 
> hashtable. Explicity
> > > >>>>>
> > > >>>>>
> > > >passing
> > > >
> > > >
> > > >>>>>data via method calls leads to coupling between pages.
> > > >>>>>
> > > >>>>>What would be nice is a service that is not only 
> pooled, but is
> > > >>>>>
> > > >>>>>
> > > >peristent
> > > >
> > > >
> > > >>>>>
> > > >>>>>
> > > >>>in
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>the Tapestry way, i.e. the value of certain fields 
> in the service
> are
> > > >>>>>private to one user session.
> > > >>>>>
> > > >>>>>An example implementation could be a Wizard that 
> uses 5 pages to
> > build
> > > >>>>>
> > > >>>>>
> > > >a
> > > >
> > > >
> > > >>>>>
> > > >>>>>
> > > >>>new
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>customer record in a database.
> > > >>>>>
> > > >>>>>If the service I described was doable, each page 
> could access a
> > > >>>>>NewCustomerWizard service, read data from it and set 
> data in it.
> The
> > > >>>>>NewCustomerWizardService could minimally reply to 
> questions like:
> > > >>>>>
> > > >>>>>- Can the wizard finish?
> > > >>>>>- What's the next page to show?
> > > >>>>>- What's the previous page to show?
> > > >>>>>
> > > >>>>>Thus, the pages could interact individually with the 
> service and
> not
> > be
> > > >>>>>coupled to one another.
> > > >>>>>
> > > >>>>>In fact, a menu component could interrogate the
> > > >>>>>
> > > >>>>>
> > > >NewCustomerWizardService
> > > >
> > > >
> > > >>>>>also to get the first page to show in order to start 
> the Wizard.
> > Plus,
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>the
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>>service could keep track of all the pages used so 
> far and if the
> user
> > > >>>>>clicked 'Finish' or 'Cancel', the service could 
> respond with the
> list
> > > >>>>>
> > > >>>>>
> > > >of
> > > >
> > > >
> > > >>>>>seen pages for cleanup purposes (forgetPage()).
> > > >>>>>
> > > >>>>>Is this wishful thinking?
> > > >>>>>Cheers,
> > > >>>>>
> > > >>>>>Geoff
> > > >>>>>
> > > >>>>>Geoffrey Longman
> > > >>>>>Intelligent Works Inc.
> > > >>>>>
> > > >>>>>
> > >
> >>>>>---------------------------------------------------------
> ------------
> > > >>>>>To unsubscribe, e-mail: 
> commons-dev-unsubscribe@jakarta.apache.org
> > > >>>>>For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > >
> >>>>----------------------------------------------------------
> -----------
> > > >>>>To unsubscribe, e-mail: 
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > >>>>For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > 
> >>>-----------------------------------------------------------
> ----------
> > > >>>To unsubscribe, e-mail: 
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > >>>For additional commands, e-mail: 
> tapestry-dev-help@jakarta.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > 
> >>------------------------------------------------------------
> ---------
> > > >>To unsubscribe, e-mail: 
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > >>For additional commands, e-mail: 
> tapestry-dev-help@jakarta.apache.org
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > 
> >---------------------------------------------------------------------
> > > >To unsubscribe, e-mail: 
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > >For additional commands, e-mail: 
> tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > > >
> > >
> > > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> > >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message