On 9/28/06, shinsato <[EMAIL PROTECTED]> wrote:


We're using the retrotranslator plugin, which unfortunately isn't released
yet.  It's still in the sandbox.  Which breaks the release plugin (which
we
discover the day before we have to get our first ever maven executed
release
out).

Is there any way around this at all?  I'm a bit new to maven2 still, and
when I tried to do an internal release of retrotranslator, it was an
exercise in frustration.

Hopefully someone knows some possible way around this.  If not, does
anyone
have an idea how to get such a release accomplished.  There were snapshot
dependencies as well.  Is this going to require releasing every transitive
dependency too?  Please say there's a short cut around this...


The most important question here is not about your dependencies ... it is
about your own desires.  Why would you want to release something of your
own, based on a snapshot dependency, that might be broken if the dependency
developers later release an updated snapshot that is not compatible with
your own product?

The only reasonable alternatives are:

* Convince the developers of the packages you are dependent on to release a
  non-snapshot version of whatever you are depending on, so you can declare
  a dependency on that version.

* Remove the dependency on the snapshot code by providing equivalent
functionality
 in some other manner.

If you wish to choose a different approach, you are guaranteeing that people
like me will *never* *ever* trust any software you produce as being
something that can be depended on, because there is no way *you* can
guarantee that the snapshot based dependencies will not change in
incompatible ways after your release.

Note that this is not an issue specific to Maven -- it's all about how
serious you are about providing a stable (over time) ability to rebuild your
software from its sources.


     Thanks in advance,
      Harold Shinsato


Craig McClanahan

Reply via email to