You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@zenplex.com> on 2002/04/04 16:59:00 UTC
Updating the repository
Hi,
I just got back online and notice that the maven bootstrap is broken.
It is broken because someone updated the beanutils jar with an
unreleased version which breaks everything because it has
commons-logging stuff.
This is a process that has to be dealt with but if you intend to update
something please post a note first. The JARs in the repo can't be
changed willy-nilly with the latest CVS builds or you can potentially
break a lot of people's code. The maven bootstrap is an example of this.
I will try to get a logging process going and a target in the maven
build system so that we can track changes in the central repository. The
beanutils that works has been put back.
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-04-04 at 18:34, Jon Scott Stevens wrote:
> on 4/4/02 2:52 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
> > They are not using CVS for their distribution mechanism
> > and I would be curious as to know why as they obviously have a model
> > that works.
>
> I believe that CPAN is release oriented so they don't need to do that.
Exactly. They must have just as much development going on as us. I think
they just have a better process.
> Jakarta development tends to be CVS HEAD oriented because most people doing
> development try to keep CVS HEAD relatively stable.
I think you should qualify that. I don't think Jakarta is like that
generally. I think we are like that generally. We should probably make a
lot more point releases is what we should really do.
> Gump also attempts to
> enforce that practice. Also, Jakarta development tends to be more bleeding
> edge and with so many components depending on specific features in so many
> other components, it tends to make sense to use CVS HEAD.
Again, I don't believe this is true. Struts is very stable, and they
have made a lot of changes recently but are still almost 100% backward
compatible if not 100% backward compatible. They added subabbs and a
plugin mechansism, wide sweeping changes, and managed to stay
compatable. Clients did not need to use many dev snapshots or nightlies.
I think for the most part Struts users survive with releases quite well.
> I also like bucking the age old development trend of using only released
> software. :-) I believe that coding around released software bugs or adding
> features in a local package instead of a general package is worse than
> simply fixing the bug or adding the feature and updating the jar.
You and I have always worked from HEAD because of the disparity between
releases and what we are working on. I think if we worked a bit harder
to make point releases every few weeks the situation would be a lot
different.
You should be able to build from CVS and I have no qualms with you
there, but the way we work is different than most. I think we can agree
on that. Not everyone is interested in the bleeding edge but for the
most part would be very content with a well padded edge.
I also don't think something like Turbine should evolve constantly. I
think core will pretty much be complete when t3 is done. A small core
that accepts keyed components.
When you release Scarab how interested do you think you're really going
to be in radically changing it? I don't think the bleeding edge will be
very interesting when the tidal wave of bitching from your users start.
With Tambora we have to fight tooth and nail to get our users to change
anything and though I'm not entirely happy with t2 I'm glad it's not
changing constantly. I'm hoping that the innovation in the core of
turbine will soon come to an end and that the cool stuff happens in the
components.
I am definitely taking into consideration what you've said, but I really
think that most people are not interested in using things from CVS and
want those comfortable releases and we have to work harder to make more
of them.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/4/02 2:52 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> They are not using CVS for their distribution mechanism
> and I would be curious as to know why as they obviously have a model
> that works.
I believe that CPAN is release oriented so they don't need to do that.
Jakarta development tends to be CVS HEAD oriented because most people doing
development try to keep CVS HEAD relatively stable. Gump also attempts to
enforce that practice. Also, Jakarta development tends to be more bleeding
edge and with so many components depending on specific features in so many
other components, it tends to make sense to use CVS HEAD.
I also like bucking the age old development trend of using only released
software. :-) I believe that coding around released software bugs or adding
features in a local package instead of a general package is worse than
simply fixing the bug or adding the feature and updating the jar.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Eric Dobbs <er...@dobbse.net>.
On Thursday, April 4, 2002, at 03:52 PM, Jason van Zyl wrote:
> I am trying to get in touch
> with some of the CPAN fellows and ask why they chose to setup CPAN they
> way they did. They are not using CVS for their distribution mechanism
> and I would be curious as to know why as they obviously have a model
> that works.
One of the salient features of CPAN is the mirroring. CPAN
grew up when the network was generally slow and it was much
better to get things from a local mirror than to haul stuff
all over the network. I'll bet mirroring was a design goal.
Another feature of CPAN is the multiple indexes. There's a
ton of stuff in CPAN.
It might also be worth talking with the creators of various
package managers from Debian and RedHat, etc. Seems like
they are playing a similar game.
There's one thing I have to agree with Jon about. The
problem with jar files is a version management problem. It
just makes sense to use a version control system. It's the
right tool for that particular problem. You could even
lean completely on cvs tags and remove the need for versions
in the jar names (not that I want to start the whole argument
about versions in jar names).
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-04-04 at 17:25, Jon Scott Stevens wrote:
> on 4/4/02 1:21 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
> > You mean for the central repository? For some reason I always thought
> > you meant for each individual project. If this is for the entire central
> > repository then I'm not averse to that idea. But the repository should
> > still be the location for released versions of tools. For logging I
> > think this is a good idea. I still do not agree that it is a good thing
> > to check in N developmental builds.
> >
> > If using CVS for the central repo is what you mean.
>
> I can't believe all this time you didn't understand what I was saying. Sigh.
> :-(
>
> I do in fact mean to use CVS for the central repo.
That is clear now.
> >> That way, I can reference an unreleased beanutils and you can reference
> >> released versions.
> >
> > All you had to do was name it something different to identify it as
> > different and all would have been well.
>
> But that doesn't mean anything when you have:
>
> commons-foo-1.0-dev.jar
Yes, we've been over this before.
> I would then have to put the date into the file name...it is much easier to
> stick the .jar files into CVS and just reference a TAG.
>
> Please create a jakarta-turbine-jars repo.
>
> Then, what we will do is check all the files in
> /www/jakarta.apache.org/turbine/jars into that repo. In the /www/*/jars
> directory, we will then put a .htaccess file with lines like this:
>
> RedirectMatch turbine-3.0-dev.jar
> http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-turbine-jars/turbine-3.
> 0-dev.jar
Sorry, but I'm not sold on this yet and I want to think carefully before
doing anything permanently. I would like to think about this myself and
ask anyone else interested to think about the pros and cons. How things
will be maintained and the long term impact of doing something like
this. I want to think about this seriously. I am trying to get in touch
with some of the CPAN fellows and ask why they chose to setup CPAN they
way they did. They are not using CVS for their distribution mechanism
and I would be curious as to know why as they obviously have a model
that works.
What you outline may very well be a good solution but I would like to
verify myself that it is the optimal solution. And hopefully others will
scruntinize any solutions put forward. What we have is obviously
temporary but I would like to get the opinions of others and definitely
gather some info from the CPAN folks before setting anything up
permanently for the central repository.
> I just talked to Greg Stein (author of viewcvs and works at collabnet) and
> asked him to add a feature to viewcvs to set the Last-Modified: header when
> doing a checkout like the example above as well as upgrade viewcvs on
> apache.org. That way, we can use that to see if the file on disk needs to be
> updated or not.
>
> Also, Greg pointed out that in the future, when everyone is using subversion
> (replacement for CVS), this operation will be a simple HTTP process because
> Subversion implements WebDAV.
>
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/4/02 1:21 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> You mean for the central repository? For some reason I always thought
> you meant for each individual project. If this is for the entire central
> repository then I'm not averse to that idea. But the repository should
> still be the location for released versions of tools. For logging I
> think this is a good idea. I still do not agree that it is a good thing
> to check in N developmental builds.
>
> If using CVS for the central repo is what you mean.
I can't believe all this time you didn't understand what I was saying. Sigh.
:-(
I do in fact mean to use CVS for the central repo.
>> That way, I can reference an unreleased beanutils and you can reference
>> released versions.
>
> All you had to do was name it something different to identify it as
> different and all would have been well.
But that doesn't mean anything when you have:
commons-foo-1.0-dev.jar
I would then have to put the date into the file name...it is much easier to
stick the .jar files into CVS and just reference a TAG.
Please create a jakarta-turbine-jars repo.
Then, what we will do is check all the files in
/www/jakarta.apache.org/turbine/jars into that repo. In the /www/*/jars
directory, we will then put a .htaccess file with lines like this:
RedirectMatch turbine-3.0-dev.jar
http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-turbine-jars/turbine-3.
0-dev.jar
I just talked to Greg Stein (author of viewcvs and works at collabnet) and
asked him to add a feature to viewcvs to set the Last-Modified: header when
doing a checkout like the example above as well as upgrade viewcvs on
apache.org. That way, we can use that to see if the file on disk needs to be
updated or not.
Also, Greg pointed out that in the future, when everyone is using subversion
(replacement for CVS), this operation will be a simple HTTP process because
Subversion implements WebDAV.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-04-04 at 14:51, Jon Scott Stevens wrote:
> on 4/4/02 6:59 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
>
> > Hi,
> >
> > I just got back online and notice that the maven bootstrap is broken.
> >
> > It is broken because someone updated the beanutils jar with an
> > unreleased version which breaks everything because it has
> > commons-logging stuff.
> >
> > This is a process that has to be dealt with but if you intend to update
> > something please post a note first. The JARs in the repo can't be
> > changed willy-nilly with the latest CVS builds or you can potentially
> > break a lot of people's code. The maven bootstrap is an example of this.
> >
> > I will try to get a logging process going and a target in the maven
> > build system so that we can track changes in the central repository. The
> > beanutils that works has been put back.
>
> THIS IS WHY I SAID TO PUT THE FILES IN A CVS REPO!
You mean for the central repository? For some reason I always thought
you meant for each individual project. If this is for the entire central
repository then I'm not averse to that idea. But the repository should
still be the location for released versions of tools. For logging I
think this is a good idea. I still do not agree that it is a good thing
to check in N developmental builds.
If using CVS for the central repo is what you mean.
> That way, I can reference an unreleased beanutils and you can reference
> released versions.
All you had to do was name it something different to identify it as
different and all would have been well.
> -jon
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Updating the repository
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 4/4/02 6:59 AM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> Hi,
>
> I just got back online and notice that the maven bootstrap is broken.
>
> It is broken because someone updated the beanutils jar with an
> unreleased version which breaks everything because it has
> commons-logging stuff.
>
> This is a process that has to be dealt with but if you intend to update
> something please post a note first. The JARs in the repo can't be
> changed willy-nilly with the latest CVS builds or you can potentially
> break a lot of people's code. The maven bootstrap is an example of this.
>
> I will try to get a logging process going and a target in the maven
> build system so that we can track changes in the central repository. The
> beanutils that works has been put back.
THIS IS WHY I SAID TO PUT THE FILES IN A CVS REPO!
That way, I can reference an unreleased beanutils and you can reference
released versions.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>