FYI I just submitted a maven build system patch for Roller JIRA ROL-1537 For more information see
http://opensource.atlassian.com/projects/roller/browse/ROL-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

I hope you find it usefull. Within minutes you should be able to mvn install and mvn jetty:run-war to run and test out your favorite weblogger built with maven from within jetty ;).

regards
  Peter Petersson


Peter Petersson wrote:
Hi there Roller devs!

I have put together a small patch (see #ROL-1527) that enables you to deploy the roller-weblogger.war file into a maven repository via a ant target. This patch will (among other things) greatly help the Geronimo dev team to continue the work on the geronimo roller plugin.

I have also done some work on a "complete" maven build system patch for roller that I hope to be able to submit soon for you to evaluate. This will eventually let you do all that you can do with the ant build system plus the extra flexibility and candy maven offers. At this writing the jars and wars created by maven is nearly identical to the ant counterparts and AFAICT the differences is due to a newer version of openjpa (v0.9.8 and its dependency, I could not find the 0.9.7 version in the maven repository) plus some maven manifest stuff. I am currently looking in to some extra maven stuff and possibly some test cases. This patch is done with as little impact as possible on the current roller project structure and dose not change any of the current structure except from adding some maven pom files and directories.

regards
  Peter Petersson

Dave wrote:
On 7/18/07, David Jencks <[EMAIL PROTECTED]> wrote:
I've been working with Peter Petersson to get roller 4 running on
geronimo 2, and we've now succeeded.  As a result we have some ideas
to make roller more javaee friendly and geronimo friendly.

1. Provide an option to look up the EntityManagerFactory in jndi
rather than constructing it through java code.  Generally in ee5 app
servers you want to use the ee5 mechanisms to access the ee5
features :-) so just as there is an option to look up the datasource
in jndi rather than using a Driver class directly, it would be great
to have the option to look up the EMF in jndi as well.  I don't see a
convenient way to use the ee5 injection features since AFAICT there
aren't any managed objects (servlets, filters, listeners, or jsf
managed beans) very near the code that needs the EMF.  I've
implemented this and it works in geronimo, see ROL-1482.  The only
possibly objectionable part of this patch I can imagine is the switch
to the servlet 2.5 schema for the persistence unit ref.  In geronimo
at least we can work around a 2.4 web.xml if you don't want to
upgrade yet: the remainder of the patch would still be extremely
helpful.

I don't think we want to require 2.5 yet.

Thanks for the contribution, but I'm -1 on the patch because it does
not address how to configure the EMF used by the Planet subsystem.

I'm not necessarily opposed to making the EMF configurable, but I
don't need it and I'm not prepared to test it -- so I'm not overly
inclined to apply the patch even when it handles both RollerPU and
PlanetPU.

Out of curiousity, what advantage does looking up the EMF instead of
the DataSource via JNDI give to our users?


2.jpa mapping info.  I notice you are currently using orm.xml files.
Do you have plans to move to annotations, and is anyone working on
that?  Also IIUC it's possible to make the annotations or orm files
match the script generated schema more closely by including stuff
like column sizes, does anyone have an opinion on if that is desirable?

I think consensus is that annotations are better here, but we haven't
had the time yet to move from XML files to annotations.


3. For deployment in geronimo, and use in a geronimo plugin, we need
to get at at least the roller war and possibly some inner details
such as the core jar.  It would be most convenient for us if these
were available through a maven repository.  So this leads to the
questions...

3a. Would you consider including some use of the maven ant tasks in
the ant build scripts to get various artifacts into maven repositories?

Yes.


3b Are you completely thrilled with the ant build or would you be
interested in considering a maven build system?

I satisfied with Ant and have had nothing but trouble with Maven.
Every time I've used it I've run into problems that I could not debug
due to its black-box nature.

I understand there are advantages to moving to Maven, and all of my
previous troubles might have been stupid user-error on my part, but at
this time I'm not interested in doing the work to rewrite the build.
If somebody else did the work, I'd be happy to consider their
patch/branch.

- Dave


Reply via email to