Sounds like an interesting approach (but a little bit over my head) - I am very
interested to hear how it all turns out. Good luck!
RB
Twenty Years | One Mission | Accelerating Business Processes
Richard Berger
Action Technologies, Inc.
VP, Product Management
510.748.1017 (Office)
510.769.0596 (Fax)
www.actiontech.com
NOTE: The opinions expressed herein are those of the writer and not necessarily those
of Action Technologies, Inc. or its employees or its affiliates.
-----Original Message-----
From: Archana Turaga [mailto:[EMAIL PROTECTED]
Sent: Tue 1/20/2004 9:29 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: build question---please help
Thanks Richard. I appreciate the input (no you have not sidetracked me..:-).
Meanwhile i found something in the jetspeed's build.xml that may help my issue.
Well this is considering that none of the jetspeed source needs any change and
will work as it is released in the CVS. Any extra classes that are written belong to a
custom package structure belonging to the company and these most of the times (till
now in my experience) trurn out to be extensions of existing jetspeed classes For e.g.
Portlet classes extend JSPPortletAction.
Considering above is the case the following can be done (based on the
information in the jetspeed's build.xml)
1) Build jetspeed with the option war-template.
2) Explode this war to the app server webapps directory.
3) Copy the jetspeed jar and its dependent jars into the web-inf\lib directory.
4) Copy the custom portals template files to the template directories under
the webapps/
5) Copy the custom portals jars to the web-inf\lib directory.
6) This step is something i'm currently experimenting on. I'm going to try to
create my.properties (following the jetspeed property override-howto) and see if i can
also embed this. If this happens and my portal works then viola i think i have
achieved most of my goal.
If all the above steps are followed then i could do the following:
1) I can check-in the combined structure into our source control
2) Everybody else in our group can then check-in the jsps, java files to this
structure
3) Write make files(not ant tasks but .gmk files) to build the custom portals
jar files and custom portal's war file.
Although jetspeed source will still be maintained as a separate entity and ant
will be used to build the jar file needed for the custom portal. In future if there
are any bug fixes then this source will be modified and the jar will be rebuilt and
the custom portal's application war will have to be rebuilt to include this new jar.
I hope i'm making some sense. If anybody sees a problem with this approach or
tried the war-template approach please please let me know. Any input is appreciated
because that will allow me to make a sound decision on the maintainence aspect of the
portal.
Thanks and i appreciate all the help,
Regards,
Archana
>>> [EMAIL PROTECTED] 01/20/04 11:16AM >>>
Not sure if this is quite the answer you were seeking, but I am doing
something similar - e.g. incorporating an existing portal application
into the Jetspeed framework. Initially, I started by installing the
jetspeed .war file and then hacking various configuration files. Then,
in order to take the next step of incorporating my Java code, I realized
I would need to have the source to Jetspeed and to incorporate my source
into that structure (e.g. writing new portlets in the package
org.apache.jetspeed.modules.actions.portlets). So, I downloaded the
source and created new portlets.
To do the build, I used the Jetspeed build.xml file, but I didn't need
to make any changes in it. I put some additional .jar files in the
appropriate lib directory and the ant tasks copy them to web-inf. Then
to deploy my Jetspeed portal (with my portlets), I created a .war file
and then exploded it into the deployment directory (I used slightly
different locations for Jboss and WebLogic). Then, in general, when
making additional changes I use the ant target "hotdeploy" (and then
usually have to restart the app server).
With this background, I will try to answer your specific questions:
Q1) Do i have to then look at jetspeed's(the jetspeed source) build file
to come up with my build.xml?
<RB>I believe that you can use the jetspeed's build.xml, but I believe
that you do not have to modify that build.xml. </RB>
2) Instead of exploding the jetspeed jar to \web-inf\classes can i just
include this like a library jar in the web-inf\lib?
<RB>Don't know. My approach was to incorporate my stuff into the
Jetspeed framework, rather than just trying to use jetspeed as a jar.
It would be cool if #2 was possible, but something tells me that it
won't work (disclaimer: I am real newbie at this)</RB>
3) If step 2 is valid then can i only take all the files that are
missing in the jar file from the jetspeed directory and deploy them into
the file structure of my custom portal? for e.g. the .properties files
are not present in the jar file. Can i just copy this property files
from jetspeed directory into the my own portal's space ,merge the
properties and then build my own war file?
<RB>NA, as I am assuming that #2 is false</RB>
4) What are the recommended methods of source maintainence of custom
portals? Does the jetspeed source also need to be maintained or the
binaries and property files are enough?
<RB>Great question - as you can tell, I was under the impression that
the jetspeed source needs to maintained, extended, modified, etc. - at
least if you want to have any type of custom portlets. As you have
probably seen, you can create DBMS portlets and RSS portlets without
having to write any code (and there are probably others that are
configurable). </RB>
Hope that was useful and that my lack of true understanding didn't get
in the way :) :).
RB
Twenty Years | One Mission | Accelerating Business Processes
Richard Berger
Action Technologies, Inc.
VP, Product Management
510.748.1017 (Office)
510.769.0596 (Fax)
www.actiontech.com
NOTE: The opinions expressed herein are those of the writer and not
necessarily those of Action Technologies, Inc. or its employees or its affiliates.
-----Original Message-----
From: Archana Turaga [mailto:[EMAIL PROTECTED]
Sent: Monday, January 19, 2004 4:20 PM
To: [EMAIL PROTECTED]
Subject: build question---please help
Hi,
I have my own portal application with it's own library files and jsp
files. To understand jetspeed i just built the tutorial and hacked that
structure to include my portal specific information. Now i want to
create a build.xml that will work with ant to create my own portal war.
I cannot follow the tutorial build.xml because it goes in three steps
there
i) Deploy(this will simply replicate the jetspeed.war) ii)Start tomcat
This will explode the war into a directory structure.
iii) Then hot deploy so that it copies all the tutorial specific
information to exploded structure under tomcat.
Also the tutorial does not have it's own library files. I have my own
libraries that i want to use.
Questions:
1) Do i have to then look at jetspeed's(the jetspeed source) build file
to come up with my build.xml?
2) Instead of exploding the jetspeed jar to \web-inf\classes can i just
include this like a library jar in the web-inf\lib?
3) If step 2 is valid then can i only take all the files that are
missing in the jar file from the jetspeed directory and deploy them into
the file structure of my custom portal? for e.g. the .properties files
are not present in the jar file. Can i just copy this property files
from jetspeed directory into the my own portal's space ,merge the
properties and then build my own war file?
4) What are the recommended methods of source maintainence of custom
portals? Does the jetspeed source also need to be maintained or the
binaries and property files are enough?
Please help me. I have been trying to figure out the best way to
formalise the steps of source maintainence. Therefore all the developers
of the portlets can use this structure to check-in and check-out source.
Thanks in advance for your time and patience, Archana
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
