Stupid question maybe, but can we deprecate the method using
o.c.d.s.Sink, and duplicate the method to one that takes an
o.a.m.d.s.Sink instance? Then at least we may be able to soften the
eventual blow of moving off to the new APIs at some later time.
Other than this, it all sounds great. BTW, Jason has also offered to
help out with releasing duty...I'm not sure whether you're still having
problems with deployment permissions on files (see email from Vincent
re: integration testing), but I'm grateful to have the backup! :)
I'm probably going to call a vote for releasing the first version of the
it plugin today, and try to get it out next weekend when I hit the
in-laws' house...I don't think it should wait until January.
Let me know what you think.
-john
Brett Porter wrote:
Ok, we only need to match up the sink, and by doing that in the api that
takes care of it. Everything is in the impl and selected by the
reporting plugin. If it upgrades to a new one, they need to change all
their references. I've tried this, and as long as the references are
updated correctly, it works.
The only limitation is that MavenReport must continue to use
o.c.d.s.Sink, not o.a.m.d.s.Sink to remain compatible.
- Brett
Brett Porter wrote:
John Casey wrote:
I was planning to release a RC version tonight, but if you think you
can make improvements in this Doxia two-step we're putting together
here, I think that is more important than a couple of days' time. I'll
spend my time in more productive ways - namely, documenting the
release process I used for 2.0.1, and the pitfalls that I experienced.
Cool. Since you are going on holidays, I'll take up the release duties.
Merry Christmas! :)
I was simply going through the apis available to any report and making
them look exactly as they would have if the package hadn't changed.
For example, the concrete classes became wrappers around the new
classes from org.apache.maven.doxia.* so that anyone who had cast them
to the concrete classes passed back would have the same API to code
against...I know that type of casting is generally a no-no, but I
wanted to avoid breaking compatibility, even at that level.
Admittedly, this compat layer was done in a fairly quick-and-dirty
fashion, so whatever you think needs to go, I have no objections...
Unfortunately, I think that we get in a bind here with it being
backwards compat, but not forwards compat (ie you can't upgrade to a
more recent doxia). That's basically what I saw on the site plugin. I'll
take a closer look, but I think we only need the interfaces and will
have to live with the other limitations. I will test it against all the
reports we have released.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
