On Fri, 2002-04-05 at 17:50, John McNally wrote:
> 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.
1) Why do you need to put the dev jar into the repo when you just built
it from CVS? There is probably a very small group of people developing
Intake and the rest of the world doesn't need that dev jar. If it's a
serious issue and you need a feature because it is a show stopper then
in the case of the commons you could push for a release like you did
with the pool code and it will likely happen.
I mean, who is really going to benefit from the -dev JAR? Most of your
users don't care and if you have users that do care they aren't going to
be able to find the source for that -dev JAR very easily. When you
release a beta that requires some new feature in a product you don't
have control over you should use a date to check out that products
source and put that date on the JAR that you build so if people actually
want to look at the source for the JAR you're providing they can.
2) Are you going to continually release products based on unreleased
packages? As mentioned above what good is a JAR that someone can't
easily find the source for if they want to patch something. Using a -dev
JAR a user will more than likely find sources in HEAD that don't match.
We have had this complaint many times.
> 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.
What if you break another project you don't have access to? I just see
that -dev JAR thing as a rats nest of problems.
> 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.
Of course not. You've never done that and you likely never will.
> Though I
> also hear you saying I should be able to work with cvs builds. How do
> you propose I do it
By changing Maven to accept projects you wish to use from CVS sources,
or you build JARs and use install-jar target which I assume you've done
almost continually since the target was created in most of the build
files.
When you get near a release you push the producers of packages you need
to do a point release, or do the date tag thing to produce a JAR that
someone can find the sources for.
I suppose you could give Scarab clients a constant diet of -dev JARs but
they probably wouldn't like that I imagine.
I don't know what the perfect solution but I think that the repo isn't
the place for -dev snapshot JARs because all your developers can get the
code from CVS anyway. With potentially hundreds of packages in the repo
there is bound to be a problem with JARs that have no versioning like a
-dev JAR. The JAR may have a version if you did the CVS thing that jon
described, but again how do you find the sources?
>, 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.
I've mentioned numerous times that this is what will happen. I'm
planning on cleaning up the repo for maven b4. b3 will be this weekend
and b4 will be next weekend. I need to make the transformation for the
project descriptors so that users don't get bonked when I change the
version identifiers. After that point I will adhere to the versioning
document in jakarta-site2 and Sun's literature on versioning w.r.t to
version identifiers.
> 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.
I agree they should be identifiable by a version. No arguments there.
> 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]>
--
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]>
