can you explain the API versioning scheme ?

after a rapid at the implementation, you shall not use the MOP API directly for various reasons 1/ performance, the component mop does not manage caching but services do 2/ some service provide value added on top of MOP (the NavigationService) 3/ you will not access some features managed by the portal (such as extended I18N) instead you should use the various services in front of it: 1/ ModelDataStorage (legacy service) for portal / pages : not great to use but that's the way it is until it is rewritten

2/ NavigationService for navigation

3/ DescriptionService for navigation i18n

On Jul 8, 2011, at 5:46 PM, Christophe Laprun wrote: > Folks, > > I've committed the initial code for the API implementation: https://source.jboss.org/changelog/GateIn?cs=6849 > I've created a new branch for this work: https://svn.jboss.org/repos/gatein/portal/branches/api > It currently won't compile because there is no deployed artifact for the prototype API. > > Action items: > - Please comment on code organization on the portal side. So if I understand correctly you want to keep gatein-api in github and place implementation in svn component/api-impl. This sounds good too me. We'll need to work release process and productization but thats the same case for Nicks work actually. > - Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts. org.gatein.portal:gatein-api org.gatein.portal:gatein-api-impl Seems fine. > - Please confirm API versioning scheme. I'm personally fine with going with 1.0.0 (instead of 3.2.0) for the API as we aim to keep separate lifecycle for this component long term. Julien, Thomas any issue with those on your side?

Bolek _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jul 8, 2011, at 5:46 PM, Christophe Laprun wrote: > Folks, > > I've committed the initial code for the API implementation: https://source.jboss.org/changelog/GateIn?cs=6849 > I've created a new branch for this work: https://svn.jboss.org/repos/gatein/portal/branches/api > It currently won't compile because there is no deployed artifact for the prototype API. > > Action items: > - Please comment on code organization on the portal side. So if I understand correctly you want to keep gatein-api in github and place implementation in svn component/api-impl. This sounds good too me. We'll need to work release process and productization but thats the same case for Nicks work actually.

> - Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts. org.gatein.portal:gatein-api

org.gatein.portal:gatein-api-impl

Seems fine. > - Please confirm API versioning scheme. I'm personally fine with going with 1.0.0 (instead of 3.2.0) for the API as we aim to keep separate lifecycle for this component long term. Julien, Thomas any issue with those on your side? Bolek _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jul 11, 2011, at 1:48 PM, Julien Viet wrote: > > On Jul 11, 2011, at 12:56 PM, Boleslaw Dawidowicz wrote: > >> On Jul 8, 2011, at 5:46 PM, Christophe Laprun wrote: >> >>> Folks, >>> >>> I've committed the initial code for the API implementation: https://source.jboss.org/changelog/GateIn?cs=6849 >>> I've created a new branch for this work: https://svn.jboss.org/repos/gatein/portal/branches/api >>> It currently won't compile because there is no deployed artifact for the prototype API. >>> >>> Action items: >>> - Please comment on code organization on the portal side. >> >> So if I understand correctly you want to keep gatein-api in github and place implementation in svn component/api-impl. This sounds good too me. We'll need to work release process and productization but thats the same case for Nicks work actually. > > On our side we are inclined to move to GIT but not without having planned it. > > For now it is not formally planned. > > It does not mean we should not use it right now, but at least we should define and agree and basic things before using GIT as a part of our formal version control system. > > In a second step we should plan and define the migration of existing code base to GIT. > > In addition there is the distinction between GIT (SCM) and GitHub (project infrastructure built on top of GIT). > > We should discuss that in a separate mail thread and not pollute this thread. Agreed. >> >>> - Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts. >> >> org.gatein.portal:gatein-api

> would be separate > >> org.gatein.portal:gatein-api-impl > > would live in portal codebase > > are those correct ? Yes. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jul 12, 2011, at 3:22 PM, Matt Wringe wrote: >>>> org.gatein.portal:gatein-api > > maybe something like org.gatein.api as the group id? we are probably > going to have multiple api artifacts (java, rest, ...) org.gatein.api might make more sense, yes, especially considering that some of the API won't deal with the portal itself. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

On Jul 12, 2011, at 4:06 PM, Julien Viet wrote: > in that fashion it would make sense to move your code package from org.gatein.api to org.gatein.api.portal package Actually, most of it so far doesn't have much to do with the portal itself… only navigation does. Using portal in packages is redundant I think. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

On Jul 12, 2011, at 4:29 PM, Julien Viet wrote: > does it mean that the object org.object.gatein.Portal has nothing to do with the portal itself ? > > On Jul 12, 2011, at 4:25 PM, Christophe Laprun wrote: > >> >> On Jul 12, 2011, at 4:06 PM, Julien Viet wrote: >> >>> in that fashion it would make sense to move your code package from org.gatein.api to org.gatein.api.portal package >> >> Actually, most of it so far doesn't have much to do with the portal itself… only navigation does. Using portal in packages is redundant I think. and Portal, of course! :) Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm

Folks, I've committed the initial code for the API implementation: https://source.jboss.org/changelog/GateIn?cs=6849 I've created a new branch for this work: https://svn.jboss.org/repos/gatein/portal/branches/api It currently won't compile because there is no deployed artifact for the prototype API. Action items: - Please comment on code organization on the portal side. - Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts. - Please confirm API versioning scheme. I need this information ASAP so that I can push forward with further implementation. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jul 12, 2011, at 3:50 PM, Matt Wringe wrote: > So looking into the REST part of the api, I have a few questions here > with the design of the API: > > 1) Does the API assume that only a superuser is ever going to use it, or > does it assume that other logged in (or unauthenticated) users will be > using it as well? > Ie I want to create a navigation/menu portlet. If I retrieve the nodes, > will I get only the nodes I have permission to view, or do I have to > retrieve them all and manually filter out the ones I don't have > permission to access? > It makes more sense for the rest service to only return elements the > user has permission to access, but we can filter that on the rest side > if needed. The current API takes the point of view that whoever is calling into it has administrative rights. > 2) Are we still going to be using java resources for internalization?

I have no idea on this… :/ Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

On Jul 12, 2011, at 3:50 PM, Matt Wringe wrote: > So looking into the REST part of the api, I have a few questions here > with the design of the API: > > 1) Does the API assume that only a superuser is ever going to use it, or > does it assume that other logged in (or unauthenticated) users will be > using it as well? > Ie I want to create a navigation/menu portlet. If I retrieve the nodes, > will I get only the nodes I have permission to view, or do I have to > retrieve them all and manually filter out the ones I don't have > permission to access? > It makes more sense for the rest service to only return elements the > user has permission to access, but we can filter that on the rest side > if needed. > I think the main use case would be for superuser - like for admin purposes but we should also address use case of users with more constrained permission accessing it _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

Action items: - Please comment on code organization on the portal side.

- Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts.

- Please confirm API versioning scheme.

On Jul 8, 2011, at 5:46 PM, Christophe Laprun wrote: > Action items: > - Please comment on code organization on the portal side. Seems like there are no comments on this part so things will move forward as they stand. > - Please confirm the artifact and group IDs for the API proper and implementation Maven artifacts. New proposed group id: org.gatein.api New proposed artifact id (API proper): gatein-java-api New proposed artifact id (implementation): java-api-impl > - Please confirm API versioning scheme. Seems like there's an agreement around the 1.0.0 scheme as opposed to 3.2.0. Version has been reset to 1.0.0-Beta01-SNAPSHOT instead of GA. Thanks. Cordialement / Best, Chris == Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev