Re: Prevayler 2.4 in Git & XStream 1.3.1?

"Justin T. Sampson" <[email protected]>
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
Howdy,

As for Prevayler versions, 2.3 is pretty solid, and I'd recommend using it.
Everything I've done post-2.3 is almost entirely source-compatible with 2.3,
so when we do get around to another release there won't be much for users to
change.

There are two post-2.3 branches in Git, "master" and "java5_experiment". The
latter has some interesting stuff but I got disillusioned with how the
generics were working and stopped working on it a few years ago. The
"master" branch is more conservative, and I got really close to finishing up
a 2.4 release when I was between jobs about a year ago. The main remaining
issue is just cleaning up some remaining build messiness after I had
migrated from Ant to Maven, and doing some final testing.

As for XStream, I did use it with Prevayler on a project several years ago
and we were pretty happy with it. I don't know what they've changed
recently, but I was building and testing Prevayler against XStream 1.3.1 on
the master branch last year and it seems to work just fine.

Cheers,
Justin


On Tue, Dec 1, 2009 at 9:06 AM, Matt Passell <[email protected]
> wrote:

> Hi Justin and Klaus (and anyone else who'd like to chime in),
>
> I was thinking of using Prevayler with the XStreamSerializer and I had
> three questions...
>
> My client's product already uses the latest version of XStream.  I looked
> at the code in XStreamSerializer and saw that it was extremely simple (yay!)
> and didn't exercise much of the XStream API (yay!).  Do you know of any
> reason that Prevayler wouldn't work with XStream v1.3.1?
>
> The product also has some XML files that are represented in memory as JDOM
> documents/elements.  Every time the in-memory representation is changed, the
> graph is marshalled to XML and written to disk. (Ack!)  Although it might
> not be a typical use of Prevayler, can you think of any reason it wouldn't
> work to write and use a simple, specialized JDOMSerializer as a snapshot
> Serializer?  That way, the changes to the XML structure could be saved
> incrementally (probably using standard serialization or XStream), while the
> base file (now used to represent the snapshot) could continue to exist with
> the same format.
>
> Finally, I browsed around a bit in the Git repository and noticed that
> there have been quite a few changes since 2.3 was released.  Is there likely
> to be a new release any time soon?  If not, would you recommend using either
> a current snapshot or one from a particular date?
>
> Thanks,
> Matt
>
> p.s. Looking forward to actually using Prevayler after first encountering
> it *years* ago. :)
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>
>

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.