You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2007/07/20 03:13:57 UTC
[M2 build design] - research branch M2-J2-REDUX experiences
Ate Douma wrote:
> Dear community,
>
> With finally the release for Jetspeed-2.1.2 behind us, the time has come
> to think of and start some large scale enhancements and changes.
>
> Some of the biggest improvements and features on my wish list, and for
> which I already know others have interest in too, are:
> - moving from our maven-1 and maven-2 hybrid build environment to *one*,
<snip/>
As promised, I'll provide my view on and experiences so far with creating a new maven-2 only build system for Jetspeed-2.
I already started out experimenting with a clean maven-2 build in a separate branch, J2-M2-REDUX, end March and a little bit more in April and May.
Note: because of lack of time then, this branch doesn't yet provide a a complete working environment in which you can build a full portal.
I'll start the discussion with the list of the features and goals I had then, and which I still think we need to realize with a new maven-2 build system.
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.
The general complaint is: maven is too complex, too unreliable, and there are too many settings to configure, most of them under documented or require deep
knowledge of the build environment to make proper use of.
I think (a maybe large) part of their problems are caused by our weird (mis)use of maven (1 & 2), but besides that, for users/shops mostly familiar with ant
maven is still viewed as an ugly and too far over-engineered beast.
For the first group, the "core" developers, we usually manage (and are allowed!) to tweak our own environments and mostly get along even with our current
build system.
Derived from these experiences, David Taylor and I concluded we should:
a) try to reduce the number of settings needed to be customized as much as possible
b) try to keep usage of maven-2 profiles as small as possible
c) move the applications *and* portal projects out of the main / core build project
d) provide sets of easy to extend/adapt assembly projects for creation of a custom portal, with the "default" and "demo" portals as well as the installers
being just examples of those
e) provide custom maven-2 plugins to help, automate and simplify complex configuration/build steps for end-users, integrators and core portal developers
f) try to provide an ant script library which can be used to setup ant based build environments, and "hide" maven-2 by using the maven tasks for ant tools
Important note: it is *not* my goal to replace maven-2 with ant for the jetspeed-2 project development itself but just to provide an alternative solution
for the end-users and integrators.
2) Provide a straightforward solution for generating database schema's and bootstrapping and seeding a database, including for component (JUnit) tests.
Our current build system is dramatically broken in this regard and even makes it impossible to build with maven-1 from scratch without "bootstrapping"
the maven-1 repository first because we're stuck with circular dependencies and some components just don't compile otherwise.
Right now, if I need to start a new Jetspeed-2 version, I first build with maven-2, then copy over all the installed jars into the maven-1 repository.
And only after this "bootstrapping" it is possible to build with maven-1 again.
And for running testcases on a certain component, you need to do a full build first too as we dropped our handcoded sql data seed scripts
(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.
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.
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.
Our current build setup makes it very difficult to run JUnit tests from within Eclipse as soon as for instance database or other configurations are needed.
And our current Eclipse (maven-1 based) classpath setting is a manually maintained single classpath for the whole of the project.
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.
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
- specific application server (e.g. Tomcat/Jetty/whatever), database (driver, url) configurations and possibly even an embedded LDAP (ADS) server
- the Jetspeed-2 Spring assemblies
- decorators
- standard/demo psml files (possible to be loaded into a database)
Some of these resources are now scattered through the code base. For maven-1, we package these in our maven plugin itself which more or less works, but for
maven-2 we don't even have a proper solution yet.
This is a diffcult issue to solve in a satisfactory way, for the J2-M2-REDUX branch I moved all of these to a new subproject (jetspeed-portal-resources).
The jetspeed-portal-resources project delivers a .jar artifact containing all of the above. And, by using a custom maven-2 plugin you can "install"
pattern based selected resources from this artifact in your own project target.
I'm still not satisfied by this solution those, even though it works. For one, this solution probably makes proper WTP much more difficult.
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.
I hope the above makes a little sense, and I'd like to hear what others opinions are.
I'm sure I haven't touched every aspect we should cover for a new maven-2 environemnt, and I also don't think I did everything right in the J2-M2-REDUX branch.
But I would like to ask those interested in all this to please check it out, try building it and review it a bit.
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
with them. I'm sure there are others much more experienced with this and I hope they will help and point out the stupid mistakes I made :)
I'm definitely not sure yet I choose the right way to go so any type of critics is welcome!
I will be gone on a 3 weeks summer holiday after tomorrow, and most likely won't touch or even see a keyboard during that time.
So any feedback is welcome, but it'll be a few weeks before I'll be able to respond again.
Just don't wait for me to respond and discuss :)
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] - research branch M2-J2-REDUX experiences
Posted by Ate Douma <at...@douma.nu>.
David Jencks wrote:
> This looks great to me, a lot of it is what I was hoping for when I
> tried messing with the build :-)
>
> Just in case I find myself with time on my hands before you get back, do
> you think it would be more appropriate to update your J2-M2-REDUX to the
> current code base or start over?
As you might have noticed, I'm going to start over as the J2-M2-REDUX branch original baseline (Jetspeed-2.1) is too far out-of-sync with the current trunk for
it to be worthwhile.
>
> thanks
> david jencks
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] - research branch M2-J2-REDUX experiences
Posted by David Jencks <da...@yahoo.com>.
This looks great to me, a lot of it is what I was hoping for when I
tried messing with the build :-)
Just in case I find myself with time on my hands before you get back,
do you think it would be more appropriate to update your J2-M2-REDUX
to the current code base or start over?
thanks
david jencks
On Jul 19, 2007, at 6:13 PM, Ate Douma wrote:
> Ate Douma wrote:
>> Dear community,
>>
>> With finally the release for Jetspeed-2.1.2 behind us, the time
>> has come
>> to think of and start some large scale enhancements and changes.
>>
>> Some of the biggest improvements and features on my wish list, and
>> for
>> which I already know others have interest in too, are:
>> - moving from our maven-1 and maven-2 hybrid build environment to
>> *one*,
> <snip/>
>
> As promised, I'll provide my view on and experiences so far with
> creating a new maven-2 only build system for Jetspeed-2.
> I already started out experimenting with a clean maven-2 build in a
> separate branch, J2-M2-REDUX, end March and a little bit more in
> April and May.
> Note: because of lack of time then, this branch doesn't yet provide
> a a complete working environment in which you can build a full portal.
>
> I'll start the discussion with the list of the features and goals I
> had then, and which I still think we need to realize with a new
> maven-2 build system.
>
> 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.
> The general complaint is: maven is too complex, too unreliable,
> and there are too many settings to configure, most of them under
> documented or require deep
> knowledge of the build environment to make proper use of.
>
> I think (a maybe large) part of their problems are caused by our
> weird (mis)use of maven (1 & 2), but besides that, for users/shops
> mostly familiar with ant
> maven is still viewed as an ugly and too far over-engineered beast.
>
> For the first group, the "core" developers, we usually manage
> (and are allowed!) to tweak our own environments and mostly get
> along even with our current
> build system.
>
> Derived from these experiences, David Taylor and I concluded we
> should:
> a) try to reduce the number of settings needed to be customized
> as much as possible
> b) try to keep usage of maven-2 profiles as small as possible
> c) move the applications *and* portal projects out of the main /
> core build project
> d) provide sets of easy to extend/adapt assembly projects for
> creation of a custom portal, with the "default" and "demo" portals
> as well as the installers
> being just examples of those
> e) provide custom maven-2 plugins to help, automate and simplify
> complex configuration/build steps for end-users, integrators and
> core portal developers
> f) try to provide an ant script library which can be used to
> setup ant based build environments, and "hide" maven-2 by using the
> maven tasks for ant tools
> Important note: it is *not* my goal to replace maven-2 with
> ant for the jetspeed-2 project development itself but just to
> provide an alternative solution
> for the end-users and integrators.
>
> 2) Provide a straightforward solution for generating database
> schema's and bootstrapping and seeding a database, including for
> component (JUnit) tests.
> Our current build system is dramatically broken in this regard
> and even makes it impossible to build with maven-1 from scratch
> without "bootstrapping"
> the maven-1 repository first because we're stuck with circular
> dependencies and some components just don't compile otherwise.
>
> Right now, if I need to start a new Jetspeed-2 version, I first
> build with maven-2, then copy over all the installed jars into the
> maven-1 repository.
> And only after this "bootstrapping" it is possible to build with
> maven-1 again.
>
> And for running testcases on a certain component, you need to do
> a full build first too as we dropped our handcoded sql data seed
> scripts
> (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.
>
> 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.
>
> 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.
>
> Our current build setup makes it very difficult to run JUnit
> tests from within Eclipse as soon as for instance database or other
> configurations are needed.
>
> And our current Eclipse (maven-1 based) classpath setting is a
> manually maintained single classpath for the whole of the project.
> 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.
>
> 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
> - specific application server (e.g. Tomcat/Jetty/whatever),
> database (driver, url) configurations and possibly even an embedded
> LDAP (ADS) server
> - the Jetspeed-2 Spring assemblies
> - decorators
> - standard/demo psml files (possible to be loaded into a database)
>
> Some of these resources are now scattered through the code base.
> For maven-1, we package these in our maven plugin itself which more
> or less works, but for
> maven-2 we don't even have a proper solution yet.
>
> This is a diffcult issue to solve in a satisfactory way, for the
> J2-M2-REDUX branch I moved all of these to a new subproject
> (jetspeed-portal-resources).
> The jetspeed-portal-resources project delivers a .jar artifact
> containing all of the above. And, by using a custom maven-2 plugin
> you can "install"
> pattern based selected resources from this artifact in your own
> project target.
> I'm still not satisfied by this solution those, even though it
> works. For one, this solution probably makes proper WTP much more
> difficult.
>
> 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.
>
> I hope the above makes a little sense, and I'd like to hear what
> others opinions are.
>
> I'm sure I haven't touched every aspect we should cover for a new
> maven-2 environemnt, and I also don't think I did everything right
> in the J2-M2-REDUX branch.
>
> But I would like to ask those interested in all this to please
> check it out, try building it and review it a bit.
>
> 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 with them. I'm sure there are others much
> more experienced with this and I hope they will help and point out
> the stupid mistakes I made :)
> I'm definitely not sure yet I choose the right way to go so any
> type of critics is welcome!
>
> I will be gone on a 3 weeks summer holiday after tomorrow, and most
> likely won't touch or even see a keyboard during that time.
> So any feedback is welcome, but it'll be a few weeks before I'll be
> able to respond again.
> Just don't wait for me to respond and discuss :)
>
> Regards,
>
> Ate
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] - research branch M2-J2-REDUX experiences
Posted by Ate Douma <at...@douma.nu>.
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: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [M2 build design] - research branch M2-J2-REDUX experiences
Posted by Elliot Metsger <em...@jhu.edu>.
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.
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.
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).
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.
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 :-)
Elliot
--
View this message in context: http://www.nabble.com/-M2-build-design----research-branch-M2-J2-REDUX-experiences-tf4114611.html#a11724196
Sent from the Jetspeed - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org