Warp Projects Organization

[Patrick Lightbody]

Are there any plans to get the warp projects to be a bit more
organized? I'm honestly not trying to be rude or put the projects
down, as I'm really impressed with all of them. I just find that there
is some "chaos" going on right now that probably leads to a bit of an
uneasy feeling with people who might want to get started with Warp.
For example:

* warp-servlets is hosted in the warp-datagrid project
* warp-persist is hosted in the warp-core project
* there is no mention of warp-datagrid on any of the websites I've
seen (ie: wideplay.com only links to warp-persist and warp-servlet)
* http://code.google.com/p/warp-datagrid/ is described as "data
support for guice applications"

Etc etc. I'd be happy to help with some efforts, but I think first I
need to understand the overall vision of what you want to do and what
is currently there now.

Patrick

[Dhanji R. Prasanna]

Hi Patrick,

Yea, there is a bit of that =)

One of my biggest problems has been time, and that I've to do most of it myself. I've tried to drive everything from an organized page on http://www.wideplay.com , which is where the docs are hosted.

Regarding warp-servlet

warp-datagrid contained a couple of experiments. One of them was warp-servlet, which grew out into more popular use.

I wanted to get it merged with Guice, since warp-servlet is a superset of guice-servlet functionality, and IMO does it better (better integration with Wicket and Struts2). I will speak to Jesse about that soon. Otherwise, we should definitely move it out into its own project.

warp-datagrid should be deleted.

Regarding warp-persist

It's hosted in its own project. And intended to be the data-layer integration for Guice apps. Robbie's doing some great work extending it for 2.0 (multiple session factories, extensible persistence engine, etc.).

Regarding warp-widgets

It's still in alpha development so I don't mention it on wideplay. It's the first warp project but I renamed it after a major architecture redux (hence hosted at warp-core). It has a lot of links from all over, so I'm loathe to move it.

These are the only three projects we've got going. Would love some help, with either suggestions or contributions. The vision is for us to have a complete web-stack:

* RESTful web services + client

* Web framework (MVC)

* Managed Servlets + Filters

* with warp-persist acting as the persistence layer. 

These use cases seem to be the entirety of pain points for Guice users and users that are reluctant to migrate from Spring and other web frameworks. 

Our road map is something like this:

* multiple persistence units and extensibility for warp-persist (Robbie)

* web conversations (continuations) for warp-servlet

* fix static typing on warp-widgets

* RESTful web services for warp-widgets

* More tutorial-like docs

* Improve JavaDoc all around

* Create example apps for all three, and one proper example with all 3 in one.

I'm totally open to suggestions. What do others think?

Dhanji.

[Josh McDonald]

I think we need to rice up the pages a little bit, and perhaps put some more explanatory text about this up there :)

-Josh

--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."

:: Josh 'G-Funk' McDonald
:: 0437 221 380 :: jo...@gfunk007.com

[Andy Shen]

Hi Dhanji,

I like warp and I've been following the mailing list and repo for a while.
I agree with Patrick's comments, I think your vision and roadmap is
something that will be good to have on the project's website.
On top of that, maybe setup a wiki to organise info into more
structured so people can see the overall flow better.

Also move repos to github might make it easier for people to contribute.

Cheers,
Andy

On Mon, Aug 25, 2008 at 8:25 AM, Dhanji R. Prasanna <dha...@gmail.com> wrote:

[Dhanji R. Prasanna]

Thanks Andy. That's a good suggestion.

An update: I just spoke to Jesse and we will be merging warp-servlet with Guice. 

http://code.google.com/p/google-guice/issues/detail?id=239

Josh also kindly agreed to help set up a better website/wiki layout. So hopefully will have some improvement on that score soon. One issue that was brought up is that we host warp-widgets under project name "warp-core". I am loathe to move it since many pages link there. 

Do people have any suggestions? =)

warp-persist is going great, we'll add example/skeleton projects and a more Guice-like "User's Guide" soon.

Dhanji.

[Patrick Lightbody]

Re: the wiki/website... Google Code's wiki has some limitations to
what it can do. A better website of course is doable. If you did want
to explore other wiki options, JIRA Studio (hosted JIRA + Confluence +
other stuff) is free for open source projects I believe...

[Josh McDonald]

Just what I need, *another* Jira I have to interface with...

*shudder*

Dhanji, you know many googlers (no shit), somebody must know somebody who can help us get a redirect / rename on google code :)

-Josh

[Rex Sheng]

Exciting to hear that!

[Robbie Vanbrabant]

On Tue, Aug 26, 2008 at 2:32 AM, Dhanji R. Prasanna <dha...@gmail.com> wrote:

An update: I just spoke to Jesse and we will be merging warp-servlet with Guice. 

http://code.google.com/p/google-guice/issues/detail?id=239

Is he going to release it with Guice 2.0, or will it follow its own release schedule?
 

Do people have any suggestions? =)

For docs I would use Google Documentation Reader. It works with the wiki system on Google Code; you just have to create a page with a Table of Contents and Documentation Reader will generate the structure for you. As an example, GWT has recently switched to it: http://tinyurl.com/5zhucx
They created a separate documentation project, that's also something you could consider.

Robbie
 

[francisc...@gmail.com]

all this is great!
but if possible don't pick jira & co.... just stick to google code.

cheers, francisco

On 26 août, 10:20, "Robbie Vanbrabant" <robbie.vanbrab...@gmail.com>
wrote:

> On Tue, Aug 26, 2008 at 2:32 AM, Dhanji R. Prasanna <dha...@gmail.com>wrote:
>
> > An update: I just spoke to Jesse and we will be merging warp-servlet with
> > Guice.
> >http://code.google.com/p/google-guice/issues/detail?id=239
>
> Is he going to release it with Guice 2.0, or will it follow its own release
> schedule?
>

> > <http://code.google.com/p/google-guice/issues/detail?id=239>

[Gili Tzabari]

For what it's worth I actually prefer JIRA to Google's applications.

Gili

[Patrick Lightbody]

I do like the GWT docs structure - good suggestion!

(Sorry about starting a mini tools debate - didn't mean to do that.
I'm sure anything will be fine. Key thing is committing to more
organization no matter what the tool)

[Dhanji R. Prasanna]

Agreed. I'm on it.

Btw, anyone who's interested in reviewing or contributing docs please contact me directly.

Thanks!

Dhanji.

[famousactress]

For projects this 'young' I'd be terrified of how overwhelming a
public JIRA instance might get right now :)

Happy to hear that warp-servlet is merging with Guice! Are there ideas
about when Guice 2 will be released?

I like the GWT docs as well...

One of the other barriers I've been having with discovering what's
available in Warp is the lack of deployed Maven artifacts. I don't
really have a sense for how large the Maven community is, but for
those of us who use it.. it's definitely a slow-down to encounter a
project that we'd like to try out that isn't deployed. Is anyone else
here using Maven? I'm curious about whether or not supporting is is a
goal for the Warp crew.

Phill

On Aug 26, 6:37 am, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> Agreed. I'm on it.
> Btw, anyone who's interested in reviewing or contributing docs please
> contact me directly.
> Thanks!
>
> Dhanji.
>

[Dhanji R. Prasanna]

Good point about maven. This has been teetering at the edge of my todo list for a long time now. I don't really use it but it would be good for users for us to support it.

Anyone want to volunteer to help us get mavenized? I think we can either:

a) host a maven-style repo ourselves in the svn tree under dist/

b) upload to ibiblio (the former seems speedier)

We also need to:

a) write poms for warp-persist and warp-widgets (latter not so important, currently)

b) write optional deps for warp + hibernate, warp + jpa, etc. (is that how it works?)

c) write up some doc goodness

This may be a starting point (badly out of date): http://code.google.com/p/warp-core/wiki/WarpWithMaven2

Dhanji.

[Patrick Lightbody]

I'd be happy to convert the projects over to Maven. We can't decide on
whether to use ibiblio or something else at the end of the process,
since it's such as easy thing to switch around.

[Patrick Lightbody]

Sorry, I just realized I wrote "we can't" when I meant "we can".

The offer is still open :)

[Dhanji R. Prasanna]

Thanks. That would be fantastic! Let me know what you need from me.

Our primary build system will still be ant, however. So if there's a
good way to keep them synced that would be ideal.

Dhanji

[francisc...@gmail.com]

+1 for a maven repo

as for building with ant, you don't necessarily need to update/sync
your maven repo with daily snapshots... just put major releases, at
least to begin with.

in fact i'd like to have access to the warp-persist artifact. i've
developed a small utility (http://code.google.com/p/gluw) and along
with other guys from the wicket mailing list we'd like to include it
in an archetype... so i'll have to mavenize mine as well to be able to
pull dependencies automatically.

http://code.google.com/p/warp-core/wiki/WarpWithMaven2 seems to have
the poms almost ready. maybe somebody is already working on this (?)

i was also thinking that if you open the framework to pluggable
persistence strategies we could include all these as maven artifacts
in warp's repo. what do you think?

francisco

On Sep 1, 8:24 am, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> Thanks. That would be fantastic! Let me know what you need from me.
>
> Our primary build system will still be ant, however. So if there's a
> good way to keep them synced that would be ideal.
>
> Dhanji

> On 9/1/08, Patrick Lightbody <pligh...@gmail.com> wrote:
>
>
>
> > Sorry, I just realized I wrote "we can't" when I meant "we can".
>
> > The offer is still open :)
>

> > On Fri, Aug 29, 2008 at 5:31 AM, Patrick Lightbody <pligh...@gmail.com>

> > wrote:
> >> I'd be happy to convert the projects over to Maven. We can't decide on
> >> whether to use ibiblio or something else at the end of the process,
> >> since it's such as easy thing to switch around.
>
> >> On Thu, Aug 28, 2008 at 10:22 PM, Dhanji R. Prasanna <dha...@gmail.com>
> >> wrote:
> >>> Good point about maven. This has been teetering at the edge of my todo
> >>> list
> >>> for a long time now. I don't really use it but it would be good for users
> >>> for us to support it.
> >>> Anyone want to volunteer to help us get mavenized? I think we can either:
> >>> a) host a maven-style repo ourselves in the svn tree under dist/
> >>> b) upload to ibiblio (the former seems speedier)
> >>> We also need to:
> >>> a) write poms for warp-persist and warp-widgets (latter not so important,
> >>> currently)
> >>> b) write optional deps for warp + hibernate, warp + jpa, etc. (is that
> >>> how
> >>> it works?)
> >>> c) write up some doc goodness
> >>> This may be a starting point (badly out of
> >>> date):http://code.google.com/p/warp-core/wiki/WarpWithMaven2
> >>> Dhanji.

> >>> On Fri, Aug 29, 2008 at 2:25 PM, famousactress <famousactr...@gmail.com>

[Dhanji R. Prasanna]

On Fri, Sep 5, 2008 at 5:40 AM, francisc...@gmail.com <francisc...@gmail.com> wrote:

+1 for a maven repo

as for building with ant, you don't necessarily need to update/sync
your maven repo with daily snapshots... just put major releases, at
least to begin with.

in fact i'd like to have access to the warp-persist artifact. i've
developed a small utility (http://code.google.com/p/gluw) and along
with other guys from the wicket mailing list we'd like to include it
in an archetype... so i'll have to mavenize mine as well to be able to
pull dependencies automatically.

http://code.google.com/p/warp-core/wiki/WarpWithMaven2 seems to have
the poms almost ready. maybe somebody is already working on this (?)

i was also thinking that if you open the framework to pluggable
persistence strategies we could include all these as maven artifacts
in warp's repo. what do you think?

Yea sounds good to me. But how do you handle different versions? Do we always go with the latest Hibernate/db40/whatever? And how do you describe deps for JPA? (It's a standard so it can have any impl with a dynamic binding.)

These are things I never understood about maven. Perhaps Patrick can shed some light. =)

But yea, having a repo in svn and updating it occasionally with the poms & jars seems like it should be enough for users.

Dhanji.

[Robbie Vanbrabant]

I think we can flag our persistence engine dependencies as <optional>true</optional> or something. Then users will have to explicitly say they want the dependency otherwise they won't get it.

[Dhanji R. Prasanna]

Yea, of course. But we need to bind to a canonical version when the option is exercised. How should this work for JPA (default to Hibernate?).

Dhanji.

[francisc...@gmail.com]

perhaps defining everything in modules. when you need, for instance,
warp-persist-hibernate it'll pull this sub-project's pom (for
dependencies) *plus* it's parent pom warp-persist (for its
dependencies).
a nice (analogous) layout can be found in the salve project (http://
code.google.com/p/salve/source/browse/trunk), in particular how it
handles either spring or guice support (or both).

although i'm not sure we can accomplish something similar by only
using the maven:deploy plugin + ant. i'll dive into it such the need
arise.

dhanji, iirc, wasn't it that you could choose between jpa or hibernate
(even if hibernate ended up being your jpa impl)? usingJpa(),
usingHibernate() ?
i mean, if somebody requests "warp-persist-jpa" artifact, he should
take care of his persistence provider dependencies. otherwise it could
be tough to track all the dependencies of each and every jpa impl.

francisco

ps: i never used it, but wouldn't it be wiser to use ivy (http://
ant.apache.org/ivy/) if you plan to stick to ant for you builds? since
it can handle maven repos maybe it's a better option (?)

On Sep 5, 1:17 pm, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> Yea, of course. But we need to bind to a canonical version when the option
> is exercised. How should this work for JPA (default to Hibernate?).
> Dhanji.
>
> On Fri, Sep 5, 2008 at 6:55 PM, Robbie Vanbrabant <
>

> robbie.vanbrab...@gmail.com> wrote:
> > I think we can flag our persistence engine dependencies as
> > <optional>true</optional> or something. Then users will have to explicitly
> > say they want the dependency otherwise they won't get it.
>
> > On Fri, Sep 5, 2008 at 1:18 AM, Dhanji R. Prasanna <dha...@gmail.com>wrote:
>

> >> On Fri, Sep 5, 2008 at 5:40 AM, francisco.tre...@gmail.com <
> >> francisco.tre...@gmail.com> wrote:
>
> >>> +1 for a maven repo
>
> >>> as for building with ant, you don't necessarily need to update/sync
> >>> your maven repo with daily snapshots... just put major releases, at
> >>> least to begin with.
>
> >>> in fact i'd like to have access to the warp-persist artifact. i've
> >>> developed a small utility (http://code.google.com/p/gluw) and along
> >>> with other guys from the wicket mailing list we'd like to include it
> >>> in an archetype... so i'll have to mavenize mine as well to be able to
> >>> pull dependencies automatically.
>

> >>>http://code.google.com/p/warp-core/wiki/WarpWithMaven2seems to have

[Patrick Lightbody]

Francisco,
That's exactly right. That's the way to go. We can still roll up
everything in to a single jar to make non-maven use very easy still.

As for using Ivy - I've had a lot of experience with both and while
Maven can be a pain once in a while, overall it's just easier to work
with. The hodgepodge of Ant + Ivy (which these days is just a nice
interface in to the Maven world now that it supports poms) can be
annoying. I'd say either stick with Ant only or Maven only.

I'd be happy to take a stab and making the build in a branch so as not
to disrupt anything, and then if the team likes the results they can
choose to merge it in :)

Patrick

[Dhanji R. Prasanna]

Yea, branching is a good idea. That way Robbie's work on multimodules can go ahead unhindered.

Note that we're just doing this to support maven users (who complain that we don't have our jars in a mavenized repo), we're not changing our build system to maven. So Ivy vs. maven doesn't really enter into it.

Dhanji.

[francisc...@gmail.com]

i agree ant + maven:deploy (http://maven.apache.org/plugins/maven-
deploy-plugin/) is the way to go.

i believe there is no need to touch the current code whatsoever. so
not even worth branching: just a folder somewhere to stock the poms
layout (for maven modules) and the plugin configuration. which should
trigger ant for a build or directly go grab available major/minor/
whatever release jars, generate poms accordingly and copy the final
result to warp's repo, as dhanji suggested, in an svn folder.

this could also be interesting: http://weblogs.java.net/blog/kohsuke/archive/2008/07/deploying_nonma.html

francisco

On Sep 6, 1:08 am, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> Yea, branching is a good idea. That way Robbie's work on multimodules can go
> ahead unhindered.
> Note that we're just doing this to support maven users (who complain that we
> don't have our jars in a mavenized repo), we're not changing our build
> system to maven. So Ivy vs. maven doesn't really enter into it.
>
> Dhanji.
>

> On Fri, Sep 5, 2008 at 11:51 PM, Patrick Lightbody <pligh...@gmail.com>wrote:
>
>
>
> > Francisco,
> > That's exactly right. That's the way to go. We can still roll up
> > everything in to a single jar to make non-maven use very easy still.
>
> > As for using Ivy - I've had a lot of experience with both and while
> > Maven can be a pain once in a while, overall it's just easier to work
> > with. The hodgepodge of Ant + Ivy (which these days is just a nice
> > interface in to the Maven world now that it supports poms) can be
> > annoying. I'd say either stick with Ant only or Maven only.
>
> > I'd be happy to take a stab and making the build in a branch so as not
> > to disrupt anything, and then if the team likes the results they can
> > choose to merge it in :)
>
> > Patrick
>

> > >> >>>http://code.google.com/p/warp-core/wiki/WarpWithMaven2seemsto have

[Sebastian]

Hallo,

are there any news about maven support? Is warp-persist available in
any maven repository yet?
Thanks in advance.

Regards,

Sebastian

On 6 Sep., 12:45, "francisco.tre...@gmail.com"
<francisco.tre...@gmail.com> wrote:
> i agree ant +maven:deploy (http://maven.apache.org/plugins/maven-

> deploy-plugin/) is the way to go.
>
> i believe there is no need to touch the current code whatsoever. so
> not even worth branching: just a folder somewhere to stock the poms

> layout (formavenmodules) and the plugin configuration. which should

> trigger ant for a build or directly go grab available major/minor/
> whatever release jars, generate poms accordingly and copy the final
> result to warp's repo, as dhanji suggested, in an svn folder.
>

> this could also be interesting:http://weblogs.java.net/blog/kohsuke/archive/2008/07/deploying_nonma....

>
> francisco
>
> On Sep 6, 1:08 am, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
>
> > Yea, branching is a good idea. That way Robbie's work on multimodules can go
> > ahead unhindered.

> > Note that we're just doing this to supportmavenusers (who complain that we

> > don't have our jars in a mavenized repo), we're not changing our build

> > system tomaven. So Ivy vs.mavendoesn't really enter into it.

>
> > Dhanji.
>
> > On Fri, Sep 5, 2008 at 11:51 PM, Patrick Lightbody <pligh...@gmail.com>wrote:
>
> > > Francisco,
> > > That's exactly right. That's the way to go. We can still roll up

> > > everything in to a single jar to make non-mavenuse very easy still.

>
> > > As for using Ivy - I've had a lot of experience with both and while

> > >Mavencan be a pain once in a while, overall it's just easier to work

> > > with. The hodgepodge of Ant + Ivy (which these days is just a nice

> > > interface in to theMavenworld now that it supports poms) can be

> > > annoying. I'd say either stick with Ant only orMavenonly.
>
> > > I'd be happy to take a stab and making the build in a branch so as not
> > > to disrupt anything, and then if the team likes the results they can
> > > choose to merge it in :)
>
> > > Patrick
>
> > > On Fri, Sep 5, 2008 at 6:46 AM, francisco.tre...@gmail.com
> > > <francisco.tre...@gmail.com> wrote:
>
> > > > perhaps defining everything in modules. when you need, for instance,
> > > > warp-persist-hibernate it'll pull this sub-project's pom (for
> > > > dependencies) *plus* it's parent pom warp-persist (for its
> > > > dependencies).
> > > > a nice (analogous) layout can be found in the salve project (http://
> > > > code.google.com/p/salve/source/browse/trunk), in particular how it
> > > > handles either spring or guice support (or both).
>
> > > > although i'm not sure we can accomplish something similar by only

> > > > using themaven:deploy plugin + ant. i'll dive into it such the need

> > > > arise.
>
> > > > dhanji, iirc, wasn't it that you could choose between jpa or hibernate
> > > > (even if hibernate ended up being your jpa impl)?  usingJpa(),
> > > > usingHibernate() ?
> > > > i mean, if somebody requests "warp-persist-jpa" artifact, he should
> > > > take care of his persistence provider dependencies. otherwise it could
> > > > be tough to track all the dependencies of each and every jpa impl.
>
> > > > francisco
>
> > > > ps: i never used it, but wouldn't it be wiser to use ivy (http://
> > > > ant.apache.org/ivy/) if you plan to stick to ant for you builds? since

> > > > it can handlemavenrepos maybe it's a better option (?)

>
> > > > On Sep 5, 1:17 pm, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> > > >> Yea, of course. But we need to bind to a canonical version when the
> > > option
> > > >> is exercised. How should this work for JPA (default to Hibernate?).
> > > >> Dhanji.
>
> > > >> On Fri, Sep 5, 2008 at 6:55 PM, Robbie Vanbrabant <
>
> > > >> robbie.vanbrab...@gmail.com> wrote:
> > > >> > I think we can flag our persistence engine dependencies as
> > > >> > <optional>true</optional> or something. Then users will have to
> > > explicitly
> > > >> > say they want the dependency otherwise they won't get it.
>
> > > >> > On Fri, Sep 5, 2008 at 1:18 AM, Dhanji R. Prasanna <dha...@gmail.com
> > > >wrote:
>
> > > >> >> On Fri, Sep 5, 2008 at 5:40 AM, francisco.tre...@gmail.com <
> > > >> >> francisco.tre...@gmail.com> wrote:
>
> > > >> >>> +1 for amavenrepo
>
> > > >> >>> as for building with ant, you don't necessarily need to update/sync

> > > >> >>> yourmavenrepo with daily snapshots... just put major releases, at

> > > >> >>> least to begin with.
>
> > > >> >>> in fact i'd like to have access to the warp-persist artifact. i've
> > > >> >>> developed a small utility (http://code.google.com/p/gluw) and along
> > > >> >>> with other guys from the wicket mailing list we'd like to include it
> > > >> >>> in an archetype... so i'll have to mavenize mine as well to be able
> > > to
> > > >> >>> pull dependencies automatically.
>
> > > >> >>>http://code.google.com/p/warp-core/wiki/WarpWithMaven2seemstohave
> > > >> >>> the poms almost ready. maybe somebody is already working on this (?)
>
> > > >> >>> i was also thinking that if you open the framework to pluggable
> > > >> >>> persistence strategies we could include all these asmavenartifacts
> > > >> >>> in warp's repo. what do you think?
>
> > > >> >> Yea sounds good to me. But how do you handle different versions? Do
> > > we
> > > >> >> always go with the latest Hibernate/db40/whatever? And how do you
> > > describe
> > > >> >> deps for JPA? (It's a standard so it can have any impl with a dynamic
> > > >> >> binding.)
>

> > > >> >> These are things I never understood aboutmaven. Perhaps Patrick can

[Richard Wallace]

Here's another +1 for getting some kind maven repository setup.  I was looking last night at trying to get warp deployed to my own internal infrastructure and it would nice if I didn't have to. :)

[francisco treacy]

i just posted about neodatis integration and the availability of a maven repo.

http://warp-persist-neodatis.googlecode.com/svn/trunk/repo/

i'm keeping a warp-persist 2.0 snapshot there.

if somebody can provide a script we could automate the build and send
copies of the artifacts there (i can easily give access to any member
with a googlecode account).

francisco

[Dhanji R. Prasanna]

Cool, thanks francisco!

I'll provide a link to this from our home page.

[Rahul]

Dhanji,

To keep snapshots 'closer', how about create a Maven repo under Warp
SVN itself and include a reference in poms. I know this might not be
on a priority list but.... I can help :-)

Cheers,
Rahul

On Nov 12, 12:18 pm, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> Cool, thanks francisco!
> I'll provide a link to this from our home page.
>
> On Tue, Nov 11, 2008 at 1:03 PM, francisco treacy <
>

> francisco.tre...@gmail.com> wrote:
>
> > i just posted about neodatis integration and the availability of a maven
> > repo.
>
> >http://warp-persist-neodatis.googlecode.com/svn/trunk/repo/
>
> > i'm keeping a warp-persist 2.0 snapshot there.
>
> > if somebody can provide a script we could automate the build and send
> > copies of the artifacts there (i can easily give access to any member
> > with a googlecode account).
>
> > francisco
>

> > On Tue, Nov 11, 2008 at 6:30 PM, Richard Wallace <rwallace1...@gmail.com>

> > wrote:
> > > Here's another +1 for getting some kind maven repository setup.  I was
> > > looking last night at trying to get warp deployed to my own internal
> > > infrastructure and it would nice if I didn't have to. :)
>

> > > On Mon, Nov 3, 2008 at 11:17 PM, Sebastian <engel.sebast...@gmail.com>

[Robbie Vanbrabant]

I don't think it would be critical to have "real time" access to snapshots using Maven. For one, if you install them into the repository as SNAPSHOT, Maven will always download the latest snapshot automatically, which will potentially break your build if there are breaking changes. So I'd install date-tagged versions (that's how we now tag snapshots) and for now there's not much to gain by hosting such a repository in the warp-persist project.

If we do set up a semi-official WP repository, we should probably create a different project on Google Code so we avoid hitting our (theoretical) space constraints. The biggest problem with this is that Guice's story with Maven is also unclear. They do plan on publishing Guice 2.0 to the official Maven repositories, but if we're going to host Guice ourselves and possibly using a different groupId (com.google? com.google.code?) people will start getting conflicts once Guice hits the official repositories.

That said, I certainly applaud the current efforts. It's unfortunate that I have so little time to look at this at the moment, but if anyone can contribute a script that we can run during our build process we'll be happy to include that.

Robbie

[francisco treacy]

if you want to use warp-persist-neodatis' repo (ask me and i'll add
you as contributor), or warp-persist's, or any other - it's up to you.

this is the way to go:

http://maven.apache.org/ant-tasks/reference.html#install

anyone interested in creating an ant task to install/deploy to a
remote repo, that can be called from warp's build? i really have a
lack of time these days, but i'll stay tuned.

francisco

ps. regarding guice: so long as warp-persist is 2.0-SNAPSHOT, one
option could be stick to 1.0 (that is in the official repos -
http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/) and
switch to guice 2.0 when its published. as maven clients will be
always requesting the latest pom, you can be sure they'll be
up-to-date and then release a non-snapshot warp-persist maven artifact
w/ guice 2.0.