> >Actually, this is similar to an idea I had. Last night I was trying
to
> >think of how to provide project-by-project customizable organization
of
> >their repository space. Then it hit me - A meta file
"repository.xml".
> >
> >
> Counter-proposal (just thinking aloud):
> Specify all dependencies repository paths explicitly (really, this is
> defining an urn:maven: URN scheme, without bothering to specify the
> prefix). Specify a short name/alias for your dependency in your
> project.xml. ie
>
> <dependency>
> <groupId>foo</groupId>
> <artifactId>bar</artifactId>
> <version>1.0</version>
> <jar>some-wacky-name-1.0-is-broken.not-a-jar</jar>
> </dependency>
>
> becomes:
> <dependency>
> <!-- id goes back to being the thing you use to refer to this
> thing from jelly-->
> <id>foo</id>
> <path>foo/jars/some-wacky-name-1.0-is-broken.not-a-jar</path>
> </dependency>
>
I'm not a fan of adding path to the POM. It requires developers to have
knowledge of each dependencies project's repository space. It also
prevents projects from manipulating (reorganizing) their project space
without worrying about breaking anyone dependent on its resources.
> This explains how you get to dependencies, but not how the project
comes
> up with its /own/ URN. We do this by making the current project's
naming
> rule explicit in your project.properties:
> maven.repopath.jar=megacorp.com/funky/${pom.id}-${pom.version}.jar
> or whatever. clearly projects that do want to build multiple artifacts
> could come up with their own naming convention, now its jellified; and
> the default rule that is used currently would be the default for this
> property.
>
> When it comes down to it, artifact ids are being used in jelly as
> aliases for more complex 'constructed' names which might as well be
> URNs. The version numbers, for example, are never used anywhere, apart
> from looking for the word 'SNAPSHOT'. The paths are also currently the
> same no matter what kind of repo is being used. Using explicit URNs
> means that URI-handling code can deal with breaking down the path
> elements if you want. You can have domain names or reverse domain
names
> in paths if you think these will help. Realising that aliases are just
> local names for dependencies means we can go back to simple ways of
> referring to specific dependencies from our jelly - you just use the
> short alias.
>
> PROS: gets rid of groupid, artifactid, <jar>, artifact name munging
> rules etc etc in one fell swoop.
I don't think this is a pro. Granted it needs to be cleaned up, and
restrictions(conventions) need to be agreed on once and for all, but I
feel that having general conventions (and restriction) w/ projected,
groupID, artifactID, version, and domain is desired. This provides
uniformity in dependencies, enough information to provide a clean
repository, freedom of extensibility for dependency providers (project
repository space admins), and ability to provide a distributed lookup
process.
Example for my proposal:
<dependency>
<id>commons-collections</id>
<version>SNAPSHOT</version>
<groupID>org.apache.jakarta.commons</groupId>
<domain>org.apache</domain>
<artifactID>optionalAPIs</artifactID>
</dependency>
NOTE: I included all elements (even optional ones, even though they
don't necessarily fit with the example dependency).
<domain> & <artifactID> are optional. If domain doesn't exist it is
considered to be == to <groupID>. Likewise <artifactID> would be == to
<id>
In this scenario the project's repository space (PRS) would be -
org/apache/jakarta/commons/commons-collections/
if no repository.xml file was found in this PRS/ then it would look for
the jars in the default directory jars/
However if the repository.xml existed, it could look something like this
(top of my head needs some work) ->
<project-repository>
<artifact name="optionalAPIs" location="additionalStuff/"/>
<artifact name="optionalAPIs" version="1.2"
path="release/optionalAPIs-1.2.jar"/>
<artifact id="commons-collections" location="jars"/>
</project-repository>
The artifact element can have the following attributes -
name = the short name (artifactID || id) of the dependency (or matching
rule, regular expression)
version = version matching rule (or matching rule, regular expression)
location = relative path - the file name will follow standard
<id>-<version>.jar
path = relative path to the file itself
>
> >PROS;
> >- Ultimate extensibility over time (consist extension point)
> >
> Your proposal kept the current layout as a way of navigating to the
> metadata. The URN proposal lets people organize the metadata the same
as
> the data.
Yes and no. my proposal keeps a standard layout for navigating to the
metadata, but improves upon the current layout.
>
> >- Very flexible in regards to project specific organization
> >
> URNs don't give a hoot about project organisation either.
But with URNs the developers depending on them will need to. This isn't
ideal. I shouldn't matter to the developers how the PRS is organized.
They just need to know I'm need this version of this project.
> >- Still provides default layout for *most* projects, since specific
> >project organization is probably going to be a rare thing
> >
> >
> Providing a default URN building rule lets people use the default
> layout. Providing flexible URN rules lets people do what the heck they
> want.
>
> >CONS:
> >- Need to tread carefully as far as performance is concerned (adding
xml
> >processing to artifacts may provide a bottleneck). I do feel though
> >that this is going to be a rare case for most projects.
> >
> The URN proposal gives repo layout flexibility (some might say
> "uncontrolled flexibility") without requiring the metadata facility to
> work yet. However I don't expect it to be adopted anytime soon as it
> breaks backward compatibility (its biggest CON), eg with the SNAPSHOT
> dependency flipping thang. It also prevents future layout reorgs,
since
> the URNs you provide act similarly to PURLs for the resources you
depend
> on. I don't see this as necessarily a bad thing.
I do. It is much more cumbersome for both the developers and dependency
providers, since they need to be able to communicate these to each other
and are very susceptible to unresolved dependency errors upon minor
changes.
By adding the domain we can also now provide dependency providers to
stand up and maintain their own repositories. Repositories that
dependencies exist in can be auto discovered through DNS lookup for
_mavenrepo._tcp.<domain>
- Dependency providers can move to different repositories with no fuss
- With the addition of the repository meta-info they can move/reorganize
PRS without screwing projects that depend on it.
- Mike
> As an example of how this might make life simpler, I can browse to a
dep
> on ibiblio that I need:
> http://www.ibiblio.org/maven/xerces/jars/xercesImpl-2.0.2.jar
> Then add it as a dependency like so:
> <dependency>
> <id>xml-parser</id>
> <path>xerces/jars/xercesImpl-2.0.2.jar</path>
> </dependency>
> ... without having to figure out how to turn that back into group,
> artifact id, version; and then change my xml parser to crimson like
so:
> <dependency>
> <id>xml-parser</id>
> <path>crimson/jars/crimson-1.1.3.jar</path>
> </dependency>
> ... without having to change my jelly that mentioned the "xml-parser"
> alias. This would be much simpler to explain to people than the
current
> scheme ;)
>
> Anyway, something to discuss.
>
> -Baz
>
>
>
>
>
> Privacy and Confidentiality Notice
>
> ------------------------------------------------
>
> The information contained in this E-Mail message is intended only for
the
> person or persons to whom it is addressed. Such information is
> confidential and privileged and no mistake in transmission is intended
to
> waive or compromise such privilege. If you have received it in error,
> please destroy it and notify us on the telephone number printed above.
If
> you do not receive complete and legible copies, please telephone us
> immediately. Any opinions expressed herein including attachments are
those
> of the author only. i-documentsystems Ltd. does not accept
responsibility
> for the accuracy or completeness of the information provided or for
any
> changes to this Email, however made, after it was sent. (Please note
that
> it is your responsibility to scan this message for viruses).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
