[PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

Here's a proposal for the Geronimo PMC regarding running a maven 
repository for the project here at the ASF.  The basic problem is that 
there are many at the ASF, including board members, that believe that 
we shouldn't publish or distribute software that isn't created at the 
ASF.  I was one of those until yesterday, when I thought it through for 
a bit.   I've started some private conversations with those I know have 
issues with the idea to get feedback early, and in parallel we can work 
out a plan and incorporate their feedback if this has a chance of 
acceptance (I think it should...).

Note that there is a "slippery-slope" argument against this for which 
there is no good answer other than the pragmatic "lets minimize risk 
and see what happens"....

Motivation
----------

I) We want a fast, controlled source of project dependencies to make it 
easy and fast to build Geronimo.

  We are able to include binary jars from other outside projects in our 
official releases, because

a) it's clear that we are the publisher of the combined work
    that is our release
b) there has been sufficient oversight by the releasing PMC
   to ensure that the licenses and re-distribution terms for
   the third party jars are appropriate

In order to do have a maven repo that includes third party jars, we must

a) make it clear that we are *NOT* the publisher of the third party
    jars, but we are just redistributing it under appropriate terms
    as defined by the publisher
b) we can demonstrate that the PMC had oversight and control
    over the contents of the repository to monitor  the content,
    license and re-dist terms

II) For any community member that is interested in tracking the 
external dependencies (and there is an increased awareness in 
commercial users due to liability and indemnification issues), the 
following proposal provides a clear stream of specific messages never 
buried in commit noise to allow an observer to track changes in project 
dependencies.

So the proposal is then to create a maven repository for the use of the 
Geronimo project.  If the basic idea is sound, lets iron out the 
details.  Here's a start :

Structure
---------
- maven structure
- include a license file for each third-party artifact we have
- include a INFO file for each third-party artifact containing
     - source of jar
     - source's statement about redistribution

Contents
--------
- top-level index page clearly describing purpose and intent of 
repository (0)
- all third-party dependencies needed by current and recent-in-time 
build (1)
- snapshot versions of Geronimo build artifacts for "sister" projects 
like OpenEJB that have a [soon-to-go-away] tight dependency on core 
geronimo code
- release versions of Geronimo build artifacts (maybe not..)

(0) can we add a short note put into our maven output that says 
"Geronimmo 3rd party dependencies will be sourced from the 
project-specific geronimo repository" or such?
(1) Do we want to keep old stuff?  I think not - I think we'd want to 
be good ASF citizens to keep disk space usage to what is really needed. 
  If you need an older version, for some reason, you can slog it out of 
ibiblio or the original source.


Oversight and Process
---------------------
- writable by all Geronimo committers only
- openly readable (2)
- any addition or update to the repo requires that
   - INFO and LICENSE are added/updated if needed
   - email sent to dev@ to inform community (3)
   - change accepted by PMC by lazy consensus
- any third-party jar that is not an official release (like OpenEJB 
these days) but built from source by a Geronimo developer (w/ or w/o 
patches) must be marked with "SNAPSHOT" to make it clear that jar isn't 
a release from the originating project, nor an attempt by the Geronimo 
project to create a release or a distributable for another project.
- infrastructure will be informed when we create this to ensure that in 
the event someone has a problem with something coming from our repo, 
they'll be aware and can just yank offending artifact, and know to 
inform the geronimo PMC about the issue

(2) for now...
(3) we can find technology solutions to reduce the work later - lets 
focus on the oversight process

I think that covers the basics.  Comments?

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Mar 31, 2005, at 3:54 PM, Jeremy Boynes wrote:

> I think this is a good start in the right direction. The need for  
> demonstrable oversight is clear and if anything I would like to  
> strengthen those processes not loosen them. Some of that is already  
> built into Maven and we should use those capabilities.
>
> More comments inline, all fine tuning.
>
> --
> Jeremy
>
> Geir Magnusson Jr. wrote:
>> Here's a proposal for the Geronimo PMC regarding running a maven  
>> repository for the project here at the ASF.  The basic problem is  
>> that there are many at the ASF, including board members, that believe  
>> that we shouldn't publish or distribute software that isn't created  
>> at the ASF.  I was one of those until yesterday, when I thought it  
>> through for a bit.   I've started some private conversations with  
>> those I know have issues with the idea to get feedback early, and in  
>> parallel we can work out a plan and incorporate their feedback if  
>> this has a chance of acceptance (I think it should...).
>> Note that there is a "slippery-slope" argument against this for which  
>> there is no good answer other than the pragmatic "lets minimize risk  
>> and see what happens"....
>> Motivation
>> ----------
>> I) We want a fast, controlled source of project dependencies to make  
>> it easy and fast to build Geronimo.
>>  We are able to include binary jars from other outside projects in  
>> our official releases, because
>> a) it's clear that we are the publisher of the combined work
>>    that is our release
>> b) there has been sufficient oversight by the releasing PMC
>>   to ensure that the licenses and re-distribution terms for
>>   the third party jars are appropriate
>> In order to do have a maven repo that includes third party jars, we  
>> must
>> a) make it clear that we are *NOT* the publisher of the third party
>>    jars, but we are just redistributing it under appropriate terms
>>    as defined by the publisher
>> b) we can demonstrate that the PMC had oversight and control
>>    over the contents of the repository to monitor  the content,
>>    license and re-dist terms
>> II) For any community member that is interested in tracking the  
>> external dependencies (and there is an increased awareness in  
>> commercial users due to liability and indemnification issues), the  
>> following proposal provides a clear stream of specific messages never  
>> buried in commit noise to allow an observer to track changes in  
>> project dependencies.
>> So the proposal is then to create a maven repository for the use of  
>> the Geronimo project.  If the basic idea is sound, lets iron out the  
>> details.  Here's a start :
>> Structure
>> ---------
>> - maven structure
>> - include a license file for each third-party artifact we have
>
> This is a normal feature of a Maven repo. We should also require that  
> an appropriate POM is installed so that contributors can be  
> identified.

Right - I thought of that, but the strong wish is that we make it  
screamingly obvious to the casual browser about the license (I guess  
them being in a directory called "license" should be a clue, but never  
underestimate a fool...).   Same w/ copyright and contributors.  This  
seems like an implementation detail at this point though.

>
>> - include a INFO file for each third-party artifact containing
>>     - source of jar
>>     - source's statement about redistribution
>
> We should also include INFO for each release identifying the  
> third-party jars that it uses. This means there is an easier place to  
> look than the content of a distribution.

Do you mean our releases, or the third party jars?

>
>> Contents
>> --------
>> - top-level index page clearly describing purpose and intent of  
>> repository (0)
>> - all third-party dependencies needed by current and recent-in-time  
>> build (1)
>> - snapshot versions of Geronimo build artifacts for "sister" projects  
>> like OpenEJB that have a [soon-to-go-away] tight dependency on core  
>> geronimo code
>> - release versions of Geronimo build artifacts (maybe not..)
>> (0) can we add a short note put into our maven output that says  
>> "Geronimmo 3rd party dependencies will be sourced from the  
>> project-specific geronimo repository" or such?
>> (1) Do we want to keep old stuff?  I think not - I think we'd want to  
>> be good ASF citizens to keep disk space usage to what is really  
>> needed.  If you need an older version, for some reason, you can slog  
>> it out of ibiblio or the original source.
>
> I think we should keep as much history as possible, at least the  
> dependencies for all maintained branches.

Ok.  I'm not so sure since they should be out there in ibiblio unless  
they have been yanked for some reason, which would imply an  
administrative burden on us.  If that isn't clear, a contrived   
example...  go forward in time, a few years, and suppose some old  
dependency that we no longer use, care or think about has to be pulled  
from availability due to something - maybe SCO sues someone else.   
Unless it's big news, we may not ever know, and thus keep making it  
available for no reason other than the unlikely event someone wants to  
go back and rebuild an old version.

However we decide this, we don't need a decision to move forward.   
Having a few versions for maintained branches will be a good problem to  
think about.


>
>> Oversight and Process
>> ---------------------
>> - writable by all Geronimo committers only
>> - openly readable (2)
>> - any addition or update to the repo requires that
>>   - INFO and LICENSE are added/updated if needed
>>   - email sent to dev@ to inform community (3)
>>   - change accepted by PMC by lazy consensus
>> - any third-party jar that is not an official release (like OpenEJB  
>> these days) but built from source by a Geronimo developer (w/ or w/o  
>> patches) must be marked with "SNAPSHOT" to make it clear that jar  
>> isn't a release from the originating project, nor an attempt by the  
>> Geronimo project to create a release or a distributable for another  
>> project.
>
> A grey area here is the "we need release 4.0.1 + these three patches"  
> scenario (for example, as an emergency security fix). This would not  
> be a SNAPSHOT but a revision/timestamp build of the project we depend  
> on.

True, but we'd make the name damn clear that it wasn't published by the  
original project (who should do it anyway).  maybe

     
foo-4.0.1-plus-geronimo-project-patches-because-foo-couldnt-be- 
bothered.jar

probably wouldn't be valid on windows though...

> I think clear notification, lazy consensus by the PMC and a plan to  
> migrate to an offical release would be sufficient oversight - we just  
> need to be clear about what is happening.

Great.  Thank you.

Anyone else?
>
>> - infrastructure will be informed when we create this to ensure that  
>> in the event someone has a problem with something coming from our  
>> repo, they'll be aware and can just yank offending artifact, and know  
>> to inform the geronimo PMC about the issue
>> (2) for now...
>> (3) we can find technology solutions to reduce the work later - lets  
>> focus on the oversight process
>> I think that covers the basics.  Comments?
>> geir
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Jeremy Boynes <jb...@apache.org>]

Dain Sundstrom wrote:
> On Mar 31, 2005, at 12:54 PM, Jeremy Boynes wrote:
>>
>> This is a normal feature of a Maven repo. We should also require that 
>> an appropriate POM is installed so that contributors can be identified.
> 
> 
> This will be a problem for ant based projects.  I propose we have a 
> minimal pom we use for these types of projects.
> 

We should generate project specific POM if there isn't one. AIUI policy 
for posting a project to the repo on ibiblio now requires a POM (so 
transitive dependencies can be resolved).

>>> - include a INFO file for each third-party artifact containing
>>>     - source of jar
>>>     - source's statement about redistribution
>>
>>
>> We should also include INFO for each release identifying the 
>> third-party jars that it uses. This means there is an easier place to 
>> look than the content of a distribution.
> 
> 
> Can't we use the pom dependencies section for this, or are you thinking 
> of something else?
> 

I'm thinking of one place where all dependencies can be found. If there 
is a pom that contains the whole list then that would be good; however, 
I am concerned about dependencies that might not be in that pom e.g. 
through transitive resolution.

I think this can be auto generated anyway at assembly time.
--
Jeremy

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Thu, Mar 31, 2005 at 07:35:26PM -0500, Geir Magnusson Jr wrote:
> 
> On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote:
> >>>
> >>>It could.  But the main argument to keep old numbered snapshot jars 
> >>>is so that you can build an old source release of of geronimo that 
> >>>might depend on a old numbered snapshot release.
> >>
> >>How?  do we ever list the snapshot number in project.xml?
> >
> >I think for a release, yes..  we should take the effort and specify 
> >the snapshot number.
> 
> I'm confused, and want to make sure we're not just talking past each 
> other accidentally.  For a release, we don't use snapshots anyway, 
> right?  We'd generate a set of jars all with the release version number 
> in the filename.
> 

A little.  True maven SNAPSHOTs are timestamped jars, not just jars
whose version number happens to include the word SNAPSHOT.

We don't actually use the jar:deploy-snapshot maven goal, which in
fact does give you a timestamped (e.g. numbered) binary like
geronimo-kernel-20050331044923.jar.  Then it just symlinks that file
to geronimo-kernel-SNAPSHOT.jar.  So the "SNAPSHOT" is just a symlink
to the timestamped jar.  Provided you checked out before you built and
deployed the maven-created snapshot jars, you have a pretty decent way
to find the source for the jar in cvs.

Would be great if we could use it, but we can't because it generates
the timestamp on a per-module basis and you end up with this:

  geronimo-kernel-20050331044923.jar
  geronimo-common-20050331045056.jar
  geronimo-system-20050331045514.jar
  geronimo-deployment-20050331045732.jar
  geronimo-j2ee-20050331050124.jar
  geronimo-j2ee-schema-20050331050659.jar
  (etc ...)

I think what Hiram has in his head is that for M1 and M2 he cut an
ActiveMQ release and we released against those.  For M3, they were
still waiting on a couple non-geronimo related features to do a
release, so we created a YYYYMMDD stamped copy of the ActiveMQ
snapshots we were using and released against those.  So if those jars
have been deleted from the ActiveMQ repo, M3 is not buildable by
anyone.

Our XFire dependencies are a cvs version hand datestamped as well as
we didn't want a SNAPSHOT dependency because the code just changes too
fast being they are still in early development--lots of renaming,
repackaging and other refactoring.  As with ActiveMQ, that XFire
version is in their repo and is safe as long as no one over there
forgets we need it.


-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Thu, Mar 31, 2005 at 10:02:07PM -0500, Geir Magnusson Jr wrote:
> 
> On Mar 31, 2005, at 8:40 PM, Hiram Chirino wrote:
> >
> >What's the difference between that and me building a 
> >ActiveMQ-3.0-20050115-SNAPSHOT.jar ??  It's the same in my eyes.  The 
> >ActiveMQ folks don't want to keep snapshots like that around since 
> >that just increases the release management overhead.  ActiveMQ likes 
> >to keep it simple... we don't do mile stones or release candidates or 
> >alphas or betas or any of that stuff.
> >
> >I think we just need to be flexible.  Other projects in the future may 
> >not be able to do a release just for a Milestone release of Geronimo.
> 
> No, but I worry about just bundling random whatever from outside the 
> project with our releases.  It would help to use the svn revision on 
> the jar, but we should really make it clear that it's something the 
> geronimo project created for it's use, rather than confuse people that 
> it might be an artifact from ActiveMQ.  The word 'SNAPSHOT' would help.
> 
> I also would have thought that the ActiveMQ project wouldn't want 
> activeMQ-*.jar floating around out there where they didn't choose *...
> 
> We'll figure it out...
> 

I have a non-hypothetical example with a newer "sister" project, Axis.

We have a SNAPSHOT dependency on that project because we are still
doing work on webservices and I occasionally have to send patches
which i need applied before I can check in.

They are very quick with applying patches (thanks!), but our svn moves
very quickly and we have to go ahead with our end of the changes and
occasionally use a "pre-commit" patched jar for a day or two before we
can switch back to the snapshots.

They publish snapshots four times a day, which is more than we need.
We really don't need a snapshot dependency, just the latest patched
code that we developed and tested against.

As far as releases go, they are coming up on the big 1.2.  After that,
they will be winding down the 1.x branch and releasing less.  Our
releasing cycles are only going to be picking up as we go forward.

Dims and crew are very generous with their time and I would feel bad
even asking them to release on our schedule.  They put an awful lot
of work into their releases just as we do, so asking them for releases
every now and then is a big request.

Anyone have any ideas on what we could/should be doing?  Floor's open
to anyone with ideas....


-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

Before this spins out of control, let's give everyone a chance to clarify.  I must admit I didn't quite clearly understand the "...and they do that...." part of the email.  I took the overall point to mean something like, if we need to release in-step then we should consider cleaning up the coupling between the projects, which wouldn't be an unreasonable statement.

Geir, is that what you meant?

-David

On Mon, Apr 04, 2005 at 04:12:06PM -0700, Dain Sundstrom wrote:
> On Apr 4, 2005, at 3:53 PM, Geir Magnusson Jr wrote:
> 
> >On Apr 4, 2005, at 5:48 PM, David Blevins wrote:
> >
> >>Even further, I don't think pressuring projects into giving us an 
> >>officially named version of our SNAPSHOT when they aren't ready to 
> >>release is a solution either.  Then we are just turning a blind eye 
> >>and saying, "not my problem."
> >
> >Well, if we are working closely with a project (like OpenEJB, 
> >ActiveMQ, HOWL, etc) and they do that it's time to reconsider working 
> >so closely with them, IMO.  I'm not saying that projects should 
> >release for us on a whim because they are independent and have other 
> >parts of their community to cater to, and I know things will settle 
> >down, but there are lots of users that wouldn't take things seriously 
> >until the pedigree of the OSS we're using is clear, and it wouldn't be 
> >if we were issuing our own snapshots of external dependencies.
> 
> Geir, I think your comments are way too hard of a line to take.  Let's 
> put this back in context.  David originally wrote the following:
> 
> --------------------------------------
> You do realize we are talking about two different things here.  No one 
> in their right mind would propose SNAPSHOT dependencies are a good idea 
> for releases of any kind.  Not only do I strongly agree, I think we 
> shouldn't switch something back to SNAPSHOT after a release.
> 
> Even further, I don't think pressuring projects into giving us an 
> officially named version of our SNAPSHOT when they aren't ready to 
> release is a solution either.  Then we are just turning a blind eye and 
> saying, "not my problem."
> --------------------------------------
> 
> The reality is our timeline are not likely to align with most projects. 
>  There will be tough times when a project is focused on another task 
> and not ready to cut a release (much like geronimo is now focused on 
> certification).  In times like that, how do you propose we "reconsider 
> working so closely with them".  Would we fork a project because they 
> wanted to wait a 3 weeks for an official release?  Would we replace the 
> project?  Most of the projects you listed are simply irreplaceable.
> 
> I think you need to be more flexible.  This is especially true when 
> dealing with a volunteer organization.
> 
> -dain

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Apr 4, 2005, at 7:12 PM, Dain Sundstrom wrote:

> On Apr 4, 2005, at 3:53 PM, Geir Magnusson Jr wrote:
>
>> On Apr 4, 2005, at 5:48 PM, David Blevins wrote:
>>
>>> Even further, I don't think pressuring projects into giving us an 
>>> officially named version of our SNAPSHOT when they aren't ready to 
>>> release is a solution either.  Then we are just turning a blind eye 
>>> and saying, "not my problem."
>>
>> Well, if we are working closely with a project (like OpenEJB, 
>> ActiveMQ, HOWL, etc) and they do that it's time to reconsider working 
>> so closely with them, IMO.  I'm not saying that projects should 
>> release for us on a whim because they are independent and have other 
>> parts of their community to cater to, and I know things will settle 
>> down, but there are lots of users that wouldn't take things seriously 
>> until the pedigree of the OSS we're using is clear, and it wouldn't 
>> be if we were issuing our own snapshots of external dependencies.
>
> Geir, I think your comments are way too hard of a line to take.

This is a fairly common line with other open source projects, and 
commercial and corporate development as well.  We can be (gawd, it 
hurts to use this word) professional.  People want to know what is in 
the the software they are deploying, that they are building products 
and business on.  They want to know where it comes from.  They want to 
know that others are using the same thing (safety in numbers) and they 
want to know that if there is a bug or patch, they can go to the source 
and get it.

>  Let's put this back in context.  David originally wrote the following:
>
> --------------------------------------
> You do realize we are talking about two different things here.  No one 
> in their right mind would propose SNAPSHOT dependencies are a good 
> idea for releases of any kind.  Not only do I strongly agree, I think 
> we shouldn't switch something back to SNAPSHOT after a release.
>
> Even further, I don't think pressuring projects into giving us an 
> officially named version of our SNAPSHOT when they aren't ready to 
> release is a solution either.  Then we are just turning a blind eye 
> and saying, "not my problem."
> --------------------------------------

And before that, he said :

> Seems like we are going in circles on this one.  Can we reasonable 
> agree that it isn't practical to hold up a Geronimo release till every 
> project we have a snapshot depenency on is able to hand us some sort 
> of official release of their own?

So I was confused.  I do think he cleared it up.

>
> The reality is our timeline are not likely to align with most 
> projects.  There will be tough times when a project is focused on 
> another task and not ready to cut a release (much like geronimo is now 
> focused on certification).  In times like that, how do you propose we 
> "reconsider working so closely with them".  Would we fork a project 
> because they wanted to wait a 3 weeks for an official release?  Would 
> we replace the project?  Most of the projects you listed are simply 
> irreplaceable.

The fact is that when we do a release, and are telling people that we 
declare the software safe and ready to use, with the standard 
conventions of dependencies on other software, that I'd like to be sure 
that there is the absolute minimum of strangeness about what we 
release, and that we have the minimum of objections for adoption.  
Cutting our own releases of dependencies is going to be a barrier.

>
> I think you need to be more flexible.  This is especially true when 
> dealing with a volunteer organization.

I think you are making a mountain out of a molehill.  We have great 
relationships with those projects (we have many cross-committers), so 
I'm not terribly worried, especially if we do a bit of coordination, 
planning and help.

geir

>
> -dain
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Dain Sundstrom <ds...@gluecode.com>]

On Apr 4, 2005, at 3:53 PM, Geir Magnusson Jr wrote:

> On Apr 4, 2005, at 5:48 PM, David Blevins wrote:
>
>> Even further, I don't think pressuring projects into giving us an 
>> officially named version of our SNAPSHOT when they aren't ready to 
>> release is a solution either.  Then we are just turning a blind eye 
>> and saying, "not my problem."
>
> Well, if we are working closely with a project (like OpenEJB, 
> ActiveMQ, HOWL, etc) and they do that it's time to reconsider working 
> so closely with them, IMO.  I'm not saying that projects should 
> release for us on a whim because they are independent and have other 
> parts of their community to cater to, and I know things will settle 
> down, but there are lots of users that wouldn't take things seriously 
> until the pedigree of the OSS we're using is clear, and it wouldn't be 
> if we were issuing our own snapshots of external dependencies.

Geir, I think your comments are way too hard of a line to take.  Let's 
put this back in context.  David originally wrote the following:

--------------------------------------
You do realize we are talking about two different things here.  No one 
in their right mind would propose SNAPSHOT dependencies are a good idea 
for releases of any kind.  Not only do I strongly agree, I think we 
shouldn't switch something back to SNAPSHOT after a release.

Even further, I don't think pressuring projects into giving us an 
officially named version of our SNAPSHOT when they aren't ready to 
release is a solution either.  Then we are just turning a blind eye and 
saying, "not my problem."
--------------------------------------

The reality is our timeline are not likely to align with most projects. 
  There will be tough times when a project is focused on another task 
and not ready to cut a release (much like geronimo is now focused on 
certification).  In times like that, how do you propose we "reconsider 
working so closely with them".  Would we fork a project because they 
wanted to wait a 3 weeks for an official release?  Would we replace the 
project?  Most of the projects you listed are simply irreplaceable.

I think you need to be more flexible.  This is especially true when 
dealing with a volunteer organization.

-dain

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Apr 4, 2005, at 5:48 PM, David Blevins wrote:

> On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
>>
>> On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:
>>
>>> On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
>>>
>>>> Seems like we are going in circles on this one.  Can we reasonable
>>>> agree that it isn't practical to hold up a Geronimo release till
>>>> every project we have a snapshot depenency on is able to hand us 
>>>> some
>>>> sort of official release of their own?
>>>
>>> +1
>>>
>>> We do our best to eliminate the SNAPSHOTs, but the reality is we 
>>> can't
>>> always eliminate all of them.
>>
>> You guys are crazy.  We have to be able to eliminate them, especially
>> for production releases. Even before we're 1.0, I would expect that 
>> our
>> 0.8 and 0.9 stuff are becoming good enough for some dependable use, 
>> and
>> thus we should only depend on released software.
>>
>
> You do realize we are talking about two different things here.  No one 
> in their right mind would propose SNAPSHOT dependencies are a good 
> idea for releases of any kind.  Not only do I strongly agree, I think 
> we shouldn't switch something back to SNAPSHOT after a release.

Sorry - I must have misunderstood the following :

>>
>>> On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
>>>
>>>> Seems like we are going in circles on this one.  Can we reasonable
>>>> agree that it isn't practical to hold up a Geronimo release till
>>>> every project we have a snapshot depenency on is able to hand us 
>>>> some
>>>> sort of official release of their own?


>
> Even further, I don't think pressuring projects into giving us an 
> officially named version of our SNAPSHOT when they aren't ready to 
> release is a solution either.  Then we are just turning a blind eye 
> and saying, "not my problem."

Well, if we are working closely with a project (like OpenEJB, ActiveMQ, 
HOWL, etc) and they do that it's time to reconsider working so closely 
with them, IMO.  I'm not saying that projects should release for us on 
a whim because they are independent and have other parts of their 
community to cater to, and I know things will settle down, but there 
are lots of users that wouldn't take things seriously until the 
pedigree of the OSS we're using is clear, and it wouldn't be if we were 
issuing our own snapshots of external dependencies.

>
> Our current reality is that we do have over a dozen SNAPSHOT 
> dependencies and we will need to release soon enough.
>
> I only see two solutions to this releasing issue:
>
>  1. Use date stamped (cvs) or revision stamped (svn) jars in place of 
> SNAPSHOTs on releases.
>  2. Not release until we can truly eliminate all SNAPSHOT usage--not 
> just get other projects to relabel our SNAPSHOTs so we feel warm and 
> fuzzy.
>
> My long term preference is 2, though I'm ok with 1 in the very short 
> term.

For the very short term I can live with #1, but this should be a 
priority to get under control, somehow.

geir

>
> -David
>
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
> 
> On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:
> 
> >On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
> >
> >>Seems like we are going in circles on this one.  Can we reasonable 
> >>agree that it isn't practical to hold up a Geronimo release till 
> >>every project we have a snapshot depenency on is able to hand us some 
> >>sort of official release of their own?
> >
> >+1
> >
> >We do our best to eliminate the SNAPSHOTs, but the reality is we can't 
> >always eliminate all of them.
> 
> You guys are crazy.  We have to be able to eliminate them, especially 
> for production releases. Even before we're 1.0, I would expect that our 
> 0.8 and 0.9 stuff are becoming good enough for some dependable use, and 
> thus we should only depend on released software.
> 

You do realize we are talking about two different things here.  No one in their right mind would propose SNAPSHOT dependencies are a good idea for releases of any kind.  Not only do I strongly agree, I think we shouldn't switch something back to SNAPSHOT after a release.

Even further, I don't think pressuring projects into giving us an officially named version of our SNAPSHOT when they aren't ready to release is a solution either.  Then we are just turning a blind eye and saying, "not my problem."

Our current reality is that we do have over a dozen SNAPSHOT dependencies and we will need to release soon enough.

I only see two solutions to this releasing issue:

 1. Use date stamped (cvs) or revision stamped (svn) jars in place of SNAPSHOTs on releases.
 2. Not release until we can truly eliminate all SNAPSHOT usage--not just get other projects to relabel our SNAPSHOTs so we feel warm and fuzzy.

My long term preference is 2, though I'm ok with 1 in the very short term.

-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Mon, Apr 04, 2005 at 08:41:24PM -0400, Geir Magnusson Jr wrote:
> 
> On Apr 4, 2005, at 6:17 PM, David Blevins wrote:
> >
> >I totally get your point, but the thing I don't like about that style 
> >for pre-1.0 software is that it is essentially a countdown to 1.0, and 
> >we can't predict how many releases it's going to take.  Then you just 
> >naturally start adding dots to the end of the release number when you 
> >hit 9 and you end up with versions like 0.9.2 or 0.9.5.3.
> 
> Ah!  The Castor "Asymptotically Approach 1.0" Version Scheme :)

Not just Castor, OpenEJB pulled a Mozilla on version numbers too.  Not something I'm proud of.

> 
> Well, that is a danger, but I think that we're getting there....
> 
> >
> >It's like when kids play hide-and-go-seek.  If the kid counting wants 
> >more time he starts yelling off fractions when they hit 9, "7... 8... 
> >9... 9 and 1/2... 9 and 3/4...."
> >
> >I'd prefer we be more aggressive with the milestones (however many we 
> >need) until we are ready to muster up a release candidate (RC) that we 
> >expect to be the final 1.0 release baring any critical issues.  Then 
> >we do dot revisions for the remainder of the 1.x branch releases.
> >
> >When work starts on 2.x, we issue milestones on that till it's ready 
> >for an RC and final.  Dot revisions after that.  Same for 3.x, 4.x and 
> >so on.
> 
> Where else have you seen it done this way?  I'm used to 0.x -> 1.0 -> 
> 1.x -> 2.0 - > ....
> 

Yanked the idea from Eclipse. 


-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Apr 4, 2005, at 6:17 PM, David Blevins wrote:

> On Mon, Apr 04, 2005 at 05:37:32PM -0400, Geir Magnusson Jr wrote:
>>
>> On Apr 4, 2005, at 4:45 PM, David Blevins wrote:
>>
>>> On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
>>>>
>>>> Even before we're 1.0, I would expect that our 0.8 and 0.9 stuff
>>>> are becoming good enough for some dependable use, and thus we
>>>> should only depend on released software.
>>>
>>> What is 0.8 and 0.9?
>>
>> Oh, sorry.  I keep thinking in terms of versions leading up to a 1.0
>> release.  I know we don't do that here (yet), but just think of things
>> that way.
>>
>
> I totally get your point, but the thing I don't like about that style 
> for pre-1.0 software is that it is essentially a countdown to 1.0, and 
> we can't predict how many releases it's going to take.  Then you just 
> naturally start adding dots to the end of the release number when you 
> hit 9 and you end up with versions like 0.9.2 or 0.9.5.3.

Ah!  The Castor "Asymptotically Approach 1.0" Version Scheme :)

Well, that is a danger, but I think that we're getting there....

>
> It's like when kids play hide-and-go-seek.  If the kid counting wants 
> more time he starts yelling off fractions when they hit 9, "7... 8... 
> 9... 9 and 1/2... 9 and 3/4...."
>
> I'd prefer we be more aggressive with the milestones (however many we 
> need) until we are ready to muster up a release candidate (RC) that we 
> expect to be the final 1.0 release baring any critical issues.  Then 
> we do dot revisions for the remainder of the 1.x branch releases.
>
> When work starts on 2.x, we issue milestones on that till it's ready 
> for an RC and final.  Dot revisions after that.  Same for 3.x, 4.x and 
> so on.

Where else have you seen it done this way?  I'm used to 0.x -> 1.0 -> 
1.x -> 2.0 - > ....

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Mon, Apr 04, 2005 at 05:37:32PM -0400, Geir Magnusson Jr wrote:
> 
> On Apr 4, 2005, at 4:45 PM, David Blevins wrote:
> 
> >On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
> >>
> >>Even before we're 1.0, I would expect that our 0.8 and 0.9 stuff
> >>are becoming good enough for some dependable use, and thus we
> >>should only depend on released software.
> >
> >What is 0.8 and 0.9?
> 
> Oh, sorry.  I keep thinking in terms of versions leading up to a 1.0 
> release.  I know we don't do that here (yet), but just think of things 
> that way.
> 

I totally get your point, but the thing I don't like about that style for pre-1.0 software is that it is essentially a countdown to 1.0, and we can't predict how many releases it's going to take.  Then you just naturally start adding dots to the end of the release number when you hit 9 and you end up with versions like 0.9.2 or 0.9.5.3.

It's like when kids play hide-and-go-seek.  If the kid counting wants more time he starts yelling off fractions when they hit 9, "7... 8... 9... 9 and 1/2... 9 and 3/4...."

I'd prefer we be more aggressive with the milestones (however many we need) until we are ready to muster up a release candidate (RC) that we expect to be the final 1.0 release baring any critical issues.  Then we do dot revisions for the remainder of the 1.x branch releases.  

When work starts on 2.x, we issue milestones on that till it's ready for an RC and final.  Dot revisions after that.  Same for 3.x, 4.x and so on.

-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Apr 4, 2005, at 4:45 PM, David Blevins wrote:

> On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
>>
>> On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:
>>
>>> On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
>>>
>>>> Seems like we are going in circles on this one.  Can we reasonable
>>>> agree that it isn't practical to hold up a Geronimo release till
>>>> every project we have a snapshot depenency on is able to hand us 
>>>> some
>>>> sort of official release of their own?
>>>
>>> +1
>>>
>>> We do our best to eliminate the SNAPSHOTs, but the reality is we 
>>> can't
>>> always eliminate all of them.
>>
>> You guys are crazy.  We have to be able to eliminate them, especially
>> for production releases. Even before we're 1.0, I would expect that 
>> our
>> 0.8 and 0.9 stuff are becoming good enough for some dependable use, 
>> and
>> thus we should only depend on released software.
>
> What is 0.8 and 0.9?

Oh, sorry.  I keep thinking in terms of versions leading up to a 1.0 
release.  I know we don't do that here (yet), but just think of things 
that way.

IOW, I think that a 1.0 should be fairly dependable, and thus the 
fractional releases leading up to 1.0 should be the kind of code you 
can work with some reasonable amount of trust.

In any event, having snapshots of external projects is something we 
should avoid.

geir

>
> -David
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
> 
> On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:
> 
> >On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
> >
> >>Seems like we are going in circles on this one.  Can we reasonable 
> >>agree that it isn't practical to hold up a Geronimo release till 
> >>every project we have a snapshot depenency on is able to hand us some 
> >>sort of official release of their own?
> >
> >+1
> >
> >We do our best to eliminate the SNAPSHOTs, but the reality is we can't 
> >always eliminate all of them.
> 
> You guys are crazy.  We have to be able to eliminate them, especially 
> for production releases. Even before we're 1.0, I would expect that our 
> 0.8 and 0.9 stuff are becoming good enough for some dependable use, and 
> thus we should only depend on released software.

What is 0.8 and 0.9?

-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:

> On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
>
>> Seems like we are going in circles on this one.  Can we reasonable 
>> agree that it isn't practical to hold up a Geronimo release till 
>> every project we have a snapshot depenency on is able to hand us some 
>> sort of official release of their own?
>
> +1
>
> We do our best to eliminate the SNAPSHOTs, but the reality is we can't 
> always eliminate all of them.

You guys are crazy.  We have to be able to eliminate them, especially 
for production releases. Even before we're 1.0, I would expect that our 
0.8 and 0.9 stuff are becoming good enough for some dependable use, and 
thus we should only depend on released software.

My USD0.02

geir

>
> -dain
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Dain Sundstrom <ds...@gluecode.com>]

On Apr 4, 2005, at 9:59 AM, David Blevins wrote:

> Seems like we are going in circles on this one.  Can we reasonable 
> agree that it isn't practical to hold up a Geronimo release till every 
> project we have a snapshot depenency on is able to hand us some sort 
> of official release of their own?

+1

We do our best to eliminate the SNAPSHOTs, but the reality is we can't 
always eliminate all of them.

-dain

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Mon, Apr 04, 2005 at 07:40:26AM -0400, Geir Magnusson Jr. wrote:
> 
> On Apr 1, 2005, at 9:36 AM, Hiram Chirino wrote:
> >>
> >>Going back to the original issue of an external project not wishing 
> >>to do a release, we want to make it clear that this is something that 
> >>we threw together ad hoc, and not something published by the external 
> >>project.
> >>
> >
> >The upside to having a geronimo committer build the artifact himself 
> >from source is that you have a better oversight in knowing from what 
> >source code a binary was produced.  Perhaps we should tag the file 
> >name with something, so it obvious it's an ad hoc build that an apache 
> >committer through together.
> 
> Yep!
> 
> >
> >>And I'm still not comfortable doing something like that in a real 
> >>geronimo release.
> >>
> >
> >I agree it's not the best solution, but it's something we have to deal 
> >with.  Unless you are willing to hold up on doing geronimo releases 
> >until all it's dependent software does an official release.  And then 
> >this would apply transitively, such that you would have to wait till a 
> >SNAPSHOT dependency of activemq is has been officially released.  etc.
> >
> 
> Well, yah, sorta.  Milestones are less of a problem but "real" versions?
> 
> I don't think that we would be happy with some other project 
> distributing jars called "geronimo-kernel-xxxx.jar" or the like.  Not 
> only could it mean misery and pain in support, but also risk to 
> reputation, and possibility of it containing code that we'd never 
> release.  The last thing we need is to explain to someone that a 
> geronimo jar containing BEA code (or whatever) really isn't a Geronimo 
> jar.
> 
> I certainly feel the pain of the problem.  But if we can do whatever we 
> can to get the other projects to do even 'beta' or 'rcx' releases... 
> Hiram, do you know any influential committers on ActiveMQ? :D
> 

Seems like we are going in circles on this one.  Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own?


-David

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Blevins <da...@visi.com>]

On Fri, Apr 01, 2005 at 03:10:58PM +1000, sissonj@insession.com wrote:
> 
> I haven't thought this through too much, but have never felt comfortable 
> with SNAPSHOTs.  Could versioned dependencies help us here?
> 

I think they would.  When I introduced a dependency on XFire in the Geronimo build I chose to use datestamped versions rather than SNAPSHOTs.  Not because I thought there would be no more changes required in XFire, but because it didn't seem like a win to use a SNAPSHOT and make other people have to deal with build failures that might arise from the constant mutation in a SNAPSHOT jar.  There have been plenty of changes in XFire, have you noticed any XFire related build failures?

Sure it's more work for me to take a slice of the cvs, build it with a datestamp, publish it to a repo, then update the Geronimo dependencies and check that in.  But I figured since I was the only one working on XFire, all related build failures are going to come back to me anyway, so I might as well be proactive about it.

I've only had to do three or for datestamped versions of XFire--not every change in XFire required an new version from Geronimo's perspective.  I've only done three patches to Axis, so we could easily get by with datestamped versions of that provided I became a little more proactive with that too.

Obviously, it's not a rule we can apply to everything.  The tighter the coupling, the more frequently you would need to produce date-stamped or revision-stamped jars.  Sometimes it's worth it, other times not.

<aside>
It's strange, but using SNAPSHOTs tends to promote increased coupling and dependency between code over time, which I think would otherwise be avoided or at least inhibited.  Very good for innovation, but puts an ironic spin on the term Continuous Integration.
</aside>


-David

SNAPSHOTs

[Jeremy Boynes <jb...@apache.org>]

sissonj@insession.com wrote:
> 
> To be able to do this effectively, we would need a tool that tells us when 
> there is a newer version available in a remote repository.  When a newer 
> version is available, a developer (or a continuous integration tool) can 
> change their local copy of the code to use the newer version and test 
> compatibility with that version and if all is ok, commit the change. 
> 

I think the problem we are seeing is more due to uncontrolled SNAPSHOTs 
rather than the concept itself. For example, a lot of the problems we 
see go away when OpenEJB is rebuilt. This implies two things:

1) there is too much coupling between the projects

2) when changes are made new jars are not posted to the online repo
    quickly enough, combined with the performance of the online build
    being so slow that people are building offline and don't see new
    versions even when they do get posted

The first of these will require time to solve.

One of the factors with the second is the number of repo locations 
(because developers do not have write access to a central repo) and the 
unpredictable performance of the main repo at ibiblio. By moving to one 
central repo with good performance I believe we will address both of these.

> Currently, all developers are exposed to updates to SNAPSHOTS and 
> sometimes the build can be broken for days.  If you don't have a backup of 
> your previously building code (and repository?), one is in trouble if they 
> want rebuild (e.g. an offline build) a working version.
> 
> I haven't thought this through too much, but have never felt comfortable 
> with SNAPSHOTs.  Could versioned dependencies help us here?
> 

The problem I think we will run into is an overabundance of versions - 
at the extreme one for every commit. That is the problem that SNAPSHOTs 
were intended to solve by allowing one shared version that could be 
overwritten combined with an automatic download mechanism.

Now that we have a central way to change the project version, one option 
might be for developers to work with a "DEV" version that never leaves 
their local machine. Because this is not a SNAPSHOT we would eliminate 
the continual polling of the remote repo for artifacts that are being 
built allowing for an online build that would pick up new third 
party/sister jars. The committed version number would be SNAPSHOT so 
that the automated build process (or anyone working with a fresh 
checkout) would see the latest version which is known to have built (ok, 
is supposed to have built).

A developer may get in trouble if they have a lot of uncommitted work 
and someone posts a new snapshot. Hopefully that would get fixed by an 
svn update and rebuild; if not, there are likely to be conflicts that 
need to be resolved anyway. This problem is of course reduced by 
committingn frequently :-)

The big upside though is that this should make the build more reliable 
for end-users.

--
Jeremy

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[si...@insession.com]

Jeremy Boynes <jb...@apache.org> wrote on 01/04/2005 02:17:48 PM:

> Geir Magnusson Jr wrote:
> > 
> > No, but I worry about just bundling random whatever from outside the 
> > project with our releases.  It would help to use the svn revision on 
the 
> > jar, but we should really make it clear that it's something the 
geronimo 
> > project created for it's use, rather than confuse people that it might 

> > be an artifact from ActiveMQ.  The word 'SNAPSHOT' would help.
> > 
> 
> SNAPSHOT has a specific meaning to Maven - it will cause it to check the 

> remote repo for a newer version (by timestamp) even if a copy exists in 
> the local repo.
> 
> This is good for daily builds, a nightmare for anything where 
> consistency is required.
> 
> So when we decide to do a milestone (or release) we need to ensure there 

> are no dependencies on versions with SNAPSHOT in them and instead use 
> ones that contain a SVN revision number or a CVS timestamp:
> 
> bad:    foo-bar-1.3-SNAPSHOT.jar
> ok:     foo-bar-1.3-20050401.jar
> better: foo-bar-1.3-158653.jar

+1 for foo-bar-1.3-158653.jar

I often wonder whether we would have a more stable daily build environment 
if we also use dependencies with versions in them.  Currently there is no 
easy way to guarantee that an online build will work, as an unversioned 
SNAPSHOT that is updated could break the build.

It would be nice to be able to say that today's daily build (where all 
tests passed) used the following dependencies: foo-bar-1.3-158653.jar, 
etc...  Therefore if we used versioned dependencies there would be a 
higher chance that if you wanted to build Geronimo at a particular 
revision (e.g. 14 days ago) that it would build successfully (assuming 
those versioned dependencies are still around).

To be able to do this effectively, we would need a tool that tells us when 
there is a newer version available in a remote repository.  When a newer 
version is available, a developer (or a continuous integration tool) can 
change their local copy of the code to use the newer version and test 
compatibility with that version and if all is ok, commit the change. 

Currently, all developers are exposed to updates to SNAPSHOTS and 
sometimes the build can be broken for days.  If you don't have a backup of 
your previously building code (and repository?), one is in trouble if they 
want rebuild (e.g. an offline build) a working version.

I haven't thought this through too much, but have never felt comfortable 
with SNAPSHOTs.  Could versioned dependencies help us here?

John

> 
> --
> Jeremy

This e-mail message and any attachments may contain confidential, 
proprietary or non-public information.  This information is intended 
solely for the designated recipient(s).  If an addressing or transmission 
error has misdirected this e-mail, please notify the sender immediately 
and destroy this e-mail.  Any review, dissemination, use or reliance upon 
this information by unintended recipients is prohibited.  Any opinions 
expressed in this e-mail are those of the author personally.

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Thu, 31 Mar 2005, Jeremy Boynes wrote:

> So when we decide to do a milestone (or release) we need to ensure there
> are no dependencies on versions with SNAPSHOT in them and instead use
> ones that contain a SVN revision number or a CVS timestamp:
>
> bad:    foo-bar-1.3-SNAPSHOT.jar
> ok:     foo-bar-1.3-20050401.jar
> better: foo-bar-1.3-158653.jar

If you are truly paranoid - then have the dependency not just lis thte
name; but also mention the MD5 or some UUID (and have the UUID resolve
into the full name, some date, file length and MD5). I.e. adding a level
of indirection to make the metadata richer; leaving room for things like
xml sig's in the future.

Dw

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Apr 1, 2005, at 9:36 AM, Hiram Chirino wrote:

>
> On Apr 1, 2005, at 4:53 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote:
>>
>>> Geir Magnusson Jr wrote:
>>>> No, but I worry about just bundling random whatever from outside 
>>>> the project with our releases.  It would help to use the svn 
>>>> revision on the jar, but we should really make it clear that it's 
>>>> something the geronimo project created for it's use, rather than 
>>>> confuse people that it might be an artifact from ActiveMQ.  The 
>>>> word 'SNAPSHOT' would help.
>>>
>>> SNAPSHOT has a specific meaning to Maven - it will cause it to check 
>>> the remote repo for a newer version (by timestamp) even if a copy 
>>> exists in the local repo.
>>>
>>> This is good for daily builds, a nightmare for anything where 
>>> consistency is required.
>>>
>>> So when we decide to do a milestone (or release) we need to ensure 
>>> there are no dependencies on versions with SNAPSHOT in them and 
>>> instead use ones that contain a SVN revision number or a CVS 
>>> timestamp:
>>>
>>> bad:    foo-bar-1.3-SNAPSHOT.jar
>>> ok:     foo-bar-1.3-20050401.jar
>>> better: foo-bar-1.3-158653.jar
>>
>> Going back to the original issue of an external project not wishing 
>> to do a release, we want to make it clear that this is something that 
>> we threw together ad hoc, and not something published by the external 
>> project.
>>
>
> The upside to having a geronimo committer build the artifact himself 
> from source is that you have a better oversight in knowing from what 
> source code a binary was produced.  Perhaps we should tag the file 
> name with something, so it obvious it's an ad hoc build that an apache 
> committer through together.

Yep!

>
>> And I'm still not comfortable doing something like that in a real 
>> geronimo release.
>>
>
> I agree it's not the best solution, but it's something we have to deal 
> with.  Unless you are willing to hold up on doing geronimo releases 
> until all it's dependent software does an official release.  And then 
> this would apply transitively, such that you would have to wait till a 
> SNAPSHOT dependency of activemq is has been officially released.  etc.
>

Well, yah, sorta.  Milestones are less of a problem but "real" versions?

I don't think that we would be happy with some other project 
distributing jars called "geronimo-kernel-xxxx.jar" or the like.  Not 
only could it mean misery and pain in support, but also risk to 
reputation, and possibility of it containing code that we'd never 
release.  The last thing we need is to explain to someone that a 
geronimo jar containing BEA code (or whatever) really isn't a Geronimo 
jar.

I certainly feel the pain of the problem.  But if we can do whatever we 
can to get the other projects to do even 'beta' or 'rcx' releases... 
Hiram, do you know any influential committers on ActiveMQ? :D

geir


> Regards,
> Hiram
>
>> geir
>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geirm@apache.org
>>
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Apr 5, 2005, at 12:47 AM, Niclas Hedhman wrote:

> On Monday 04 April 2005 19:43, Geir Magnusson Jr. wrote:
>> Maybe
>>
>> foo-bar-1.3-ådhøc-gérönîmó-158653.jar
>
> FYI, the dots, rings and slashes are distinct different characters 
> (just like
> the difference between "a" and "e") and not variants of the base 
> character.

I know.  Just like I know that speaking louder and slower doesn't make 
english any more understandable to those that don't speak it.

I was just joking.

geir

> Please don't allow the Phreakers in ASF...
>
>
> Thanks
> Niclas
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 04 April 2005 19:43, Geir Magnusson Jr. wrote:
> Maybe
>
> foo-bar-1.3-ådhøc-gérönîmó-158653.jar

FYI, the dots, rings and slashes are distinct different characters (just like 
the difference between "a" and "e") and not variants of the base character. 
Please don't allow the Phreakers in ASF...


Thanks
Niclas

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Apr 1, 2005, at 12:01 PM, Alan D. Cabrera wrote:

>
>
> Hiram Chirino wrote:
>
>>
>> On Apr 1, 2005, at 4:53 AM, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote:
>>>
>>>> Geir Magnusson Jr wrote:
>>>>
>>>>> No, but I worry about just bundling random whatever from outside 
>>>>> the project with our releases.  It would help to use the svn 
>>>>> revision on the jar, but we should really make it clear that it's 
>>>>> something the geronimo project created for it's use, rather than 
>>>>> confuse people that it might be an artifact from ActiveMQ.  The 
>>>>> word 'SNAPSHOT' would help.
>>>>
>>>>
>>>> SNAPSHOT has a specific meaning to Maven - it will cause it to 
>>>> check the remote repo for a newer version (by timestamp) even if a 
>>>> copy exists in the local repo.
>>>>
>>>> This is good for daily builds, a nightmare for anything where 
>>>> consistency is required.
>>>>
>>>> So when we decide to do a milestone (or release) we need to ensure 
>>>> there are no dependencies on versions with SNAPSHOT in them and 
>>>> instead use ones that contain a SVN revision number or a CVS 
>>>> timestamp:
>>>>
>>>> bad:    foo-bar-1.3-SNAPSHOT.jar
>>>> ok:     foo-bar-1.3-20050401.jar
>>>> better: foo-bar-1.3-158653.jar
>>>
>>>
>>> Going back to the original issue of an external project not wishing 
>>> to do a release, we want to make it clear that this is something 
>>> that we threw together ad hoc, and not something published by the 
>>> external project.
>>>
>>
>> The upside to having a geronimo committer build the artifact himself 
>> from source is that you have a better oversight in knowing from what 
>> source code a binary was produced.  Perhaps we should tag the file 
>> name with something, so it obvious it's an ad hoc build that an 
>> apache committer through together.
>
>
> foo-bar-1.3-adhoc-geronimo-158653.jar

works for me

>
> This way it's clear that this jar was specifically for an ad hoc 
> geronimo snapshot.  Another nice thing about having adhoc-geronimo in 
> the name is that when you browse your local repo, it's easy to spot 
> the ad hoc geronimo jars.  Finding these jars using the find command 
> is simplified when jars are "taged" with these tokens in their jar 
> names.
> I'm not married to the token adhoc-geronimo but, you get the idea.  
> Actually as I think about it, would one want to make the tag name as 
> unweldy as possible to deter non-geronimo projects from relying on our 
> maven repo as a means of distribution?

Yes.  We should ensure that they are outside of the 7bit ASCII space.

Maybe

foo-bar-1.3-ådhøc-gérönîmó-158653.jar

if we could get an unprintable character in there too, we'd be done.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Alan D. Cabrera" <ad...@toolazydogs.com>]

Hiram Chirino wrote:

>
> On Apr 1, 2005, at 4:53 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote:
>>
>>> Geir Magnusson Jr wrote:
>>>
>>>> No, but I worry about just bundling random whatever from outside 
>>>> the project with our releases.  It would help to use the svn 
>>>> revision on the jar, but we should really make it clear that it's 
>>>> something the geronimo project created for it's use, rather than 
>>>> confuse people that it might be an artifact from ActiveMQ.  The 
>>>> word 'SNAPSHOT' would help.
>>>
>>>
>>> SNAPSHOT has a specific meaning to Maven - it will cause it to check 
>>> the remote repo for a newer version (by timestamp) even if a copy 
>>> exists in the local repo.
>>>
>>> This is good for daily builds, a nightmare for anything where 
>>> consistency is required.
>>>
>>> So when we decide to do a milestone (or release) we need to ensure 
>>> there are no dependencies on versions with SNAPSHOT in them and 
>>> instead use ones that contain a SVN revision number or a CVS timestamp:
>>>
>>> bad:    foo-bar-1.3-SNAPSHOT.jar
>>> ok:     foo-bar-1.3-20050401.jar
>>> better: foo-bar-1.3-158653.jar
>>
>>
>> Going back to the original issue of an external project not wishing 
>> to do a release, we want to make it clear that this is something that 
>> we threw together ad hoc, and not something published by the external 
>> project.
>>
>
> The upside to having a geronimo committer build the artifact himself 
> from source is that you have a better oversight in knowing from what 
> source code a binary was produced.  Perhaps we should tag the file 
> name with something, so it obvious it's an ad hoc build that an apache 
> committer through together.


foo-bar-1.3-adhoc-geronimo-158653.jar

This way it's clear that this jar was specifically for an ad hoc 
geronimo snapshot.  Another nice thing about having adhoc-geronimo in 
the name is that when you browse your local repo, it's easy to spot the 
ad hoc geronimo jars.  Finding these jars using the find command is 
simplified when jars are "taged" with these tokens in their jar names. 

I'm not married to the token adhoc-geronimo but, you get the idea.  
Actually as I think about it, would one want to make the tag name as 
unweldy as possible to deter non-geronimo projects from relying on our 
maven repo as a means of distribution?


Regards,
Alan

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

On Apr 1, 2005, at 4:53 AM, Geir Magnusson Jr. wrote:

>
> On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote:
>
>> Geir Magnusson Jr wrote:
>>> No, but I worry about just bundling random whatever from outside the 
>>> project with our releases.  It would help to use the svn revision on 
>>> the jar, but we should really make it clear that it's something the 
>>> geronimo project created for it's use, rather than confuse people 
>>> that it might be an artifact from ActiveMQ.  The word 'SNAPSHOT' 
>>> would help.
>>
>> SNAPSHOT has a specific meaning to Maven - it will cause it to check 
>> the remote repo for a newer version (by timestamp) even if a copy 
>> exists in the local repo.
>>
>> This is good for daily builds, a nightmare for anything where 
>> consistency is required.
>>
>> So when we decide to do a milestone (or release) we need to ensure 
>> there are no dependencies on versions with SNAPSHOT in them and 
>> instead use ones that contain a SVN revision number or a CVS 
>> timestamp:
>>
>> bad:    foo-bar-1.3-SNAPSHOT.jar
>> ok:     foo-bar-1.3-20050401.jar
>> better: foo-bar-1.3-158653.jar
>
> Going back to the original issue of an external project not wishing to 
> do a release, we want to make it clear that this is something that we 
> threw together ad hoc, and not something published by the external 
> project.
>

The upside to having a geronimo committer build the artifact himself 
from source is that you have a better oversight in knowing from what 
source code a binary was produced.  Perhaps we should tag the file name 
with something, so it obvious it's an ad hoc build that an apache 
committer through together.

> And I'm still not comfortable doing something like that in a real 
> geronimo release.
>

I agree it's not the best solution, but it's something we have to deal 
with.  Unless you are willing to hold up on doing geronimo releases 
until all it's dependent software does an official release.  And then 
this would apply transitively, such that you would have to wait till a 
SNAPSHOT dependency of activemq is has been officially released.  etc.

Regards,
Hiram

> geir
>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Mar 31, 2005, at 11:17 PM, Jeremy Boynes wrote:

> Geir Magnusson Jr wrote:
>> No, but I worry about just bundling random whatever from outside the 
>> project with our releases.  It would help to use the svn revision on 
>> the jar, but we should really make it clear that it's something the 
>> geronimo project created for it's use, rather than confuse people 
>> that it might be an artifact from ActiveMQ.  The word 'SNAPSHOT' 
>> would help.
>
> SNAPSHOT has a specific meaning to Maven - it will cause it to check 
> the remote repo for a newer version (by timestamp) even if a copy 
> exists in the local repo.
>
> This is good for daily builds, a nightmare for anything where 
> consistency is required.
>
> So when we decide to do a milestone (or release) we need to ensure 
> there are no dependencies on versions with SNAPSHOT in them and 
> instead use ones that contain a SVN revision number or a CVS 
> timestamp:
>
> bad:    foo-bar-1.3-SNAPSHOT.jar
> ok:     foo-bar-1.3-20050401.jar
> better: foo-bar-1.3-158653.jar

Going back to the original issue of an external project not wishing to 
do a release, we want to make it clear that this is something that we 
threw together ad hoc, and not something published by the external 
project.

And I'm still not comfortable doing something like that in a real 
geronimo release.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Jeremy Boynes <jb...@apache.org>]

Geir Magnusson Jr wrote:
> 
> No, but I worry about just bundling random whatever from outside the 
> project with our releases.  It would help to use the svn revision on the 
> jar, but we should really make it clear that it's something the geronimo 
> project created for it's use, rather than confuse people that it might 
> be an artifact from ActiveMQ.  The word 'SNAPSHOT' would help.
> 

SNAPSHOT has a specific meaning to Maven - it will cause it to check the 
remote repo for a newer version (by timestamp) even if a copy exists in 
the local repo.

This is good for daily builds, a nightmare for anything where 
consistency is required.

So when we decide to do a milestone (or release) we need to ensure there 
are no dependencies on versions with SNAPSHOT in them and instead use 
ones that contain a SVN revision number or a CVS timestamp:

bad:    foo-bar-1.3-SNAPSHOT.jar
ok:     foo-bar-1.3-20050401.jar
better: foo-bar-1.3-158653.jar

--
Jeremy

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Mar 31, 2005, at 8:40 PM, Hiram Chirino wrote:

>
>>>>>>>
>>>>>>> It could.  But the main argument to keep old numbered snapshot 
>>>>>>> jars is so that you can build an old source release of of 
>>>>>>> geronimo that might depend on a old numbered snapshot release.
>>>>>>
>>>>>> How?  do we ever list the snapshot number in project.xml?
>>>>>
>>>>> I think for a release, yes..  we should take the effort and 
>>>>> specify the snapshot number.
>>>>
>>>> I'm confused, and want to make sure we're not just talking past 
>>>> each other accidentally.  For a release, we don't use snapshots 
>>>> anyway, right?  We'd generate a set of jars all with the release 
>>>> version number in the filename.
>>>>
>>>
>>> Not sure why you think we would not use snapshots.  For example, if 
>>> we were releasing M4, it would have to ship with a SNAPSHOT of 
>>> activemq 3.0 since it's not ready to be released yet.  We would 
>>> generate numbered snapshot using the svn revision number of the 
>>> activemq sources.
>>
>> Ah - of other stuff.  I figured there was something missing.
>>
>> Interesting question.  Could we ask ActiveMQ to do a 
>> ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call 
>> it)?  yes, that would be a snapshot, but since it better be a 
>> functional snapshot (rather than somewhat random), couldn't that be a 
>> milestone release from ActiveMQ if we asked really, really nicely?
>>
>
> What's the difference between that and me building a 
> ActiveMQ-3.0-20050115-SNAPSHOT.jar ??  It's the same in my eyes.  The 
> ActiveMQ folks don't want to keep snapshots like that around since 
> that just increases the release management overhead.  ActiveMQ likes 
> to keep it simple... we don't do mile stones or release candidates or 
> alphas or betas or any of that stuff.
>
> I think we just need to be flexible.  Other projects in the future may 
> not be able to do a release just for a Milestone release of Geronimo.

No, but I worry about just bundling random whatever from outside the 
project with our releases.  It would help to use the svn revision on 
the jar, but we should really make it clear that it's something the 
geronimo project created for it's use, rather than confuse people that 
it might be an artifact from ActiveMQ.  The word 'SNAPSHOT' would help.

I also would have thought that the ActiveMQ project wouldn't want 
activeMQ-*.jar floating around out there where they didn't choose *...

We'll figure it out...

geir

>
> Regards,
> Hiram
>
>
>> geir
>>
>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geir@gluecode.com
>>
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

On Mar 31, 2005, at 8:55 PM, David Jencks wrote:

> for subversion-ized projects I think it makes a lot more sense to use 
> a svn revision number as the jar id than a date.
>
+1
Regards,
Hiram
> david jencks
>
> On Mar 31, 2005, at 5:40 PM, Hiram Chirino wrote:
>
>>
>>>>>>>>
>>>>>>>> It could.  But the main argument to keep old numbered snapshot 
>>>>>>>> jars is so that you can build an old source release of of 
>>>>>>>> geronimo that might depend on a old numbered snapshot release.
>>>>>>>
>>>>>>> How?  do we ever list the snapshot number in project.xml?
>>>>>>
>>>>>> I think for a release, yes..  we should take the effort and 
>>>>>> specify the snapshot number.
>>>>>
>>>>> I'm confused, and want to make sure we're not just talking past 
>>>>> each other accidentally.  For a release, we don't use snapshots 
>>>>> anyway, right?  We'd generate a set of jars all with the release 
>>>>> version number in the filename.
>>>>>
>>>>
>>>> Not sure why you think we would not use snapshots.  For example, if 
>>>> we were releasing M4, it would have to ship with a SNAPSHOT of 
>>>> activemq 3.0 since it's not ready to be released yet.  We would 
>>>> generate numbered snapshot using the svn revision number of the 
>>>> activemq sources.
>>>
>>> Ah - of other stuff.  I figured there was something missing.
>>>
>>> Interesting question.  Could we ask ActiveMQ to do a 
>>> ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call 
>>> it)?  yes, that would be a snapshot, but since it better be a 
>>> functional snapshot (rather than somewhat random), couldn't that be 
>>> a milestone release from ActiveMQ if we asked really, really nicely?
>>>
>>
>> What's the difference between that and me building a 
>> ActiveMQ-3.0-20050115-SNAPSHOT.jar ??  It's the same in my eyes.  The 
>> ActiveMQ folks don't want to keep snapshots like that around since 
>> that just increases the release management overhead.  ActiveMQ likes 
>> to keep it simple... we don't do mile stones or release candidates or 
>> alphas or betas or any of that stuff.
>>
>> I think we just need to be flexible.  Other projects in the future 
>> may not be able to do a release just for a Milestone release of 
>> Geronimo.
>>
>> Regards,
>> Hiram
>>
>>
>>> geir
>>>
>>>
>>> -- 
>>> Geir Magnusson Jr                                  +1-203-665-6437
>>> geir@gluecode.com
>>>
>>
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[David Jencks <da...@yahoo.com>]

for subversion-ized projects I think it makes a lot more sense to use a 
svn revision number as the jar id than a date.

david jencks

On Mar 31, 2005, at 5:40 PM, Hiram Chirino wrote:

>
>>>>>>>
>>>>>>> It could.  But the main argument to keep old numbered snapshot 
>>>>>>> jars is so that you can build an old source release of of 
>>>>>>> geronimo that might depend on a old numbered snapshot release.
>>>>>>
>>>>>> How?  do we ever list the snapshot number in project.xml?
>>>>>
>>>>> I think for a release, yes..  we should take the effort and 
>>>>> specify the snapshot number.
>>>>
>>>> I'm confused, and want to make sure we're not just talking past 
>>>> each other accidentally.  For a release, we don't use snapshots 
>>>> anyway, right?  We'd generate a set of jars all with the release 
>>>> version number in the filename.
>>>>
>>>
>>> Not sure why you think we would not use snapshots.  For example, if 
>>> we were releasing M4, it would have to ship with a SNAPSHOT of 
>>> activemq 3.0 since it's not ready to be released yet.  We would 
>>> generate numbered snapshot using the svn revision number of the 
>>> activemq sources.
>>
>> Ah - of other stuff.  I figured there was something missing.
>>
>> Interesting question.  Could we ask ActiveMQ to do a 
>> ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call 
>> it)?  yes, that would be a snapshot, but since it better be a 
>> functional snapshot (rather than somewhat random), couldn't that be a 
>> milestone release from ActiveMQ if we asked really, really nicely?
>>
>
> What's the difference between that and me building a 
> ActiveMQ-3.0-20050115-SNAPSHOT.jar ??  It's the same in my eyes.  The 
> ActiveMQ folks don't want to keep snapshots like that around since 
> that just increases the release management overhead.  ActiveMQ likes 
> to keep it simple... we don't do mile stones or release candidates or 
> alphas or betas or any of that stuff.
>
> I think we just need to be flexible.  Other projects in the future may 
> not be able to do a release just for a Milestone release of Geronimo.
>
> Regards,
> Hiram
>
>
>> geir
>>
>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geir@gluecode.com
>>
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

>>>>>>
>>>>>> It could.  But the main argument to keep old numbered snapshot 
>>>>>> jars is so that you can build an old source release of of 
>>>>>> geronimo that might depend on a old numbered snapshot release.
>>>>>
>>>>> How?  do we ever list the snapshot number in project.xml?
>>>>
>>>> I think for a release, yes..  we should take the effort and specify 
>>>> the snapshot number.
>>>
>>> I'm confused, and want to make sure we're not just talking past each 
>>> other accidentally.  For a release, we don't use snapshots anyway, 
>>> right?  We'd generate a set of jars all with the release version 
>>> number in the filename.
>>>
>>
>> Not sure why you think we would not use snapshots.  For example, if 
>> we were releasing M4, it would have to ship with a SNAPSHOT of 
>> activemq 3.0 since it's not ready to be released yet.  We would 
>> generate numbered snapshot using the svn revision number of the 
>> activemq sources.
>
> Ah - of other stuff.  I figured there was something missing.
>
> Interesting question.  Could we ask ActiveMQ to do a 
> ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call 
> it)?  yes, that would be a snapshot, but since it better be a 
> functional snapshot (rather than somewhat random), couldn't that be a 
> milestone release from ActiveMQ if we asked really, really nicely?
>

What's the difference between that and me building a 
ActiveMQ-3.0-20050115-SNAPSHOT.jar ??  It's the same in my eyes.  The 
ActiveMQ folks don't want to keep snapshots like that around since that 
just increases the release management overhead.  ActiveMQ likes to keep 
it simple... we don't do mile stones or release candidates or alphas or 
betas or any of that stuff.

I think we just need to be flexible.  Other projects in the future may 
not be able to do a release just for a Milestone release of Geronimo.

Regards,
Hiram


> geir
>
>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geir@gluecode.com
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Mar 31, 2005, at 8:15 PM, Hiram Chirino wrote:

>
> On Mar 31, 2005, at 7:35 PM, Geir Magnusson Jr wrote:
>
>>
>> On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote:
>>
>>>
>>> On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote:
>>>
>>>>
>>>> On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote:
>>>>
>>>>>
>>>>>>>>
>>>>>>>> I think we should keep as much history as possible, at least 
>>>>>>>> the dependencies for all maintained branches.
>>>>>>>
>>>>>>> I would say, we never remove a jar.  A SNAPSHOT jar should just 
>>>>>>> be a simlink to a numbered jar (this is what maven does 
>>>>>>> already).
>>>>>>
>>>>>> Re the snapshots, doesn't that result in piles of useless crap?  
>>>>>> I mean, why keep the old numbered jars around?  The build 
>>>>>> conditions for them are variable at best, and I can't think of 
>>>>>> situations where you'd need to go and use an old one. ?
>>>>>>
>>>>>
>>>>> It could.  But the main argument to keep old numbered snapshot 
>>>>> jars is so that you can build an old source release of of geronimo 
>>>>> that might depend on a old numbered snapshot release.
>>>>
>>>> How?  do we ever list the snapshot number in project.xml?
>>>
>>> I think for a release, yes..  we should take the effort and specify 
>>> the snapshot number.
>>
>> I'm confused, and want to make sure we're not just talking past each 
>> other accidentally.  For a release, we don't use snapshots anyway, 
>> right?  We'd generate a set of jars all with the release version 
>> number in the filename.
>>
>
> Not sure why you think we would not use snapshots.  For example, if we 
> were releasing M4, it would have to ship with a SNAPSHOT of activemq 
> 3.0 since it's not ready to be released yet.  We would generate 
> numbered snapshot using the svn revision number of the activemq 
> sources.

Ah - of other stuff.  I figured there was something missing.

Interesting question.  Could we ask ActiveMQ to do a 
ActiveMQ-3.0-pre-alpha-don'tuse.jar (or whatever they wanted to call 
it)?  yes, that would be a snapshot, but since it better be a 
functional snapshot (rather than somewhat random), couldn't that be a 
milestone release from ActiveMQ if we asked really, really nicely?

geir


-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

On Mar 31, 2005, at 7:35 PM, Geir Magnusson Jr wrote:

>
> On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote:
>
>>
>> On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote:
>>
>>>
>>> On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote:
>>>
>>>>
>>>>>>>
>>>>>>> I think we should keep as much history as possible, at least the 
>>>>>>> dependencies for all maintained branches.
>>>>>>
>>>>>> I would say, we never remove a jar.  A SNAPSHOT jar should just 
>>>>>> be a simlink to a numbered jar (this is what maven does already).
>>>>>
>>>>> Re the snapshots, doesn't that result in piles of useless crap?  I 
>>>>> mean, why keep the old numbered jars around?  The build conditions 
>>>>> for them are variable at best, and I can't think of situations 
>>>>> where you'd need to go and use an old one. ?
>>>>>
>>>>
>>>> It could.  But the main argument to keep old numbered snapshot jars 
>>>> is so that you can build an old source release of of geronimo that 
>>>> might depend on a old numbered snapshot release.
>>>
>>> How?  do we ever list the snapshot number in project.xml?
>>
>> I think for a release, yes..  we should take the effort and specify 
>> the snapshot number.
>
> I'm confused, and want to make sure we're not just talking past each 
> other accidentally.  For a release, we don't use snapshots anyway, 
> right?  We'd generate a set of jars all with the release version 
> number in the filename.
>

Not sure why you think we would not use snapshots.  For example, if we 
were releasing M4, it would have to ship with a SNAPSHOT of activemq 
3.0 since it's not ready to be released yet.  We would generate 
numbered snapshot using the svn revision number of the activemq 
sources.

Regards,
Hiram

> geir
>
>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geir@gluecode.com
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Mar 31, 2005, at 6:30 PM, Hiram Chirino wrote:

>
> On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote:
>
>>
>> On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote:
>>
>>>
>>>>>>
>>>>>> I think we should keep as much history as possible, at least the 
>>>>>> dependencies for all maintained branches.
>>>>>
>>>>> I would say, we never remove a jar.  A SNAPSHOT jar should just be 
>>>>> a simlink to a numbered jar (this is what maven does already).
>>>>
>>>> Re the snapshots, doesn't that result in piles of useless crap?  I 
>>>> mean, why keep the old numbered jars around?  The build conditions 
>>>> for them are variable at best, and I can't think of situations 
>>>> where you'd need to go and use an old one. ?
>>>>
>>>
>>> It could.  But the main argument to keep old numbered snapshot jars 
>>> is so that you can build an old source release of of geronimo that 
>>> might depend on a old numbered snapshot release.
>>
>> How?  do we ever list the snapshot number in project.xml?
>
> I think for a release, yes..  we should take the effort and specify 
> the snapshot number.

I'm confused, and want to make sure we're not just talking past each 
other accidentally.  For a release, we don't use snapshots anyway, 
right?  We'd generate a set of jars all with the release version number 
in the filename.

geir


-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

On Mar 31, 2005, at 6:17 PM, Geir Magnusson Jr wrote:

>
> On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote:
>
>>
>>>>>
>>>>> I think we should keep as much history as possible, at least the 
>>>>> dependencies for all maintained branches.
>>>>
>>>> I would say, we never remove a jar.  A SNAPSHOT jar should just be 
>>>> a simlink to a numbered jar (this is what maven does already).
>>>
>>> Re the snapshots, doesn't that result in piles of useless crap?  I 
>>> mean, why keep the old numbered jars around?  The build conditions 
>>> for them are variable at best, and I can't think of situations where 
>>> you'd need to go and use an old one. ?
>>>
>>
>> It could.  But the main argument to keep old numbered snapshot jars 
>> is so that you can build an old source release of of geronimo that 
>> might depend on a old numbered snapshot release.
>
> How?  do we ever list the snapshot number in project.xml?

I think for a release, yes..  we should take the effort and specify the 
snapshot number.

Regards,
Hiram

>
>>  Perhaps we only push numbered snapshot jar into our maven repo when 
>> we do a release, and we continue to use the public repos during 
>> development to get the unnumbered snapshots.
>>
>
> Do you really ever refer to snapshots by number?
>
> geir
>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geir@gluecode.com
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Geir Magnusson Jr <ge...@4quarters.com>]

On Mar 31, 2005, at 6:14 PM, Hiram Chirino wrote:

>
>>>>
>>>> I think we should keep as much history as possible, at least the 
>>>> dependencies for all maintained branches.
>>>
>>> I would say, we never remove a jar.  A SNAPSHOT jar should just be a 
>>> simlink to a numbered jar (this is what maven does already).
>>
>> Re the snapshots, doesn't that result in piles of useless crap?  I 
>> mean, why keep the old numbered jars around?  The build conditions 
>> for them are variable at best, and I can't think of situations where 
>> you'd need to go and use an old one. ?
>>
>
> It could.  But the main argument to keep old numbered snapshot jars is 
> so that you can build an old source release of of geronimo that might 
> depend on a old numbered snapshot release.

How?  do we ever list the snapshot number in project.xml?

>  Perhaps we only push numbered snapshot jar into our maven repo when 
> we do a release, and we continue to use the public repos during 
> development to get the unnumbered snapshots.
>

Do you really ever refer to snapshots by number?

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Hiram Chirino <hi...@hiramchirino.com>]

>>>
>>> I think we should keep as much history as possible, at least the 
>>> dependencies for all maintained branches.
>>
>> I would say, we never remove a jar.  A SNAPSHOT jar should just be a 
>> simlink to a numbered jar (this is what maven does already).
>
> Re the snapshots, doesn't that result in piles of useless crap?  I 
> mean, why keep the old numbered jars around?  The build conditions for 
> them are variable at best, and I can't think of situations where you'd 
> need to go and use an old one. ?
>

It could.  But the main argument to keep old numbered snapshot jars is 
so that you can build an old source release of of geronimo that might 
depend on a old numbered snapshot release.  Perhaps we only push 
numbered snapshot jar into our maven repo when we do a release, and we 
continue to use the public repos during development to get the 
unnumbered snapshots.

Regards,
Hiram

> geir
>
>>
>> -dain
>>
>>
> -- 
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
>

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

["Geir Magnusson Jr." <ge...@apache.org>]

On Mar 31, 2005, at 4:15 PM, Dain Sundstrom wrote:

> On Mar 31, 2005, at 12:54 PM, Jeremy Boynes wrote:
>
>>> - include a license file for each third-party artifact we have
>>
>> This is a normal feature of a Maven repo. We should also require that 
>> an appropriate POM is installed so that contributors can be 
>> identified.
>
> This will be a problem for ant based projects.  I propose we have a 
> minimal pom we use for these types of projects.

Y

>
>>> - include a INFO file for each third-party artifact containing
>>>     - source of jar
>>>     - source's statement about redistribution
>>
>> We should also include INFO for each release identifying the 
>> third-party jars that it uses. This means there is an easier place to 
>> look than the content of a distribution.
>
> Can't we use the pom dependencies section for this, or are you 
> thinking of something else?

As long as it's easy and obvious to to a browser who doen't grok 
maven...

>
>>> Contents
>>> --------
>>> - top-level index page clearly describing purpose and intent of 
>>> repository (0)
>>> - all third-party dependencies needed by current and recent-in-time 
>>> build (1)
>>> - snapshot versions of Geronimo build artifacts for "sister" 
>>> projects like OpenEJB that have a [soon-to-go-away] tight dependency 
>>> on core geronimo code
>>> - release versions of Geronimo build artifacts (maybe not..)
>>> (0) can we add a short note put into our maven output that says 
>>> "Geronimmo 3rd party dependencies will be sourced from the 
>>> project-specific geronimo repository" or such?
>>> (1) Do we want to keep old stuff?  I think not - I think we'd want 
>>> to be good ASF citizens to keep disk space usage to what is really 
>>> needed.  If you need an older version, for some reason, you can slog 
>>> it out of ibiblio or the original source.
>>
>> I think we should keep as much history as possible, at least the 
>> dependencies for all maintained branches.
>
> I would say, we never remove a jar.  A SNAPSHOT jar should just be a 
> simlink to a numbered jar (this is what maven does already).

Re the snapshots, doesn't that result in piles of useless crap?  I 
mean, why keep the old numbered jars around?  The build conditions for 
them are variable at best, and I can't think of situations where you'd 
need to go and use an old one. ?

>
> Actually, the only SNAPSHOTs I think we should have in our repo are 
> for OpenEJB because of the overhead that would be involved in using 
> versioned releases.  Once we clean up the interfaces between Geronimo 
> and OpenEJB, I think we should switch to fully versioned jars (this is 
> what happened with activeMQ once we got the interfaces cleaned up).

I thought we also might have geronimo snapshots, because then 
non-geronimo openejb developers (if there are such that are active ;)  
could build openejb w/o having to have HEAD of G locally and built...  
That's the only reason I can think of (and it applies to any project 
that wants to tie closely to us...)

geir

>
> -dain
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Dain Sundstrom <ds...@gluecode.com>]

On Mar 31, 2005, at 12:54 PM, Jeremy Boynes wrote:

>> - include a license file for each third-party artifact we have
>
> This is a normal feature of a Maven repo. We should also require that 
> an appropriate POM is installed so that contributors can be 
> identified.

This will be a problem for ant based projects.  I propose we have a 
minimal pom we use for these types of projects.

>> - include a INFO file for each third-party artifact containing
>>     - source of jar
>>     - source's statement about redistribution
>
> We should also include INFO for each release identifying the 
> third-party jars that it uses. This means there is an easier place to 
> look than the content of a distribution.

Can't we use the pom dependencies section for this, or are you thinking 
of something else?

>> Contents
>> --------
>> - top-level index page clearly describing purpose and intent of 
>> repository (0)
>> - all third-party dependencies needed by current and recent-in-time 
>> build (1)
>> - snapshot versions of Geronimo build artifacts for "sister" projects 
>> like OpenEJB that have a [soon-to-go-away] tight dependency on core 
>> geronimo code
>> - release versions of Geronimo build artifacts (maybe not..)
>> (0) can we add a short note put into our maven output that says 
>> "Geronimmo 3rd party dependencies will be sourced from the 
>> project-specific geronimo repository" or such?
>> (1) Do we want to keep old stuff?  I think not - I think we'd want to 
>> be good ASF citizens to keep disk space usage to what is really 
>> needed.  If you need an older version, for some reason, you can slog 
>> it out of ibiblio or the original source.
>
> I think we should keep as much history as possible, at least the 
> dependencies for all maintained branches.

I would say, we never remove a jar.  A SNAPSHOT jar should just be a 
simlink to a numbered jar (this is what maven does already).

Actually, the only SNAPSHOTs I think we should have in our repo are for 
OpenEJB because of the overhead that would be involved in using 
versioned releases.  Once we clean up the interfaces between Geronimo 
and OpenEJB, I think we should switch to fully versioned jars (this is 
what happened with activeMQ once we got the interfaces cleaned up).

-dain

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Jeremy Boynes <jb...@apache.org>]

I think this is a good start in the right direction. The need for 
demonstrable oversight is clear and if anything I would like to 
strengthen those processes not loosen them. Some of that is already 
built into Maven and we should use those capabilities.

More comments inline, all fine tuning.

--
Jeremy

Geir Magnusson Jr. wrote:
> Here's a proposal for the Geronimo PMC regarding running a maven 
> repository for the project here at the ASF.  The basic problem is that 
> there are many at the ASF, including board members, that believe that we 
> shouldn't publish or distribute software that isn't created at the ASF.  
> I was one of those until yesterday, when I thought it through for a 
> bit.   I've started some private conversations with those I know have 
> issues with the idea to get feedback early, and in parallel we can work 
> out a plan and incorporate their feedback if this has a chance of 
> acceptance (I think it should...).
> 
> Note that there is a "slippery-slope" argument against this for which 
> there is no good answer other than the pragmatic "lets minimize risk and 
> see what happens"....
> 
> Motivation
> ----------
> 
> I) We want a fast, controlled source of project dependencies to make it 
> easy and fast to build Geronimo.
> 
>  We are able to include binary jars from other outside projects in our 
> official releases, because
> 
> a) it's clear that we are the publisher of the combined work
>    that is our release
> b) there has been sufficient oversight by the releasing PMC
>   to ensure that the licenses and re-distribution terms for
>   the third party jars are appropriate
> 
> In order to do have a maven repo that includes third party jars, we must
> 
> a) make it clear that we are *NOT* the publisher of the third party
>    jars, but we are just redistributing it under appropriate terms
>    as defined by the publisher
> b) we can demonstrate that the PMC had oversight and control
>    over the contents of the repository to monitor  the content,
>    license and re-dist terms
> 
> II) For any community member that is interested in tracking the external 
> dependencies (and there is an increased awareness in commercial users 
> due to liability and indemnification issues), the following proposal 
> provides a clear stream of specific messages never buried in commit 
> noise to allow an observer to track changes in project dependencies.
> 
> So the proposal is then to create a maven repository for the use of the 
> Geronimo project.  If the basic idea is sound, lets iron out the 
> details.  Here's a start :
> 
> Structure
> ---------
> - maven structure
> - include a license file for each third-party artifact we have

This is a normal feature of a Maven repo. We should also require that an 
appropriate POM is installed so that contributors can be identified.

> - include a INFO file for each third-party artifact containing
>     - source of jar
>     - source's statement about redistribution
> 

We should also include INFO for each release identifying the third-party 
jars that it uses. This means there is an easier place to look than the 
content of a distribution.

> Contents
> --------
> - top-level index page clearly describing purpose and intent of 
> repository (0)
> - all third-party dependencies needed by current and recent-in-time 
> build (1)
> - snapshot versions of Geronimo build artifacts for "sister" projects 
> like OpenEJB that have a [soon-to-go-away] tight dependency on core 
> geronimo code
> - release versions of Geronimo build artifacts (maybe not..)
> 
> (0) can we add a short note put into our maven output that says 
> "Geronimmo 3rd party dependencies will be sourced from the 
> project-specific geronimo repository" or such?
> (1) Do we want to keep old stuff?  I think not - I think we'd want to be 
> good ASF citizens to keep disk space usage to what is really needed.  If 
> you need an older version, for some reason, you can slog it out of 
> ibiblio or the original source.
> 

I think we should keep as much history as possible, at least the 
dependencies for all maintained branches.

> 
> Oversight and Process
> ---------------------
> - writable by all Geronimo committers only
> - openly readable (2)
> - any addition or update to the repo requires that
>   - INFO and LICENSE are added/updated if needed
>   - email sent to dev@ to inform community (3)
>   - change accepted by PMC by lazy consensus
> - any third-party jar that is not an official release (like OpenEJB 
> these days) but built from source by a Geronimo developer (w/ or w/o 
> patches) must be marked with "SNAPSHOT" to make it clear that jar isn't 
> a release from the originating project, nor an attempt by the Geronimo 
> project to create a release or a distributable for another project.

A grey area here is the "we need release 4.0.1 + these three patches" 
scenario (for example, as an emergency security fix). This would not be 
a SNAPSHOT but a revision/timestamp build of the project we depend on. I 
think clear notification, lazy consensus by the PMC and a plan to 
migrate to an offical release would be sufficient oversight - we just 
need to be clear about what is happening.

> - infrastructure will be informed when we create this to ensure that in 
> the event someone has a problem with something coming from our repo, 
> they'll be aware and can just yank offending artifact, and know to 
> inform the geronimo PMC about the issue
> 
> (2) for now...
> (3) we can find technology solutions to reduce the work later - lets 
> focus on the oversight process
> 
> I think that covers the basics.  Comments?
> 
> geir
> 

Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Thu, 31 Mar 2005, Geir Magnusson Jr. wrote:

>   We are able to include binary jars from other outside projects in our
> official releases, because
>
> a) it's clear that we are the publisher of the combined work
>     that is our release
> b) there has been sufficient oversight by the releasing PMC
>    to ensure that the licenses and re-distribution terms for
>    the third party jars are appropriate
 c) we are tracking those third party jars, ensuring that they
    are readily recognizable as third party (e.g. by putting them
    in a separate directory) and have full control to make sure that
    the license agreements are tracked.

> In order to do have a maven repo that includes third party jars, we must
>
> a) make it clear that we are *NOT* the publisher of the third party
>     jars, but we are just redistributing it under appropriate terms
>     as defined by the publisher
  c) and we track the license which allows us to re-distribute. This is
     usually the same license under which our users can re-distributed;
     though there are exceptions (think some of the SUN artefacts where
     the ASF secretariat has a separate document on file).
> b) we can demonstrate that the PMC had oversight and control
>     over the contents of the repository to monitor  the content,
>     license and re-dist terms

Dw.