You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2006/12/05 15:19:18 UTC
JAXB and Java 5 (was Re: [Fwd: Admin Portlet])
Great point about java5 Craig. . .I hadn't thought of that.
I'm hesitant to force java5 for 1.1.x since it's focus is 168.
Why don't we do this:
1) Drive the release of 1.1.0 to GA and not allow the persistence of
page configuration. (I think we're very close if we don't add new features).
2) Maintain bug fixes for this in the 1.1.x series
3) As soon as the release is through, move the trunk to 1.2.x. In this
version we will upgrade to Java5/JAXB and start working on more robust
admin portlets.
4) Down the road. . .we will consider the 286 branch as 2.0.
Thoughts?
David
CDoremus@hannaford.com wrote:
> See below
>
> >To: pluto-dev@portals.apache.org, Oliver Spindler
> ><ol...@minet.uni-jena.de>
> >From: "David H. DeWolf" <dd...@apache.org>
> >Sent by: "David H. DeWolf" <dd...@gmail.com>
> >Date: 12/04/2006 09:04PM
> >Subject: [Fwd: Admin Portlet]
> >
> >Hi Oliver,
> >
> >I'm forwarding this to the pluto-dev list. All of these discussions
> >
> >need to take place there. I'll respond onlist.
> >
> >Thanks,
> >
> >
> >David
> >
> >-------- Original Message --------
> >Subject: Admin Portlet
> >Date: Tue, 05 Dec 2006 03:10:29 +0100
> >From: Oliver Spindler <ol...@minet.uni-jena.de>
> >To: David H. DeWolf <dd...@apache.org>
> >References:
> >
> >com>
> ><45...@apache.org>
> >
> >Hi David
> >
> >As Torsten told you, I'm working on the admin-portlet.
> >At the moment I'm still working on the software-design.
> >I think it would be the best to split the Admin-Portlet into two
> >separate ones.
> >The first for deploying portlets and the second one for editing the
> >portal pages.
> >Then the second portlet is independent from the servlet container
> >(like
> >Tomcat).
> >The main problem is, that you cannot save the configuration of a
> >running
> >pluto-instance.
> >I think it is necessary to implement something to save the current
> >configuration.
> >Maybe we can use a XML-mapper like JAXB or something else instead of
> >Digester.
>
> Yes, we need a page configuration file, which is a modified version of
> pluto-portal-driver-config.xml. I'm all for moving this to JAXB 2, since
> we need it for JSR-286. But we need to keep in mind that JSXB 2 requires
> Java 5, so we need to make it clear to our users that Java 5 will be
> required for Pluto 1.1 if we use JAXB 2. Again, this is something we
> need to do for JSR-286.
>
> >The next problem is the portlet-assembler. I think we need a better
> >one,
> >which provides
> >a good result in all cases. For example if you use him twice.
> >
> >This is my idea for the Deployer-Portlet:
> >for deploying:
> > 1. the user selects an .war file
> > 2. upload the .war file to a temp-dir
> > 3. the portlet-assembler checks the .war file and inject pluto
> >specific things
> > 4. we can use existing features of the servlet container to
> >deploy
> >the .war to the servlet-container
> I have already created code to do these steps. They have been checked
> into a sandbox branch called 1.1-ADMIN-CRAIG. The code I added is in the
> pluto-util and pluto-portal-driver modules. This code needs to be cherry
> picked to make it compatible with David's recent commits on page
> configuration. Also, much of the the pluto-util code needs to be moved
> into pluto-portal-driver or pluto-portal-driver-impl.
>
> As I stated before, we also need to strive to reuse deployment code
> between the ant, maven and admin portlets.
>
> > 5. register the portlet application in pluto (persistent)
> > optional:
> > 6. select/create a page for the new portlets
> >The portlet should also be able to re-/undeploy a portlet
> >application.
> >I have implemented an wrapper class for the Tomcat-Manager servlet
> >(see http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html) and
> >I
> >think it would be
> >the best way to deploy the .war file to Tomcat. The problem here is
> >the
> >authentication for the
> >tomcat-manager servlet (username/password) when using HttpClient for
> >the
> >connection.
> >I can send you the sources, if you are interested in.
> >Another problem is the context.xml file. I think we should create one
> >in
> >the META-INF directory
> >or check it if it exists.
> >Maybe we could also provide a servlet for deploying portlets like
> >the
> >Tomcat-Manager servlet
> >(not the html part) for using with maven and ant.
> >
> >This is my idea for the page-manager portlet:
> > 1. list of all known portlets
> > 2. create new pages
> > 3. edit/remove existing pages
> > 4. put and arrange any portlet on a page
> > 5. save the configuration
> > optional:
> > 6. create own themes for the portal pages
> >
> As David has said, he has have solved #1-4. Step 5 still needs to be
> done, while 6 should be out-of-scope for now.
>
>
> >I think we should also create a new directory (f.e:
> >pluto-portla-admin)
> >for the administration portlets/servlets/utilities.
> >The pluto-driver directory should only contain some interfaces for
> >the
> >pluto-specfic administration tasks,
> >like register portlets, save configuration and so on.
> >
>
> We need to keep the generic code/interfaces with the portal code in
> pluto-portal-driver and the Tomcat-specific stuff in
> pluto-portal-driver-impl. Like David said, Pluto administration code
> needs to stay close to the driver code.
>
>
> >What do you think about that all?
> >
> >Off-topic:
> >I have still problems redeploying Pluto, when Tomcat is running. I
> >think
> >we should also use the Tomcat-Manager-Servlet
> >for deploying/undeploying Pluto if Tomcat is running.
> >
> >
> >
> >Best regards
> >
> >Oliver
Re: JAXB and Java 5 (was Re: [Fwd: Admin Portlet])
Posted by "David H. DeWolf" <dd...@apache.org>.
good points, yes, we should
David
Elliot Metsger wrote:
> David H. DeWolf wrote:
>> Great point about java5 Craig. . .I hadn't thought of that.
>>
>> I'm hesitant to force java5 for 1.1.x since it's focus is 168.
>
>
> New dependencies (Junit 4, EasyMock) require Java 5 -
>
> esm ~/eclipse-workspace/PlutoASFTrunk $ java -version
> java version "1.4.2_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-233)
> Java HotSpot(TM) Client VM (build 1.4.2-56, mixed mode)
> esm ~/eclipse-workspace/PlutoASFTrunk $ mvn clean install
> <...>
> bad class file:
> /Users/esm/.m2/repository/junit/junit/4.0/junit-4.0.jar(junit/framework/TestCase.class)
>
> class file has wrong version 49.0, should be 48.0
> <...>
>
> Backing up to JUnit 3.8 and building produces:
> <...>
> /Users/esm/eclipse-workspace/PlutoASFTrunk/pluto-container/src/test/java/org/apache/pluto/core/PortletContextManagerTest.java:[7,-1]
> cannot access org.easymock.EasyMock
> bad class file:
> /Users/esm/.m2/repository/org/easymock/easymock/2.2/easymock-2.2.jar(org/easymock/EasyMock.class)
>
> class file has wrong version 49.0, should be 48.0
> <...>
>
> I wonder if we could use an earlier version of easymock and junit?
>
>
>> Why don't we do this:
>>
>> 1) Drive the release of 1.1.0 to GA and not allow the persistence of
>> page configuration. (I think we're very close if we don't add new
>> features).
>
> +1
>
>
>> 2) Maintain bug fixes for this in the 1.1.x series
>
> Sounds good! Just need to document to the user that Java5-based 1.2.x
> features won't be backported to the 1.1.x branches.
>
>> 3) As soon as the release is through, move the trunk to 1.2.x. In
>> this version we will upgrade to Java5/JAXB and start working on more
>> robust admin portlets.
>
> +1
>
>> 4) Down the road. . .we will consider the 286 branch as 2.0.
>
>
>>
>> Thoughts?
>>
>
> Sounds like a good strategy.
>
>
>>
>> David
>>
>> CDoremus@hannaford.com wrote:
>>> See below
>>>
>>> >To: pluto-dev@portals.apache.org, Oliver Spindler
>>> ><ol...@minet.uni-jena.de>
>>> >From: "David H. DeWolf" <dd...@apache.org>
>>> >Sent by: "David H. DeWolf" <dd...@gmail.com>
>>> >Date: 12/04/2006 09:04PM
>>> >Subject: [Fwd: Admin Portlet]
>>> >
>>> >Hi Oliver,
>>> >
>>> >I'm forwarding this to the pluto-dev list. All of these discussions
>>> >
>>> >need to take place there. I'll respond onlist.
>>> >
>>> >Thanks,
>>> >
>>> >
>>> >David
>>> >
>>> >-------- Original Message --------
>>> >Subject: Admin Portlet
>>> >Date: Tue, 05 Dec 2006 03:10:29 +0100
>>> >From: Oliver Spindler <ol...@minet.uni-jena.de>
>>> >To: David H. DeWolf <dd...@apache.org>
>>> >References: >
>>> >com> ><45...@apache.org>
>>> >
>>> >Hi David
>>> >
>>> >As Torsten told you, I'm working on the admin-portlet.
>>> >At the moment I'm still working on the software-design.
>>> >I think it would be the best to split the Admin-Portlet into two
>>> >separate ones.
>>> >The first for deploying portlets and the second one for editing the
>>> >portal pages.
>>> >Then the second portlet is independent from the servlet container
>>> >(like
>>> >Tomcat).
>>> >The main problem is, that you cannot save the configuration of a
>>> >running
>>> >pluto-instance.
>>> >I think it is necessary to implement something to save the current
>>> >configuration.
>>> >Maybe we can use a XML-mapper like JAXB or something else instead of
>>> >Digester.
>>>
>>> Yes, we need a page configuration file, which is a modified version
>>> of pluto-portal-driver-config.xml. I'm all for moving this to JAXB 2,
>>> since we need it for JSR-286. But we need to keep in mind that JSXB 2
>>> requires Java 5, so we need to make it clear to our users that Java 5
>>> will be required for Pluto 1.1 if we use JAXB 2. Again, this is
>>> something we need to do for JSR-286.
>>>
>>> >The next problem is the portlet-assembler. I think we need a better
>>> >one,
>>> >which provides
>>> >a good result in all cases. For example if you use him twice.
>>> >
>>> >This is my idea for the Deployer-Portlet:
>>> >for deploying:
>>> > 1. the user selects an .war file
>>> > 2. upload the .war file to a temp-dir
>>> > 3. the portlet-assembler checks the .war file and inject pluto
>>> >specific things
>>> > 4. we can use existing features of the servlet container to
>>> >deploy
>>> >the .war to the servlet-container
>>> I have already created code to do these steps. They have been checked
>>> into a sandbox branch called 1.1-ADMIN-CRAIG. The code I added is in
>>> the pluto-util and pluto-portal-driver modules. This code needs to be
>>> cherry picked to make it compatible with David's recent commits on
>>> page configuration. Also, much of the the pluto-util code needs to be
>>> moved into pluto-portal-driver or pluto-portal-driver-impl.
>>>
>>> As I stated before, we also need to strive to reuse deployment code
>>> between the ant, maven and admin portlets.
>>>
>>> > 5. register the portlet application in pluto (persistent)
>>> > optional:
>>> > 6. select/create a page for the new portlets
>>> >The portlet should also be able to re-/undeploy a portlet
>>> >application.
>>> >I have implemented an wrapper class for the Tomcat-Manager servlet
>>> >(see http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html) and
>>> >I
>>> >think it would be
>>> >the best way to deploy the .war file to Tomcat. The problem here is
>>> >the
>>> >authentication for the
>>> >tomcat-manager servlet (username/password) when using HttpClient for
>>> >the
>>> >connection.
>>> >I can send you the sources, if you are interested in.
>>> >Another problem is the context.xml file. I think we should create one
>>> >in
>>> >the META-INF directory
>>> >or check it if it exists.
>>> >Maybe we could also provide a servlet for deploying portlets like
>>> >the
>>> >Tomcat-Manager servlet
>>> >(not the html part) for using with maven and ant.
>>> >
>>> >This is my idea for the page-manager portlet:
>>> > 1. list of all known portlets
>>> > 2. create new pages
>>> > 3. edit/remove existing pages
>>> > 4. put and arrange any portlet on a page
>>> > 5. save the configuration
>>> > optional:
>>> > 6. create own themes for the portal pages
>>> >
>>> As David has said, he has have solved #1-4. Step 5 still needs to be
>>> done, while 6 should be out-of-scope for now.
>>>
>>>
>>> >I think we should also create a new directory (f.e:
>>> >pluto-portla-admin)
>>> >for the administration portlets/servlets/utilities.
>>> >The pluto-driver directory should only contain some interfaces for
>>> >the
>>> >pluto-specfic administration tasks,
>>> >like register portlets, save configuration and so on.
>>> >
>>>
>>> We need to keep the generic code/interfaces with the portal code in
>>> pluto-portal-driver and the Tomcat-specific stuff in
>>> pluto-portal-driver-impl. Like David said, Pluto administration code
>>> needs to stay close to the driver code.
>>>
>>>
>>> >What do you think about that all?
>>> >
>>> >Off-topic:
>>> >I have still problems redeploying Pluto, when Tomcat is running. I
>>> >think
>>> >we should also use the Tomcat-Manager-Servlet
>>> >for deploying/undeploying Pluto if Tomcat is running.
>>> >
>>> >
>>> >
>>> >Best regards
>>> >
>>> >Oliver
>
>
Re: JAXB and Java 5 (was Re: [Fwd: Admin Portlet])
Posted by Elliot Metsger <em...@jhu.edu>.
David H. DeWolf wrote:
> Great point about java5 Craig. . .I hadn't thought of that.
>
> I'm hesitant to force java5 for 1.1.x since it's focus is 168.
New dependencies (Junit 4, EasyMock) require Java 5 -
esm ~/eclipse-workspace/PlutoASFTrunk $ java -version
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-233)
Java HotSpot(TM) Client VM (build 1.4.2-56, mixed mode)
esm ~/eclipse-workspace/PlutoASFTrunk $ mvn clean install
<...>
bad class file:
/Users/esm/.m2/repository/junit/junit/4.0/junit-4.0.jar(junit/framework/TestCase.class)
class file has wrong version 49.0, should be 48.0
<...>
Backing up to JUnit 3.8 and building produces:
<...>
/Users/esm/eclipse-workspace/PlutoASFTrunk/pluto-container/src/test/java/org/apache/pluto/core/PortletContextManagerTest.java:[7,-1]
cannot access org.easymock.EasyMock
bad class file:
/Users/esm/.m2/repository/org/easymock/easymock/2.2/easymock-2.2.jar(org/easymock/EasyMock.class)
class file has wrong version 49.0, should be 48.0
<...>
I wonder if we could use an earlier version of easymock and junit?
> Why don't we do this:
>
> 1) Drive the release of 1.1.0 to GA and not allow the persistence of
> page configuration. (I think we're very close if we don't add new
> features).
+1
> 2) Maintain bug fixes for this in the 1.1.x series
Sounds good! Just need to document to the user that Java5-based 1.2.x
features won't be backported to the 1.1.x branches.
> 3) As soon as the release is through, move the trunk to 1.2.x. In this
> version we will upgrade to Java5/JAXB and start working on more robust
> admin portlets.
+1
> 4) Down the road. . .we will consider the 286 branch as 2.0.
>
> Thoughts?
>
Sounds like a good strategy.
>
> David
>
> CDoremus@hannaford.com wrote:
>> See below
>>
>> >To: pluto-dev@portals.apache.org, Oliver Spindler
>> ><ol...@minet.uni-jena.de>
>> >From: "David H. DeWolf" <dd...@apache.org>
>> >Sent by: "David H. DeWolf" <dd...@gmail.com>
>> >Date: 12/04/2006 09:04PM
>> >Subject: [Fwd: Admin Portlet]
>> >
>> >Hi Oliver,
>> >
>> >I'm forwarding this to the pluto-dev list. All of these discussions
>> >
>> >need to take place there. I'll respond onlist.
>> >
>> >Thanks,
>> >
>> >
>> >David
>> >
>> >-------- Original Message --------
>> >Subject: Admin Portlet
>> >Date: Tue, 05 Dec 2006 03:10:29 +0100
>> >From: Oliver Spindler <ol...@minet.uni-jena.de>
>> >To: David H. DeWolf <dd...@apache.org>
>> >References: >
>> >com> ><45...@apache.org>
>> >
>> >Hi David
>> >
>> >As Torsten told you, I'm working on the admin-portlet.
>> >At the moment I'm still working on the software-design.
>> >I think it would be the best to split the Admin-Portlet into two
>> >separate ones.
>> >The first for deploying portlets and the second one for editing the
>> >portal pages.
>> >Then the second portlet is independent from the servlet container
>> >(like
>> >Tomcat).
>> >The main problem is, that you cannot save the configuration of a
>> >running
>> >pluto-instance.
>> >I think it is necessary to implement something to save the current
>> >configuration.
>> >Maybe we can use a XML-mapper like JAXB or something else instead of
>> >Digester.
>>
>> Yes, we need a page configuration file, which is a modified version of
>> pluto-portal-driver-config.xml. I'm all for moving this to JAXB 2,
>> since we need it for JSR-286. But we need to keep in mind that JSXB 2
>> requires Java 5, so we need to make it clear to our users that Java 5
>> will be required for Pluto 1.1 if we use JAXB 2. Again, this is
>> something we need to do for JSR-286.
>>
>> >The next problem is the portlet-assembler. I think we need a better
>> >one,
>> >which provides
>> >a good result in all cases. For example if you use him twice.
>> >
>> >This is my idea for the Deployer-Portlet:
>> >for deploying:
>> > 1. the user selects an .war file
>> > 2. upload the .war file to a temp-dir
>> > 3. the portlet-assembler checks the .war file and inject pluto
>> >specific things
>> > 4. we can use existing features of the servlet container to
>> >deploy
>> >the .war to the servlet-container
>> I have already created code to do these steps. They have been checked
>> into a sandbox branch called 1.1-ADMIN-CRAIG. The code I added is in
>> the pluto-util and pluto-portal-driver modules. This code needs to be
>> cherry picked to make it compatible with David's recent commits on
>> page configuration. Also, much of the the pluto-util code needs to be
>> moved into pluto-portal-driver or pluto-portal-driver-impl.
>>
>> As I stated before, we also need to strive to reuse deployment code
>> between the ant, maven and admin portlets.
>>
>> > 5. register the portlet application in pluto (persistent)
>> > optional:
>> > 6. select/create a page for the new portlets
>> >The portlet should also be able to re-/undeploy a portlet
>> >application.
>> >I have implemented an wrapper class for the Tomcat-Manager servlet
>> >(see http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html) and
>> >I
>> >think it would be
>> >the best way to deploy the .war file to Tomcat. The problem here is
>> >the
>> >authentication for the
>> >tomcat-manager servlet (username/password) when using HttpClient for
>> >the
>> >connection.
>> >I can send you the sources, if you are interested in.
>> >Another problem is the context.xml file. I think we should create one
>> >in
>> >the META-INF directory
>> >or check it if it exists.
>> >Maybe we could also provide a servlet for deploying portlets like
>> >the
>> >Tomcat-Manager servlet
>> >(not the html part) for using with maven and ant.
>> >
>> >This is my idea for the page-manager portlet:
>> > 1. list of all known portlets
>> > 2. create new pages
>> > 3. edit/remove existing pages
>> > 4. put and arrange any portlet on a page
>> > 5. save the configuration
>> > optional:
>> > 6. create own themes for the portal pages
>> >
>> As David has said, he has have solved #1-4. Step 5 still needs to be
>> done, while 6 should be out-of-scope for now.
>>
>>
>> >I think we should also create a new directory (f.e:
>> >pluto-portla-admin)
>> >for the administration portlets/servlets/utilities.
>> >The pluto-driver directory should only contain some interfaces for
>> >the
>> >pluto-specfic administration tasks,
>> >like register portlets, save configuration and so on.
>> >
>>
>> We need to keep the generic code/interfaces with the portal code in
>> pluto-portal-driver and the Tomcat-specific stuff in
>> pluto-portal-driver-impl. Like David said, Pluto administration code
>> needs to stay close to the driver code.
>>
>>
>> >What do you think about that all?
>> >
>> >Off-topic:
>> >I have still problems redeploying Pluto, when Tomcat is running. I
>> >think
>> >we should also use the Tomcat-Manager-Servlet
>> >for deploying/undeploying Pluto if Tomcat is running.
>> >
>> >
>> >
>> >Best regards
>> >
>> >Oliver