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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to