Hi Ron,
On 5/6/07, Ron Wheeler <[EMAIL PROTECTED]> wrote:
Thanks for the wisdom of experience. It looks like a good path for what
I want to do.
I have 2 projects that I have to do.
I am pretty sure that 1 is a good Jetspeed project.
The other one has some WebServices requirements (graphical client and
process control interfaces) but I am wondering if it might be a good
idea to have a portal front-end as well for routine maintenance and
those features (simple business process functions) where the WebServices
client is more trouble than it is worth.
It might make it easy to test (or verify tests) of non-portal processes.
I am working in Eclipse. From what you are saying, I could start a new
Maven project and keep a standard Jetspeed development project for those
situations where I want to modify the core Jetspeed package and
contribute my mucking about back to the community.
Right, you generate a portal project with the command described on
this page (Note that the archetypeVersion can vary).
http://portals.apache.org/tutorials/jetspeed-2/01/genapp.html
Then you put your custom stuff in the portal and application
directories generated by the archetype.
mvn -P tomcat,min will build and deploy your portal (I shut down
tomcat when I do this, but there is a hot deploy that I don't know how
to use yet).
The Jetspeed documentation is pretty obscure and needs some help.
Can you give me the outline of the actual steps required to follow your
suggestion.
I've upload my settings.xml but it isn't that much different from the
settings.xml.sample in subversion.
http://people.apache.org/~pmd/settings.xml
Is there a set of Jetspeed libraries that I can just reference in my
projects or do I have to incorporate some of the Jetspeed resources into
my build?
There are numerous Jetspeed resources required but this is handled by
the archetype when you generate the portal project.
Philip
Ron
Philip Mark Donaghy wrote:
> Hi Ron,
>
> On 5/6/07, Ron Wheeler <[EMAIL PROTECTED]> wrote:
>> It would seem reasonable that I should change the groupId and artifactID
>> to something that describes my project.
>
> I did this when I first started working with Jetspeed. And I did so to
> contribute and follow the evolution of Jetspeed. Today I wouldn't do
> that. I've got one project that is going to take a while to merge with
> the latest from subversion because I did just what you are describing.
>
> So I would use the archetype to generate a custom portal. My
> experience is that the source code changes very fast and it is
> preferable to follow a migration guide from one version to another.
>
> I know that waiting for new versions is not always easy so I suggest
> that you use the archetype. Then keep a separate subversion build that
> you use to test new archetypes or Jetspeed features you need to
> integrate into your portal.
>
> My last thought is if you want to be lazy then run one j2 subversion
> build and continue to use the archetype without changing the j2
> source. If you come up with a good feature then you can contribute to
> the well being of j2 and your project can be tested with the latest.
> If you do this then write a separate settings.xml and keep a separate
> m2 repository. One for the project and one for j2 latest. Any way you
> look at it requires managing separate build environments.
>
> Philip
>
>>
>> What problems is this going to cause besides making all of the pom.xml
>> files all custom to my projects?
>>
>> I understand that I have to change all of the parent records in the
>> subsiduary pom.xml files..
>>
>>
>> <groupId>org.apache.portals.jetspeed-2</groupId>
>> <artifactId>jetspeed-2</artifactId>
>>
>> Ron
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Philip Donaghy
donaghy.blogspot.com del.icio.us/donaghy/philip
Skype: philipmarkdonaghy
Office: +33 5 56 60 88 02
Mobile: +33 6 20 83 22 62
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
