struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [Standalone Tiles] Major Refactoring (Long)
Date Sat, 03 Dec 2005 18:33:27 GMT
On 12/3/05, Joe Germuska <> wrote:
> At 11:19 PM -0700 12/2/05, Wendy Smoak wrote:
> >On 12/2/05, Joe Germuska <> wrote:
> >
> >>  In short, it builds a JAR with a timestamped version (like
> >>  struts-core-20051106.203359.jar) and then makes a copy of it with the
> >>  name struts-core-SNAPSHOT.jar  So for my team, if we are depending on
> >>  a nightly build, we use the timestamped version, not the SNAPSHOT, so
> >>  that there is no inconsistency.
> >
> >(The artifact plugin was finally convinced to cooperate.)  Before I
> >deleted them, had:
> >
> >tiles-core-0.2-20051203.055551.jar      02-Dec-2005 21:56   82K
> >tiles-core-0.2-20051203.060733.jar      02-Dec-2005 22:07   82K
> >tiles-core-0.2-SNAPSHOT.jar             02-Dec-2005 22:07   82K
> >tiles-core-SNAPSHOT.jar                 30-Aug-2005 21:27  106K
> >(plus all the signatures and metadata)
> >
> >A Joe explained, you can declare a dependency on a particular snapshot
> >and not have to worry about Maven retrieving the latest version.
> do we want to remove tiles-core-SNAPSHOT.jar ?  I'm afraid there
> might be confusion; from the listing details, it's clearly not the
> same as the other files (is that 24K the result of Greg's aggressive
> pruning?  Nice work! ;-) )
> I think we should disclaim any responsibility for maintaining
> specific JARs in the repository; if people are
> depending on SNAPSHOTS, they should be prepared for things possibly
> being removed.  Is that fair?

That certainly makes some logical sense ... but it has a down side too.
Another project's trunk cannot do any useful development against the trunk
build of Standalone Tiles at all, because there's no guarantee that I can
download the source of the dependent project, use Maven or Ant to pull down
the dependencies, and know that I'm going to be able to retrieve it.  The
only option would be to package the binary jar that was used (say, with this
particular daily build) and then have to corrupt the build scripts to use
that instead of the usual dependency.

Of course, the other approach to this problem is to do 0.1, 0.2 types of
snapshot releases on the way towards a refactored 1.0.  Then, at least, you
can point at a dependency that is likely to be there for a while.

(In case it's not obvious, the "dependent project" in this case is Shale



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message