REST API Specification
by Nick Scavelli
The initial draft of the REST API specification is available now
https://community.jboss.org/wiki/GateInRESTAPISpecification. I tried to
design it as RESTful as possible for now, and we can decide if some
complexity that comes with REST is appropriate for the GateIn REST API.
For example Twitter's REST API is fairly easy to understand, however
some would not call it quite so "RESTful".
Also this specification conflicts with the stuff I've built for GateIn
Management, especially the organization of the resources (pages,
navigation, etc). However we should be in sync with how the Public Java
API is going to expose these resources. For example if I can do
api.getPages() as apposed to api.getSite().getPages() then Pages should
be a "first class resource".
All feedback is welcome.
- Nick
13 years, 5 months
Build update
by Julien Viet
Hi,
we are currently working on the build after the GIT migration, one of the current issue is profile selection.
The most important issue we are solving is that performing a release is error prone and often fails to perform the release properly: often POM are not versionned by the release plugin, du to the fact that it uses incorrect profile activation. Of course it is always possible to have it working by selecting the good profiles in the release plugin and on the command line, however it is error prone and it is hard to figure out by looking at the build what should be used.
We are going to change how the build work with profiles, not because we don't use profiles the right way, but because Maven profile activation is not good enough. (activeByDefault is broken, you cannot have flexible activation, etc...)
We still need to use profiles and actually we don't change the current profiles, what we do change is how their activation is done with a simple and important change: "Everything is built by default"
It means that the command "mvn install" builds everything (all server packaging, docs, examples, etc...). This guarantees that release plugin will release properly the project. Obviously we need to address developer productivity and we do provide a way to perform a build that saves the most time we can when it is activated in a simple manner.
To achieve it we use profile activation based on properties: the gatein.dev property is introduced to do it.
When this property is not present, the build behaves as said before : it builds everthing.
When it is selected with any value, it means that the build is done for development purpose and it skips some parts of the build (examples, docs, most of packaging).
When it is selected with a server value, it build that server only : for instance "mvn install -Dgatein.dev=jetty" . The possible values are
- tomcat
- jbossas5
- jbossas6
- jbossas
- tomcat6
- tomcat7
- jetty
Another issue to fix is the selected database for running the unit tests, but I believe it affects you less because most of you are using hsqldb tests. To perform tests with MySQL, the profile -Pmysql5 can be used.
Several things to note:
- The README file of GateIn has been updated with the information
- AS7 build is not yet finished and is cut of the build (which means that doing a release would not version the AS7 poms)
Let me know if you have any issue with the build.
Julien
13 years, 6 months
GateIn maven module structure
by Matt Wringe
Is there any document anywhere, or does anyone know why things are
placed in the current maven module structure? ie what makes something a
'component' what should go under 'web', etc...
It gets a bit confusing to try and figure out where new things should
go.
Thanks,
Matt Wringe
13 years, 6 months
GIT migration
by Julien Viet
Hi,
we are going to migrate the GateIn Portal repository to GIT soon (hopefully by next week) and here is the process we should follow:
1/ provide an initial repository (by me) as preview to play with it and check things are OK (identities, tags).
2/ stop SVN commits by the end of this week (which means that people having pending commits will have to flush them before the end of this week).
3/ the new repository should be available in GitHub early next week, ready to be used in the GateIn organization in a repository named "gatein-portal".
We want to use GIT in order to keep a trunk as stable as possible and the main motivation is to never have "unfinished" work in the master of the repository:
- a long feature does not have to be entirely finished of course to go in master but it should reach a certain milestone in its implementation.
- a small feature should be finished and then merged in the master.
- bug fixes can go directly in the master as they are independant.
Git provides a huge benefit over SVN : it allows to schedule when commits are merged in the master without blocking other people to work. We will use this
feature to "implement" the behavior explained before.
After the 3.2 release, we want to increase our release rate with GateIn 3.3, 3.4, etc.. We think we should be able to make up to 4 releases a year (as opposed to
a single release in almost 2 years which means an x8 factor). We also think that using correctly Git will help us to do that (also with a proper management of
the roadmap and dependencies between features of course). The idea is to focus on a few selected features in the master at a time for the next release and
keep the other in other branches (TBD).
We will clarify how people can work with this repository soon, but in short at the beginning only a few persons will interact directly with the repository. We will
use the "pull request" mechanism of Git to notify when a merge should be done (to be clarified by Bolek soon). Also here the idea is that we will schedule
pull request at the appropriate time.
So this is valid at the moment for the portal project, other project will be migrated later (during March/April), at the moment we focus on the portal because it's
the place where the main activity is done at the moment. Other project will have likely similar rules but it will be less strict since it's usually used by less people
than the portal.
So tonight I'm providing a repository preview https://github.com/vietj/gatein-portal-preview for the portal that contains the SVN history and the released tags
- it does not contain branch information (since we don't use them for the community versions).
- you should check the repository (like using a tag and building it).
- you must check your identity was correctly migrated (based on the information you provided) : if it is not tell me what is your Git identity.
- the .gitignore file was not added yet, I will add it later (likely like this one https://github.com/juzu/juzu/blob/master/.gitignore) : if you have specific desire tell me
- the maven release plugin is not yet updated to use Git and it will be done later (and actually it should be updated to release things more correctly).
if you feel something is missing or have question, don't hesitate to raise the concern.
cheers
Julien
13 years, 6 months
SVN -> GIT identities
by Julien Viet
Hi,
we are working on the migration of the portal svn repository to GIT and we need to link the svn identifiers to git identities.
I need your help to complete those (some may be out dated).
I published an online excel sheet to allow anyone to edit this file and correct the identity.
https://docs.google.com/spreadsheet/ccc?key=0AvM_noOJ_w0cdFJ3QXgxUEJnS0dR...
Please edit the file to change your ID to the correct Git identity.
If you have already a GitHub account you can link with your existing GitHub account, otherwise you should create an account.
The original values are like this:
julien_viet = julien_viet < julien_viet(a)mycompany.com>
It should be corrected to
julien_viet = Julien Viet <julien(a)julienviet.com>
that is taken from the .gitconfig file
[user]
name = Julien Viet
email = julien(a)julienviet.com
I need the identities to be corrected as soon as possible :-)
*anyone* with the link can edit the file.
thanks
Julien
13 years, 6 months
Re: [gatein-dev] Mobile Spec Feedback
by Matt Wringe
On Tue, 2012-03-06 at 21:11 -0500, Ken Finnigan wrote:
> Matt,
>
> I've read through all the Mobile specs you've written for GateIn, and here is my feedback:
Thanks, yeah, there are a few typos and such in the specs right now,
they are more of a draft to see what others feedback is before making
them more concrete. Thanks for looking over it, comments in line below.
>
> • Mobile Detection
>
>
> • Introduction
>
>
> • Last paragraph has a typo, think the "m" needs to be a
> comma in "content between devicesm different content"
> •
> Use Cases
>
> • 2nd bullet has an "except" that should be "expect"
> •
> Replaceability
>
> • Agree that we need something smart enough to be able to
> determine whether the filter is active to prevent UI admin display,
> while also providing a way to turn the whole thing off. If there's a
> configuration setting for turning on and off, would it be a case of
> the filter is always active, but just skips over itself if the
> configuration setting is deactivated? This would enable it to be
> reactivated without necessitating a portal restart, I'd imagine. There
> may be a dynamic/fancy way of doing it too
We shouldn't really use filters anymore. The navigation controller now
controls how portal urls are mapped. I have already updated my prototype
to use a WebRequestHandler instead.
I don't know if it makes sense for it to be completely plugable and
remove all trace of it from the admin ui if its removed (nor have I
started to create the ui components yet). It will be setup so that its
disabled by default and will require either an xml configuration file to
be configured, or enabled through the admin ui.
The logic for determining redirects will be a service, and the admin can
write their own service implementation to handle this if they want to
use a custom solution. The device detection will also be configurable as
well, so the admin can select exactly what they want to check for.
If someone wants to have their own completely different configuration,
they are also free to use their own custom filter or some other
mechanism to handle it. They would just need to make sure the built in
one is disabled.
> Mobile Redirection and Mirroring
>
> • Workflow
>
>
> • Definitely think that the logic paths to go from
> original url to destination url need to be cached. Maybe add that as
> first step in flow to check cache for existing mapping from orig->dest
> for matching orig. Then updates to mappings by admin could cause flush
> of cache to that part of the tree impacted. ie. admin changing
> mappings for portal/foo/x/y will flush cache for portal/foo/x/y and
> anything lower, but cache for portal/foo/x and other children of x
> still remain
Yes, caching needs to be done.
> Mobile Manual Redirection Selection
>
> • I think there should be the option for the user to decide
> whether this alternative site will always be redirected to
> (cookie/session is updated), or only this one occasion (session is
> updated)
I disagree, we should only give the user the option to always redirect
but make it easy for them to switch back.
> Mobile Look and Feel
>
> • Is there a link for the touch based gestures at the end of
> the Introduction yet?
The look and feel is a bit farther away and has other things which need
to be fixed before we get into things like gestures. Gestures are not
going to be supported at least for the first couple of releases of this.
Its more important to get the device detection and redirection working
properly.
> •
> Mobile Portlet Development
>
> • Use Cases
>
>
> • Look and Feel has typo of "fell" instead of "feel"
> •
> General
>
> • Could the Navigation Controller be leveraged to provide any
> of this URL mapping or routing that would be required in switching
> between desktop/tablet/mobile?
Yes, I am using the navigation controller now and using some internal
services to determine mappings and routings. For now I am concentrating
on just allowing switching between sites on the same portal which makes
things a lot easier. I will have to see later if there is much of a need
to have redirection between separate distinct portals or between other
separate websites (between separate distinct portals becomes a bit
tricky since I don't think we have remote capabilities to detect if a
node exists or not).
>
> Given the current architecture of the platform, ie. not geared for
> mobile, I believe the specs you've outlined are a great step into the
> portal supporting mobile. Impressed with the various aspects that
> you've covered thoroughly.
>
>
> Ken
13 years, 7 months
