avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Maven Deployment
Date Sat, 28 Feb 2004 01:55:51 GMT
Mark R. Diggory wrote:

> 
> 
> Stephen McConnell wrote:
> 
>> Mark R. Diggory wrote:
>>
>>> Question 1, are the contents of your projects within the repository 
>>> currently managed under separate maven groupIds?
>>
>>
>>
>> Yes.
>>
>>> ie:
>>>  avalon-apps/                             17-Jan-2004 16:02    -
>>>  avalon-cornerstone/                      17-Jan-2004 16:02    -
>>>  avalon-extension/                        17-Jan-2004 16:02    -
>>>  avalon-framework/                        17-Jan-2004 16:02    -
>>>  avalon-phoenix/
>>> ...
>>>
>>> Or are you planning to deploy everything under one groupId?
>>>
>>> ie:
>>>  avalon/                                  17-Jan-2004 16:02    -
>>
>>
>>
>> No.
>>
>> My understanding is the that /avalon directory represents a root of a 
>> repository.  As such, something like avalon-activation represents a 
>> group identifier.
> 
> 
> 
> Hmm, this is something new to me, I'll have to bug Jason and see what he 
> says about it. Do you have any sort of reference to this in the Maven 
> Doc's?


My guess is that Jason will be in the dark on this. From my 
understanding of things it is possible to declare 
http://www.apache.or/dist/avalon as a remote maven.  Just with Leo for 
more details.


>>
>>
>>>
>>> Its important because there was some stray files in the avalon 
>>> directory and some duplication which I removed using symlinking much 
>>> of the contents of "avalon" into the various subcomponents.
>>>
>>> Ultimately, it would be good to alleviate the duplication documented 
>>> towards the bottom of the following report:
>>>
>>> http://www.apache.org/~henkp/md5/
>>
>>
>>
>> The info here is saying that the signature file (mine) is not good.  
>> Is there some additional information I can get as to the actual problem?
>>
> 
> Could it be that your Public Key isn't stored in KEYS (I didn't check)?
> http://www.apache.org/dist/avalon/KEYS


I'll dig.


>>>
>>> I do like the idea of having the repository contents nested into the 
>>> existing dist directories (like you've done within dist/avalon. 
>>> Unfortunately, it will take some time before Maven supports this 
>>> directory structure across projects, ie:
>>
>>
>>
>>
>> Actually - maven group ids are not interpreted by maven beyond a 
>> string identifier of a path.  You can define a group as "xxxx/yyy" and 
>> it will work just fine.
> 
> 
> Yes, but they are leaning heavily against that for some reason. But, 
> also there is the issue that you possibly have already built up external 
> dependencies against your projects, changing your groupId would reek 
> Havoc on the projects now dependent on you. this is an unfortunate side 
> effect of Maven's binding the id to an actual directory structure. There 
> is no room for change without hurting your users.


The is a build time versus runtime separation here.  Merlin build time 
uses the maven repository to resolve application artifacts but merlin 
runtime uses the avalon-repository implementation to handle runtime 
service management.  If we run into maven issues we can easily switch 
over to the avalon-repository implementation which provides full support 
for arbitrary nesting of group identifiers (plus a bunch of nice stuff 
relating to service bootstrapping).


>>
>>
>>> Where:
>>> http://www.apache.org/dist/avalon/avalon-activation/jars/...
>>> http://www.apache.org/dist/jakarta/commons/math/jars/...
>>>
>>> Actually are within the same Maven Repository located under:
>>> http://www.apache.org/dist/
>>
>>
>>
>> This is where we may have some degree of confusion.  My understanding 
>> is that the repo root (for avalon content) is 
>> http://www.apache.org/dist/avalon.  If that's incorrect then I've been 
>> responsible for putting a bunch of stuff in the wrong place.
>>
>> Stephen.
>>
> 
> I guess the big questions are:
> 
> What are your goals in having your repository contents relative to 
> "http://www.apache.org/dist/avalon"?


Today there are two distinct repositories:

   http://www.apache.org/avalon

     - this is where the PMC put stuff after valid PMC votes

   http://dpml.net

     - this is where I put stuff that is snapshot related (i.e.
       not sanctioned by a PMC vote)

     - dpml stuff is linked into maven stuff (what appears in dpml
       will appear in maven - mostly - unlesss I have a reason not
       to do so)


> Are you using the repository location as a remote repository for the 
> avalon subcomponent project development?

In principal yes - in practice no (as far as I know).

> Are external projects dependent on the "avalon repository" or are the 
> dependent on www.ibiblio.org/maven?

Generally speaking - ibiblio.org/maven
For anything related to Merlin then its:

     dpml.net (primary)
     ibiblio.org/maven (fall back)


> Do you submit requests to ibiblio to get your jars published or do you 
> have an ibiblio account and can do it yourself?


ourselves


> The point in us setting up the "java-repository" is that now all Apache 
> Projects are freed to have their release managers publish onto ibiblio 
> without any need to make requests to ibiblio or log onto their machines, 
> for all practical concerns ibiblio is now just a mirror of 
> java-repository content. This makes jar publishing to ibiblio a uniform 
> process across all Apache projects.

OK I need to know what exactly the expectations are.
Currently I'm publishing content every few days to dpml.  This is 
reflected in ibiblio/maven automatically.  I publish into 
www.apache.org/avalon following a valid PMC vote to publish. Is this 
consistent with your view of the world?


> 
> Ultimately we want the java-repository structure to merge conceptually 
> with both the "Repository Projects" URI Specification and the "dist" 
> directory contents:
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/URISyntax

My current feeling is that we are missing a solid version specification 
ad without this - nested group ids will be difficult to manager in a non 
tool-specific manner.

> I know it probably sounds ambitious, but I think it is possible.

Me too - but some decisions are needed!

Cheer, Steve.

> -Mark


-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message