I like the splatch website design also.
As we discussed for Karaf, moving the SMX website to use scalate
requires that we have a "nightly" deployment of the website to quickly
update the news section, etc.
Regards
JB
On 06/29/2011 09:33 AM, Guillaume Nodet wrote:
If we do the same as Karaf, the scalate based web site mostly consist
in non technical docs (downloads, community, irc, forums, etc...) and
all the technical docs are in versioned manuals.
ServiceMix has a particularity though because we have several major
versions which are really different, so that may affect a bit.
Anyway, I really like the one splatch, so if he can give us the core
images used in that web page, I'm sure we can make it work with the
site Gert has worked on.
On Wed, Jun 29, 2011 at 08:15, Lars Heinemann<lh...@apache.org> wrote:
Yes, I agree that we first should go for the content. But it's a bit wired as
if we don't have so many sub pages as
in the current page then we will probably do content for pages which will not
be used or in a different form.
We should just have some basic idea how the sitemap will look like before
flooding in the content.
Best regards,
Lars
--------------------------------------
Lars Heinemann
FuseSource
Email: lh...@fusesource.com
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77
Am 29.06.2011 um 08:03 schrieb Guillaume Nodet:
I don't have any problems with changing the design, but I just think
that the content is more important than the color
On Wed, Jun 29, 2011 at 07:39, Lars Heinemann<lh...@apache.org> wrote:
Regarding the webpage design...
As already stated I don't like the design of the webpage. It seems to be a
duplicate of the Karaf homepage
and I can't see that the page is now more easy and clean as we once intended to
do.
Well, if I can slightly object, it's kinda the opposite, as Karaf has
simply reused the ServiceMix design ;-)
I'd like to point you to the following design proposals which I think are
really awesome looking...
http://www.flickr.com/photos/ccustine/5390898666/sizes/l/ (from ccustine)
http://img259.imageshack.us/img259/1718/servicemix46.jpg (from splatch)
Shouldn't we go for something like this? Those designs are awesome looking and
have a very clear and simple navigation concept.
Both looks really good to me, but before switching the css, we need to
get the scalate stuff to work and the content up to date, so that we
can switch to that new stuff asap.
Then, we can propose changes on the pure css stuff (colors, images,
icons etc...) based on the new website. Once we have the
infrastructure in place, we can easily branch or experiment with css
patches.
Wdyt?
Best regards,
Lars
--------------------------------------
Lars Heinemann
FuseSource
Email: lh...@fusesource.com
Web: http://www.fusesource.com
Blog: http://lhein.blogspot.com
Twitter: lhein77
Am 29.06.2011 um 01:39 schrieb Gert Vanthienen:
Guillaume,
All this seems to make a lot of sense to me - let's drop the bits that
don't bring any value (any more) and try to add value to the project
by focusing on providing these container-level services to integration
projects. I also like the idea for creating both a Tomcat and a Karaf
based distribution. That way, people can start with the more familiar
WAR deployment in a simple Tomcat container and, as they need the more
advanced features, gently migrate to the full OSGi-goodness of the
Karaf based distribution.
For the website, I took an initial stab at migrating the relevant bits
of existing website contents to a Scalate/Maven-based project at
https://svn.apache.org/repos/asf/servicemix/website and pushed an
initial copy of the result out to
http://servicemix.apache.org/staging/ so we can start adding content
again there until we're happy enough with the result to promote this
to become the home page.
Information about the current location/build/... of the documentation
project can be found at
http://servicemix.apache.org/documentation-project.html - we have a
bit of content for ServiceMix 4.x in there already but it still needs
quite some work. For ServiceMix 5.x, we should probably grow the
habit of documenting every single feature the moment we add it to the
codebase right from the start so we can build the documentation right
along with the actual code.
Regards,
Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
On Mon, Jun 27, 2011 at 5:54 PM, Guillaume Nodet<gno...@gmail.com> wrote:
Last week, I've been discussing with a few committers about the
ServiceMix roadmap.
So I'd like to communicate those thoughts to a wider audience.
We've been discussing already that the value of ServiceMix (which was
the JBI layer in ServiceMix 3
and the container side in ServiceMix 4) has moved mostly to Camel and
Karaf respectively. The remainining
bits are mostly the NMR. However, the value of the NMR is not in the
NMR itself, but rather the NMR was
supposed to enable various container-level features. However, we
haven't really built those features so
that the *real* value of the NMR is not that high currently.
So, what we've been discussing is to focus on that added value in a
more transparent way by tweaking
Camel a bit to support global interceptors, so that one could deploy
the real routes without having to
force the use of a specific transport such as the current NMR. This
way, a user could test / develop
the Camel routes or take existing Camel routes and deploy them in
ServiceMix, thereby transparently
enabling a bunch of useful features. We've been thinking about adding
message tracing / timing / auditing,
sending test messages, security checks, viewing flows, persistent
modification of camel
routes, camel route versioning, etc... That need to be coupled with a
web console similar to the
Camel / ActiveMQ web consoles, to actually display all the data to
provide useful information for monitoring
Camel routes and help diagnosing problems in production for example.
There's really nothing magically new
here and some of those features were actually part of ServiceMix 3,
but without much focus on those and
they have always kept a bit on the side. The idea is really to make
ServiceMix the best possible container
for deploying Camel based integration.
Additional things that could be pushed inside ServiceMix 5 would be a
Tomcat based container deployment
option (for those that don't need OSGi), a new manual similar to what
we have in Karaf (maybe reusing
parts of it). We'd also need a new website (without the technical
doc, as we have for Karaf I think).
On the maintenance of the JBI components and NMR/JBI layer, I think we
should keep them in smx4.
People wanting to deploy those could easily add a pointer to the
servicemix 4 features descriptors and
deploy the needed features. So we could officially deprecate those
and tell users they won't be
available in smx5. This also means that there's really not much to
reuse from smx4, so smx5 would
have its own new and dedicated svn area.
FWIW, I plan to devote a big chunk of my time on ServiceMix 5 in the
coming months, so those are not
faithful wishes, but really something I want to start implementing asap.
Feedback welcomed!
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
