Hypothetically, I want to add some functionality to intake that uses
something in the latest cvs code of commons-foo. There is a
commons-foo.jar in the repo that is version 1.3.1.
It would seem I should be able to put a commons-foo-dev.jar into the
repo, so that I can develop this addition to intake. Having done this,
I have to be aware that commons-foo-dev is not a static target and I may
have to fix fulcrum when a change to commons-foo-dev.jar breaks it.
You seem to be saying you want me to wait on developing in intake until
the commons-foo project gets around to making another release. Though I
also hear you saying I should be able to work with cvs builds. How do
you propose I do it, if the commons-foo.jar namespace has been reserved
for version 1.3.1?
Aside:
I do not know why it has to be named commons-foo.jar, just because foo's
build system named it that. Change the name to commons-foo-1.3.1.jar or
put it into a versioned directory. I do not care either way, just don't
name it ${lib.repo}/commons-foo.jar.
commons-beanutils names all of its jars commons-beanutils.jar. I don't
know why version 1.2 has any more rights to the name than the cvs
version which also builds commons-beanutils.jar.
john mcnally
Jason van Zyl wrote:
>
> On Fri, 2002-04-05 at 13:19, John McNally wrote:
> > As I was the one that checked in the latest beanutils that started this
> > can I ask what was broken? You say it was because it used
> > commons-logging but I updated that as well. I did check that it did not
> > break stratum, torque, fulcrum and t3. And the reason I updated was
> > that I knew at that point that the head of beanutils would work for
> > these packages, I did not know whether any other revision would work.
> >
> > Since there several versions of beanutils, it makes sense to me that the
> > commons-beanutils.jar filename would refer to the latest code.
>
> The latest released code? Or the latest code in CVS? This is the problem
> I have in sticking dev snapshots in the repository. If there are issues
> that have been resolved in a package then the producer of that package
> should pushed to do a point release. Can you imagine having a 1000
> different packages in the repository where there was a development
> snapshot of any given number of those packages? I think things would
> fall apart pretty quickly because no rigor is required to push up a JAR
> that was built from CVS.
>
> > Are you
> > saying an unversioned filename should always refer to the latest
> > released version of a library?
>
> No. For the commons-beanutils JAR the name it has is the name that its
> build process produces. When I rename everything according to the
> version document and Sun's guidelines it will be
> commons-beanutils-1.0.jar (or whatever it's at).
>
> > If so I propose we use the convention
> > commons-beanutils-HEAD.jar or commons-beanutils-dev.jar to mean the
> > library built from the latest cvs. I guess I did not follow the
> > decision process on unversioned filenames, what was the conclusion (if
> > it is a simple one liner)?
>
> I'm not sure about the exact details of how the repository is going to
> work, but I would like to promote a stringent form of versioning that is
> specified in the <dependencies> and the promotion of using releases and
> making more of them when necessary. So either the JAR would have the
> version in it or a directory structure following the versioning
> conventions with versionless JAR names. I would like to start with
> versions in the JAR names because that's easier. With Maven if the
> structure changes users won't be affected.
>
> > The solution above is simpler than going to cvs, though that might be a
> > good idea. In my proposal, if a project chooses to use the c-b-dev.jar
> > (or c-b.jar whichever is decided means HEAD code), then it is that
> > projects' responsibility to fix any breakage due to someone else
> > updating the repo.
>
> If that JAR is released version and there has been proper deprecation
> but I don't think this would be good for dev snapshots. If I follow a
> project can put a JAR in the repo and everyone is forced to update their
> source?
>
> > It is a good idea to email the list noting that a
> > dev jar has been updated, though with all the lists and the fact that it
> > could be breaking an outside app, I do not see how a developer updating
> > the dev jar can be expected to know exactly where to note the change.
>
> That's the whole problem with dev JARs, no rigor. I think a build system
> that accommodated building from CVS would be better for the situation
> that we typically work in and pushing for more point releases is better
> then putting dev snapshots into the repo.
>
> Who are the clients for dev snapshots? Aren't the same clients going to
> be able to build from CVS (say Scarab developers)? If they aren't then
> I'm willing to be that those clients (Scarab users lets say) would be
> far more interested in a point release.
>
> > john mcnally
> >
> >
>
> --
> jvz.
>
> Jason van Zyl
> [EMAIL PROTECTED]
>
> http://tambora.zenplex.org
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
