portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Where should portlet-api_3.0 & portlet-tck_3.0 live?
Date Fri, 27 Jun 2014 16:08:52 GMT
All ASF projects are supposed to host their source on ASF infrastructure. That said, there
is an approved way for projects to use Github if they choose - although I have never done
it so I’m not sure what is involved.

However, what you are proposing is a bit unusual because, as far as I understand it, the portlet
TCK and API are really owned by the JSR committee and not the Portals project.

My personal opinion would be to bring them into svn (or the ASF Git mechanism) as soon as
practical.

Out of curiosity, where does the actual portlet spec document reside?

Ralph

On Jun 27, 2014, at 7:23 AM, Martin Scott Nicklous <Scott.Nicklous@de.ibm.com> wrote:

> 
> I have a question: we want to start working with the v3.0 TCK & API. So
> far, these components are hosted on Github, but it seems to me like it
> would be more convenient for Pluto development if we add these directories
> to the Pluto base project directory. That way, developers would have the
> code to build the 3.0 API themselves, and if you want to work on the TCK,
> you can do so from within the Apache Pluto git repo. The resulting
> directory structure would look like this:
> 
> portlet-api_3.0
> portlet-tck_3.0
> pluto-ant-tasks
> pluto-container
> pluto-container-api
> pluto-container-driver-api
> pluto-portal
> pluto-portal-driver
> pluto-portal-driver-impl
> pluto-site-skin
> pluto-taglib
> pluto-testsuite
> pluto-util
> 
> The portlet-api_3.0 and portlet-tck_3.0 maven builds are currently
> independent of one another. If I add these directories to Pluto, I would
> leave the builds independent, at least for now.
> 
> The portlet-tck_3.0 directory in the Pluto repo would become the master for
> the 3.0 TCK. In other words, moving forward, I would only make changes to
> the Pluto version of those files.
> 
> However, for the time being, I would like to leave the master of the 3.0
> API on Github for two reasons: I like the Github.io pages for displaying
> the portlet API, and also because I have a (too) complicated local branch
> structure based on the Github repo, that I don't want to try to reproduce
> for the Pluto repo ... too much work, and too little bang for the buck. So
> for the time being, we would have a single, more or less fixed copy of the
> API on Pluto to develop against, but API changes that the expert group
> agrees upon will initially go into the Github repo.
> 
> So my proposal would be to copy the following into the Pluto project from
> the Github portletspec3 project:
> 
> portlet-api_3.0
> portlet-tck_3.0
> 
> The alternative would be to leave these items on Github for now, and Pluto
> developers who want to work on the TCK would have to fork the Github
> Portletspec3 project.
> 
> Thoughts?
> 
> If you have objections / suggestions, it would be good if you could make
> them known within the next couple of days, because I would like to carry
> this out on Sunday evening before I leave on vacation for a week.
> 
> Mit freundlichen Grüßen, / Kind regards,
> Scott Nicklous
> 
> WebSphere Portal Standardization Lead & Technology Consultant
> Specification Lead, JSR 362 Portlet Specification 3.0
> IBM Software Group, IBM Collaboration Solutions
> 
> Phone: +49-7031-16-4808 / E-Mail:scott.nicklous@de.ibm.com /  Schoenaicher
> Str. 220, 71032 Boeblingen, Germany
> IBM Deutschland Research & Development GmbH / Vorsitzender des
> Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
> HRB 243294
> 


Mime
View raw message