Elliot,
Here's a diff analysis I did with my suggestions for changes to move from trunk to pluto-1.1.x:
**************************************************************************************************************
Diff between pluto-1.1.x and trunk as of 1/4/2008
Significant changes that should be fixed:
*** fix in pluto-1.1.x branch
*** fix in pluto-1.1.x branch
root pom.xml (URLs in scm record (connection,developerConnection and url elements) modified in 1.1.x to point to tags/pluto-1.1.1 instead of trunk in trunk)
maven-pluto-plugin
InstallationDependancy (XERCES static field added to 1.1.x)
InstallationDependancy (XERCES static field added to 1.1.x)
pluto-ant-tasks
AssembleTask (archiveFileSets set to final in 1.1.x)
AssembleTask (archiveFileSets set to final in 1.1.x)
pluto-container
DefaultPortletPreferencesService (final var in 1.1.x)
RequiredContainerServices (interface methods made public in 1.1.x)
In test folder
MockResourceUrlProviderImpl (not in trunk)
PortletResponseImplTest (not in trunk)
ResourceBundleFactoryTest (final var in 1.1.x)
NamespaceMapperImplTest (final var in 1.1.x)
DefaultPortletPreferencesService (final var in 1.1.x)
RequiredContainerServices (interface methods made public in 1.1.x)
In test folder
MockResourceUrlProviderImpl (not in trunk)
PortletResponseImplTest (not in trunk)
ResourceBundleFactoryTest (final var in 1.1.x)
NamespaceMapperImplTest (final var in 1.1.x)
pluto-descriptor-api
PortletDD (EXPIRATION_CACHE_UNSET field added and expirationCache initialized to it in 1.1.x)
JspConfigDD (not in trunk)
JspPropertyGroupDD (not in trunk)
WebAppDD (JspConfigDD field with getter/setter added to 1.1.x)
PortletDD (EXPIRATION_CACHE_UNSET field added and expirationCache initialized to it in 1.1.x)
JspConfigDD (not in trunk)
JspPropertyGroupDD (not in trunk)
WebAppDD (JspConfigDD field with getter/setter added to 1.1.x)
pluto-descriptor-impl
In test folder
AbstractVersionedWebAppDescriptorTest (code additions in testWrite() in 1.1.x)
test/resources
servlet-2.4-webapp-descriptor.xml (jsp-config section added to 1.1.x)
main/resources/castor-web-xml-mapping.xml (jsp-config mapping added to 1.1.x)
In test folder
AbstractVersionedWebAppDescriptorTest (code additions in testWrite() in 1.1.x)
test/resources
servlet-2.4-webapp-descriptor.xml (jsp-config section added to 1.1.x)
main/resources/castor-web-xml-mapping.xml (jsp-config mapping added to 1.1.x)
pluto-portal
webapp/WEB-INF/fragments/about/view.jsp (added Java Version and OS to trunk)***
webapp/WEB-INF/fragments/admin/page/TomcatDeploymentHelp.jsp (numerous edits to trunk)***
webapp/WEB-INF/fragments/about/view.jsp (added Java Version and OS to trunk)***
webapp/WEB-INF/fragments/admin/page/TomcatDeploymentHelp.jsp (numerous edits to trunk)***
pluto-portal-driver
SupportedWindowStateService (all methods public in 1.1.x)
PortletTag (all private member variables set to null in 1.1.x except status)
SupportedWindowStateService (all methods public in 1.1.x)
PortletTag (all private member variables set to null in 1.1.x except status)
pluto-portal-driver-impl
ContainerServicesImpl (member vars final in 1.1.x)
ResourceConfig (portletApplications var final in 1.1.x)
ResourceConfigReader (digester var final in 1.1.x)
PortalURLParserImpl (three items added to ENCODINGS var in trunk - related to fixed Jira issue?)***
RelativePortalURLImpl (urlParser var and other changes in trunk - related to fixed Jira issue?)***
ContainerServicesImpl (member vars final in 1.1.x)
ResourceConfig (portletApplications var final in 1.1.x)
ResourceConfigReader (digester var final in 1.1.x)
PortalURLParserImpl (three items added to ENCODINGS var in trunk - related to fixed Jira issue?)***
RelativePortalURLImpl (urlParser var and other changes in trunk - related to fixed Jira issue?)***
pluto-site
In xdoc folder:
download.xml (noted added in trunk)***
index.xml (changed JSR-286 spec location in trunk)***
news.xml (added 1.1.4 news item in trunk)***
In xdoc/v11 folder:
app-servers.xml (major modifications in trunk)***
deploying.xml (minor text changes in trunk)***
getting-started.xml (minor, but significant edits in trunk)***
release-notes.xml (conflicting edits)***
In xdoc folder:
download.xml (noted added in trunk)***
index.xml (changed JSR-286 spec location in trunk)***
news.xml (added 1.1.4 news item in trunk)***
In xdoc/v11 folder:
app-servers.xml (major modifications in trunk)***
deploying.xml (minor text changes in trunk)***
getting-started.xml (minor, but significant edits in trunk)***
release-notes.xml (conflicting edits)***
pluto-taglib
ParamTag (added throws JspException to getName() in trunk)***
ParamTag (added throws JspException to getName() in trunk)***
pluto-testsuite
TestConfig (member variables set to final or null in 1.1.x)
TestResult (member var name initialized to null in 1.1.x)
TestResults (member var list set as final in 1.1.x)
webapp/WEB-INF/classes/logging.properties (removed from 1.1.x)***
TestConfig (member variables set to final or null in 1.1.x)
TestResult (member var name initialized to null in 1.1.x)
TestResults (member var list set as final in 1.1.x)
webapp/WEB-INF/classes/logging.properties (removed from 1.1.x)***
pluto-util
Assembler (member vars set to final and assemble() set as public in 1.1.x)
AssemblerCLI (member vars options and args set as final in 1.1.x)
FileSystemInstaller (imports re-arranged in trunk)
install/jetty/Call (missing from trunk)
install/jetty/Configure (missing from trunk)
install/jetty/Jetty5FileSystemInstaller (imports rearranged and dep.getPath().indexOf() call in getSharedDir() changed in trunk to use Java 5 String.contains() instead)
install/tomcat/Tomcat5FileSystemInstaller (dep.getPath().indexOf() call in getSharedDir() changed in trunk to use Java 5 String.contains() instead)
**************************************************************************************************************
To: [email protected]
From: Elliot Metsger <[EMAIL PROTECTED]>
Date: 01/04/2008 03:21PM
Subject: Re: [VOTE] Move 1.1-286-trunk-merge branch to trunk
Craig,
I'll take a look at the diff this weekend. A cursory glance shows that
there are actually a few more things in the 1.1.x branch than are in
truck, specifically some container unit tests and a wsrp fix.
The diff is taking a while on my machine... I'll review it and open up
any jiras for code that should be merged up to the 1.1.x branch from trunk.
Elliot
[EMAIL PROTECTED] wrote:
> Eric,
>
> Thanks for this message and all the patches you have recently contributed to
> Pluto. I just did a diff between pluto-1.1.x and trunk, and I found a number of
> differences. Most if them were minor, but a few of them were not. So I'd rather
> not get rid of the current trunk code for now since I am not 100% sure that all
> the trunk code has been properly merged with the 1.1-286-trunk-merge branch.
> Therefore, I intend to copy the current trunk to a pluto-1.2.0 branch before I
> move the 1.1-286-trunk-merge branch into the SVN trunk sometime early next week.
>
> At a later date when we have a stable JSR-286 RI in the SVN trunk, we can vote
> on getting rid of the pluto-1.2.0 branch. I'd just rather not do it now.
> /Craig
>
>
>
> -----Eric Dalquist <[EMAIL PROTECTED]> wrote: -----
>
> To: [email protected]
> From: Eric Dalquist <[EMAIL PROTECTED]>
> Date: 01/04/2008 10:51AM
> Subject: Re: [VOTE] Move 1.1-286-trunk-merge branch to trunk
>
> While I don't have any say in this my view is along the same lines as
> Elliots.
>
> 1.0.x is dead
> 1.1.x is being used and will likely need patch releases for the
> foreseeable future
> 1.2.x is pointless with 2.0 on the horizon and if there are any changes
> in 1.2.x that aren't in 1.1 or 2.0 they should be merged where
> appropriate and 1.2 should be abandoned
>
> -Eric
>
> Elliot Metsger wrote:
> > Sorry I'm coming in late on this discussion.
> >
> > I'm +1 for promoting the 286-trunk-merge to trunk, and +1 for bumping
> > all the pom revs to 2.0.0-SNAPSHOT thereafter. I haven't followed the
> > 286 coding much at all but I fully support its promotion. Thank you
> > to Craig, Torsten and others for making the 286 work happen.
> >
> > The pluto-1.0.2 branch is pretty much dead, and I don't think any
> > development effort has happened on it for over a year. I have no
> > opinion about keeping it or deleting it. SVN makes it easy to get back.
> >
> > The pluto-1.1.x branch should continue to be maintained for now. It
> > seems to be very stable, and we are still getting some bug fixes and
> > enhancements towards 1.1.x from the community. I think that the
> > pluto-1.1.x branch should be the basis for a 1.2.x branch (if we
> > decide to do a 1.2.0 release).
> >
> > The remaining branches (initial, 1.1.0-ADMIN-PORTLET-CRAIG,
> > 1.1-286-COMPATIBILITY) can go away I think.
> >
> > I don't believe that the current trunk (1.2.0) has any features over
> > the 1.1.x branch - I'll double check Jira and the SVN log to make
> > sure. Effort has been made to keep 1.1.x and 1.2.0 the same.
> >
> > I think we can forgo a 1.2 release and that the 286-trunk-merge should
> > become trunk. I think the easiest way would be what Ate suggested and
> > remove trunk and move the 1.1-286-trunk-merge to trunk. If history
> > has been properly maintained during the 1.1-286-trunk-merge work, I
> > don't think we will "loose" any history that matters.
> >
> > If we ever want to put forward effort to have a 1.2.x branch (perhaps
> > putting 1.1.x into maint mode to focus dev effort) we can create it
> > from the 1.1.x branch; then we won't have any regressions from 1.1.x
> > and we can just add the 1.5 sugar on top. If the 1.5 sugar is sweet
> > enough, it could be merged back to trunk.
> >
> > If it is decided not to release 1.2.0 from the current trunk, and
> > instead release it based off of another branch at a later time, we'll
> > need to some cleanup in Jira as well.
> >
> > Elliot
> >
> >
> > [EMAIL PROTECTED] wrote:
> >> Ate,
> >>
> >> Thanks for your well-considered comments (see below).
> >>
> >>
> >> -----Ate Douma <[EMAIL PROTECTED]> wrote: -----
> >>
> >> >To: [email protected]
> >> >From: Ate Douma <[EMAIL PROTECTED]>
> >> >Date: 12/19/2007 03:12AM
> >> >Subject: Re: [VOTE] Move 1.1-286-trunk-merge branch to trunk
> >> >
> >> >I'm +1 in general.
> >> >
> >> >But we also should discuss what to do with the current trunk.
> >> >I haven't closely followed the trunk status, but there might be
> >> >(significant) changes since the 1.4.0 release?
> >> >Although the JSR-286 is supposed to be JSR-168 backwards compatible,
> >> >we cannot assume every user is going to migrate to Pluto 2.0
> >> >(immediately).
> >> >Thus we have to cater for future maintenance / bug fixes on at least
> >> >the latest 1.x version too, which effectively means there will be 2
> >> >active Pluto >versions... (comparable to for instance Tomcat 5.5.x
> >> and Tomcat 6.x
> >> >development).
> >> >
> >> >So I think we might need to release the current trunk (as Pluto 1.1.5
> >> >or 1.2, whatever) *before* the 1.1-JSR-286-trunk-merge branch becomes
> >> >trunk.
> >>
> >> A few weeks ago, Elliot volunteered to do a Pluto 1.1.5 release and
> >> was preparing that in the 1.1.x branch, which, I believe, is a clone
> >> of the trunk. Please comment, Elliot.
> >>
> >>
> >>
> >> >Once the trunk is released, I suggest deleting it and then simply
> >> >copying the 1.1-286-trunk-merge branch to trunk.
> >> >Note: this way we might cause some annoying svn history breakage but
> >> >I see no other quick solution, short of merging the
> >> >1.1-JSR-286-trunk-merge back into trunk >which I expect will not
> >> be a trivial task.
> >> >
> >>
> >> Pluto 1.1 development began in a branch that was eventually moved
> >> into the trunk after 1.0.1 was released (Please comment, David).
> >> Before 1.1 moved into the trunk, a Pluto 1.0.2 branch was created for
> >> future 1.0.x development. I see the 1.1.x branch functioning in the
> >> same way: the place for future 1.1 development.
> >> The 1.1-286-trunk-merge branch is a merge with the both the trunk and
> >> the 1.1.-286-COMPATIBILITY branch. I see no need for further merging.
> >>
> >>
> >>
> >> >Regards,
> >> >
> >> >Ate
> >> >
> >> >[EMAIL PROTECTED] wrote:
> >> >> Hi all,
> >> >> >> The JSR-286 Expert Group's work is being completed in the
> >> next few
> >> >weeks.
> >> >> The JSR-286 RI work lead by Torsten Dettborn should also be
> >> >finished at
> >> >> that time. That work started in the 1.1-286-COMPATIBILITY branch,
> >> >but it
> >> >> has moved to the 1.1-286-trunk-merge branch with my help. As its
> >> >name
> >> >> implies, the 1.1-286-trunk-merge branch now has fully integrated
> >> >trunk code
> >> >> into the JSR-286 code.
> >> >> >> When the final RI work is done, Ate Duoma suggested that the
> >> code
> >> >be tagged
> >> >> in Subversion (remember a tag is not a release). That point would
> >> >also be a
> >> >> good time to move the 1.1-286-trunk-merge code into the trunk. I
> >> >suggest we
> >> >> change the pom version to 2.0.0-SNAPSHOT at that time.
> >> >> >> Is this something you can support?
> >> >>
>
>
