Elliot Metsger wrote:
Ate Douma wrote:
1) Recognize the fact we have two main groups of users:
- developers working directly off the source tree, this includes the
jetspeed committers
- end-users and integrators building a customized portal
We've had a lot of complaints from people out of the latter group who
don't like maven (1 & 2), and/or have a hard time customizing/tuning it to
their needs.
Yes, that has been my experience as well. In other projects that I'm
involved in that use M2, ant tasks/scripts have been supplied and M2 plugins
written as well. Mostly this revolved around packaging and deployment of
the portal, and deployment of portlets. And like you state elsewhere in the
email, the Ant builds in these projects were _not_ meant to replace M2, but
to provide an easy way for deployers to execute common tasks.
Ate Douma wrote:
2) Provide a straightforward solution for generating database schema's and
bootstrapping and seeding a database, including for component (JUnit)
tests.
Again, having no experience with Jetspeed internals (e.g. the Jetspeed
Serializer), I don't know if this is possible or not.
In other M2 projects I've used a mixture of:
* the Hibernate M2 plugin to generate the DDL for table schema (based off
of a Hibernate mapping describing the table structures). Note that your
code doesn't have to use Hibernate, you're just using it to generate DDL,
giving you flexibility to test with multiple databases.
* DBUnit for executing the table creation DDL, and for (un)loading
sample/test data into the DB
* actual unit tests extend Spring's
AbstractDependencyInjectionSpringContextTests, so Spring-managed components
can be injected into the test fixtures.
* Using HSQL's in-memory DB as the backend for the tests.
Both Hibernate and DBUnit aren't available to us as Apache project because of
their LGPL license.
Ate Douma wrote:
(which I find a good thing by the way) and now "seed" the data from
xml with the JetspeedSerializer. But the current JetspeedSerializer
component depends on
almost all other (database related) components thereby introducing
very nasty circular dependencies.
This is a clear design error which needs to be fixed, which I think I
already managed to do in the J2-M2-REDUX branch but I had to almost
completely
rewrite the JetspeedSerializer for it.
DBUnit may help here, I don't know (I'm totally ignorant of the
JetspeedSerializer). DBUnit (AFAIK) can't create tables for you (but that
can be easily implemented using Spring JDBC and the Hibernate DDL
generator), but it is able to (de)serialize table data to/from the database
from multiple formats, including XML. The DBUnit XML format is easy to
understand, so you can hand code the seed data it if you want. But it is
also easy to use its export capabilities to produce the seed data from an
existing database.
The JetspeedSerializer component was created to support database independence allowing export and subsequent import of Jetspeed-2 data across (different)
databases and version changes.
Ate Douma wrote:
3) Restructure our project and sub project source and resource folders in
compliance with the recommended maven-2 foldering.
We're still using what I think is pre-maven-1.0 folder structures and
this makes our project/pom definitions far more complex than needs be.
I agree. Just use M2's default folder structure: this will get you a long
way to supporting your first goal.
Ate Douma wrote:
4) Provide (at least) proper Eclipse debugging and WTP support for easy
building, deploying and testing the portal, portlet applications and our
JUnit tests
from within Eclipse. Providing other IDE support like maybe for
Netbeans and IntelliJ is also fine by me.
Ate Douma wrote:
I know Eclipse - maven-2 integration isn't perfect, especially when using
subprojects as Eclipse still cannot handle that properly, but I definitely
think
we need to switch to using the maven-eclipse plugin to generate our
projects.
m2eclipse works reasonably well. I know that the plugin has been stuck on
the 0.0.10 release for some time, but I do believe they are working towards
a 0.0.11 release.
Ate Douma wrote:
5) Provide a proper solution to "package" and "deliver" our
default/required portal resources as well as making it easy to extend
and/or override subsets of it.
For setting up a Jetspeed-2 portal, a lot of resources are needed:
- database ddl scripts
- initial database seed data
Perhaps Hibernate's DDL/DBunit can also help with packaging, not just
testing.
Ate Douma wrote:
- specific application server (e.g. Tomcat/Jetty/whatever), database
(driver, url) configurations and possibly even an embedded LDAP (ADS)
server
Yes, Apache DS is pretty easy to embed. I was working on that for uPortal 3
(before that code was sandboxed - it will not be released due to lack of
developer resources).
Cool, maybe you might be interested to work on that again for Jetspeed-2 (lite)
sometime?
Ate Douma wrote:
6) Drop torque schema generation for DDLUtils which I think has more
momentum and much better runtime support.
In the J2-M2-REDUX branch I wrote a maven-2 plugin for this as well as
an ddl and sql scripts executing plugin for creating databases.
Cool, I never heard of DDLUtils.
http://db.apache.org/ddlutils/
Ate Douma wrote:
I hope the above makes a little sense, and I'd like to hear what others
opinions are.
<snip>
I'm not an maven-2 expert and had to learn a lot by trial and error as
some maven plugins behave weird in my view, but probably because of my
lack of experience
I'll try to find some cycles to check it out. And no, it is not a issue of
expertise. Some of the plugins *are* weird :-)
Glad I'm not the only one thinking that :)
Elliot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
