We need to release mmm-search-* version 1.0.2 after all issues are resolved and publish the result to central maven repo.

Invent new modules and move around existing common interfaces.

mmm-uit-core
mmm-uit-widget
mmm-uit-element

Until util-core in 1.0.2 more or less only an API was provided for the panned stream-detector-framework. This is to be implemented.

When the configuration is missing tags (e.g. ), ID-references are wrong or IDs are not unique you end up with NPEs which is not really helpful for the end-user.

We need to improve the (spring-)configuration of mmm-persistence. It needs to be restructured and offer more flexibility for datasource/connection-pool, jpa-vendor, etc.

When the search-indexer is working incremental using "vcs" as strategy (and "svn" as type) I get this exception:

An unexpected error has occurred:
java.lang.NullPointerException: repository cannot be null

at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:49)
at org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.executeCommand(AbstractSvnScmProvider.java:356)
at org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.info(AbstractSvnScmProvider.java:377)
at org.apache.maven.scm.provider.svn.svnexe.SvnExeScmProvider.getRepositoryURL(SvnExeScmProvider.java:150)
at org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.makeProviderScmRepository(AbstractSvnScmProvider.java:119)
at org.apache.maven.scm.manager.AbstractScmManager.makeProviderScmRepository(AbstractScmManager.java:267)
at net.sf.mmm.search.indexer.impl.strategy.SearchIndexerUpdateStrategyVcs.index(SearchIndexerUpdateStrategyVcs.java:201)

The encoding for locations should be strict and disable UTF detection. Only if not set in location UTF detection shall be enabled for text. The non-UTF-encoding shall be configurable.

Tests reveal that XML unmarshalling does not work anymore:

testSearch(net.sf.mmm.search.engine.impl.lucene.LuceneSearchEngineTest): The XML from "unexpected element (uri:"", local:"locations"). >Expected elements are (none) at [node=null,object=null,url=null,line=8,col=18,offset=-1]" is invalid!

This seems to be as JAXB code is referring to SearchSourceBean while SearchIndexerSourceBean is required to resolve "locations". I cannot add a @XmlSeeAlso refererring as this is not visible at this point.
However it is not loaded from SearchIndexerConfigurationLoader so maybe also the XML of the test-case is just wrong and the invalid tags have been ignored in earlier versions of JDK/JAXB-Impl.
Seem I will have to track back why this once worked first...

util-core shall offer support for GWT so various features can be used in GWT clients.

We want to integrate the code from mmm-util-pojo into mmm-util-core. Packages and Classnames will not change and still gain compatibility. However value-converters can then depended on pojo code and allow advanced features as planned for ValueConverterToCompatiblePojo that is currently bundled with util-pojo but belongs to util.value which is in util-core.

Queries containing "()" are causing an infinity loop in the parser.

We need to release mmm-service-* modules and publish to central maven repo.

Iso8601Util.parseCalendar("19991231T235959Z") fails with an exception that "235959Z" is an illegal argument.

Currently NLS only accepts instances of AbstractResourceBundle for reverse mapping of root bundle in template-resolver.

If you read messages from a configuration file and want to do localization you would first have to create a java class extending AbstractResourceBundle and compile it. Then you can create a localized properties file.
It should also be possible to use a properties file for the root bundle declared in "META-INF/net.sf.mmm/nls-bundles".

We need to improve our CDI configurations (dedicated for spring). All components should have explicit and stable IDs defineds a constants (typically in component interface). This way it should be possible to externally override a component implementation via spring XML using the same ID but alternate implementation.

Further, component scan should be per major component (e.g. net/sf/mmm/util or net/sf/mmm/service instead of all [net/sf/mmm]) in order to avoid loading and setting up too many components on startup (e.g. to speed up junits).

We want to release GWT support for mmm-util-core. This has already been created with mmm-util-gwt but we decided for simplicity and usability that we want to have it directly in mmm-util-core.

we need to complete mmm-persistence and deploy to maven central repo.

For UIT we need generic enum access e.g. to fill option lists of option widgets (combobox, radios, etc.). Therefore, util-core shall provide a generic API and base implementation. Actual implementation however, needs to be provided outside (may include DB access via persistence for dynamic enums). The API should be designed to be used both in synchronous (JEE server) as well as in asynchronous environments (client).

Due to problems with subversions and increased stability and support of git we want to migrate to git.

mmm-data needs to be refactored and finally removed.

• we want to get rid of *View interfaces as this makes it overcomplicated
• we need to put this into the according mmm-app-*-shared/-server modules

Build and deploy release mmm-util-core version 4.0.0

Caused by: java.lang.IllegalAccessException: Class net.sf.mmm.util.pojo.descriptor.impl.accessor.PojoPropertyAccessorNonArgMethod can not access a member of class net.sf.mmm.util.pojo.descriptor.impl.PublicMethodPojoDescriptorBuilderTest$TestPojo with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Method.invoke(Method.java:588)
at net.sf.mmm.util.pojo.descriptor.impl.accessor.PojoPropertyAccessorNonArgMethod.invoke(PojoPropertyAccessorNonArgMethod.java:54)
... 25 more

Such methods also need to be made accessible.

We need to create/improve/complete the UiWidget layer (mmm-uit-widget-api) and its GWT implementation (mmm-uit-widget-impl-gwt).
Goal is that API can also be implemented for other UI toolkits. Next one will be swing. This allows brief testing UI components way faster than with these slow development cycles of GWT.

In order to demonstrate the features and concepts of mmm-client (esp. ui-widget and ui-dialog), we need to create a showcase. The showcase needs to be well designed (we need some common infrastructure for each showcase feature including possibility to show the source-code) and should on the long run be available for all supported underlying toolkits.
It should follow the best practices of other existing showcases, e.g.
http://gwt.googleusercontent.com/samples/Showcase/Showcase.html
http://www.smartclient.com/smartgwt/showcase/

The webapp for mmm-search should show the current version of mmm.
This should also link to a page that shows a table with all versioned artifacts on the classpath using ManifestLoader.

We need to complete and release version 3.1.0 of mmm-util-core.

After creating all the nice NLS stuff in util-core the webapp for the search should actually use it so it can be localized.

UiWidgetListTable is to be implemented. This will be tough especially for web (GWT). We have to consider the following requirements:

• Support for scrolling tbody vertically as needed and the entire table horizontally.
• Ability to scale the size of the entire table with the available size (without javascript layout managers)
• Abilitly for the user to sort by column (via clicking on column header)
• Ability for the user to resize columns (with e-resize cursor on the fly by dragging the right border of the column)
• Ability for the user to reorder columns with drag and drop via column header
• Ability for inline editing
• Ability for multiple selection with checkboxes
• Keyboard support to step through the column headers and cells with cursor keys
• Accessibility support via WAI-ARIA
• For large datasets it may be required that we only render the visible part and update lazily while scrolling

We need to complete & build mmm-util-gwt:1.0.0 and deploy to maven central repo.

java8 introduced new awesome features and also standard functional interfaces that replace or obsolete interfaces like net.sf.mmm.util.lang.api.Function.

We want to carefully consider downward compatibility and support of older java versions but still make use of the new stuff. The major strategy should be:

• modules that have already been released (esp. mmm-util-core) need to follow a careful compatibility plan.
• new modules that will not be released before the end of the year can use new java8 features and may not run with older java versions.

For the first case we should consider:

• avoid to use java8 syntax and features that prevent running the code in java 1.7-
• provide a backport implementation of java.util.function
• add a dependency to that backport implementation based on java-version profile trigger so if java version is less than 1.8 this dependency will be added, otherwise not.
• we need to explicitly test that the (1.5 level) compiled code really works with all versions from 1.5-1.8 without recompilation.

We have to create/improve/complete mmm-service-*. We also need an alternate implementation to GWT. It should use spring-remoting (HttpInvoker).

Creating dynamic queries with JPQL is painful due to ugly string concatenations. Further building these strings requires a lot of knowledge that if NOT immediately present requires scanning the specification that is quite complex. As Criteria API is not always suitable and sometimes hardly to predict, we will create a query builder for JPQL. This will allow to build JPQL queries dynamically in a type-safe, compact and expressive way. The API/JavaDoc will guide you and provide the required information.

Create a release of mmm-util-core:3.0.0 and mmm-util-gwt:1.0.0 and publish to maven repo.

If you want to index something in your home directory and therefore configure a location-uri starting with ~/... you will get an IllegalStateException.

We need to refactor mmm-persistence:

• move (and rename) entity interfaces to util-core so transfer-objects and other stuff using it does not require a dependency on mmm-persistence what would be odd.
• rename _PersistenceEntity_Manager* to *Dao. We did not like the term DAO but it is simply so common and widely used that we shall adopt it.
• refactor search support as PersistenceSearcher approach was too complicated and can be designed way simpler by wrapping underlying query without big impact on DAO API.

The WAI-ARIA standard is more complex than initially thought of. After understanding all the concepts we need to change it to a typesafe API that models the roles in an object oriented manner.

when mmm-search-indexer-impl-lucene is used with all dependencies to run the SearchIndexerMain, one ends up with an Exception that StaticLoggerBinder could not be found.
The problem is that mmm-search-indexer-base is missing a dependency to the slf4j implementation (slf4j-log4j)

Recent validation API sucks due to the use of exceptions.
Redesign required, old stuff will be depreceted and removed one release later.

If NLS is used without IoC, then NlsDependencies with all related components is created and initialised multiple times. This shoul be prevented.

We want to add JSON support to mmm-service via GSON. Maybe will will also find a compatible way for this in GWT.

For NLS we use java.text.Format that is not supported by GWT. However, GWT supports com.google.gwt.i18n.client.NumberFormat that allows to port most NLS formats (percent, number, etc.). A simple abstraction will allow to make this GWT compatible by super-sourcing the abstraction class.

If ReflectionUtil.visitResourceNames (or ReflectionUtil.findResourceNames or ReflectionUtil.findClassNames) is invoked with package being the empty string ("") then it scans the entire classpath including all resources. This is correct however it is causing the root path to be "/" instead of "". Therefore all resolved paths have a leading "/" causing classnames to have a leading "." (e.g. ".net.sf.mmm.util.filter.api.Filter").

This is an obvious bug that needs to be fixed.

The mmm website (maven site) is dirty rotten old.
We have to update urgently.

Proxies build by NlsBundleFactory shall be cached as well as their templates and arguments names to speed up from slow reflection.

We decided to go for JavaFx as it is more promising than we initially thought. Besides native desktop clients it can potentially lead us into the mobile world. Further we also want to create a web implementation based on javafx that offers a bridge to the browsers DOM and to the JavaScript world. That is all we need to make it possible even though it will still be very tough. In comparison to the GWT implementation this will require the java(fx) plugin available in the browser but therefore our client code is executed a true java so we skip additional compilation and all the limitations of GWT.

UnicodeUtil is quite a large and expensive animal. We need help in completing javadoc, adding more characters, improve on normalize2ascii, etc.

We introduced interfaces GenericEntity and RevisionedEntity that only contained the getters (getId(), getModificationCounter(), getRevision()) but no setters. The setters have only been part of the implementation and marked as protected.

However, copying an entity to a transfer-object, or other generic access needs to be able to set these attributes.
For simplicity we should have public setters via the API.

Like MessageFormat of the JDK, the NlsMessage used index-based parameters such as "{0}", "{1}", etc.
However this is a bad approach for maintenance and translations.
Hence we want to support named keys for parameters such as "{value}" or "{min}". As a key can be any string including numbers this approach will still be downward compatible.

We need to release mmm-client-ui and deploy to central repo.

We need to create a dialog framework with the following features:

• history management (browser back and forward-button, bookmarking of dialog state)
• embedding (opening dialog opens parent dialog recursive and embedding into slot of parent dialog)
• code-splitting (prevent that client has to be loaded as single large BLOB at startup)
• simple access to current dialogs by type
• separate dialog and popup(-dialog)