maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baptiste MATHUS ...@batmat.net>
Subject Re: Repository Roadmap
Date Fri, 18 Feb 2011 09:23:38 GMT
Hi,

2011/2/17 John Patrick <nhoj.patrick@gmail.com>

> Evening, Morning, Hello,
>
> I'm wondering if their is a roadmap for repository
> design/functionality. I'm thinking something along the lines of
> Debian's repository structure and standards.
>
> I've been working with Maven since 2005 usually in Off-Line
> environments, where Companies question using it because it is open
> source so where do they purchase support and how secure is it.
>
> Overview of Suggested Changes
>
> 1) sha256 Checksum
>   - Start using sha256 as the default checksum, as md5 can be forged
> given enough cpu power.
>

Why not, but as Brett said, md5&sha1 checksum are currently only used for
integrity, not for anything else.


>
> 3) Repository Hierarchy
>    - Merge snapshot and release repos and split central into sub
> directories
>

Sorry, but I feel this is nonsense. I for one want to keep my releases
eternally but I just don't care about losing snapshots. Typically you'd want
to have a strict backup policy for your releases. Snapshots are not to be
backed up, since they're transient by essence. Backing it up would just be a
waste of money and time.


>    - Strict publishing requirements for new core release repo
>    - Relaxed publishing requirements for open repo(s)
>    - Point pom to single repo and define what you are willing to accept
>    - repo/core/release states to clients, only accept valid checksum
> and signatures
>    - repo/open/release states to client, warn if checksum are missing
> or invalid and continue if you accept that risk
>
4) Core Publishing Requirements
>    - Everything must be Signed
>    - Everything mush have valid Checksum
>    - Everything must publish JavaDoc (if appropriate, e.g. for
> jar/war/ear packaged artifact)
>    - Everything must publish Source (if appropriate, e.g. for
> jar/war/ear packaged artifact)
>    - Everything mush have Open Source License
>    - Group ID must match project url,
>    - Everything for only core functionality e.g. "mvn clean install
> deploy site" using any "org.apache.maven.plugins".
>

I'm under the impression a good part of you ask if currently offered through
maven repository managers. I suppose you already use nexus, archiva or
artifactory.

What you're asking above (for example, always putting javadoc, source or so)
is something for example achievable using nexus professional and is called
staging profile/ruleset.


>
> 5) Main Publishing Requirements
>     - Same requirements as (4) Core but ignoring the core functionality
> comment
>
> 6) Open Publishing Requirements
>     - Everything accepted and also treated as untrusted.
>

See Nexus procurement for it I guess.


>
> 7) 3rdparty Publishing Requirements
>     - Probably wrong name, contains pom that are signed and checksum
> themself and refer to artifacts that can't be published to maven due
> to export/license restrictions.
>

"Can't be published", you say it all. But you still want it to be published
;-).  If oracle sues because one their jars is downloadable somewhere else
from their website, you will pay? :-)

Cheers

-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message