additionally, i think we need to decompose our problem. i see our aims
like this:
1. maintaining an updated registry
a) keep reference to components and regularly ping/update data
(wicket hub should be able to do this real soon)
b) automatically discover those components (a whole new story)
couldn't sleep tonight, so i did a bit of work on it...
http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata
just a quick first sketch. thoughts?
Jonathan Locke wrote:
i don't have time to develop the metadata standard, but i could make time
to review it.
coincidentally, i started working on that again and i was about to
contact you to suggest a draft.
my perspective are (for the moment) data that is to be mapped to
fields currently supported in wicket hub. i put it in a jar metadata
format.
Site-URL: (maps to website url)
License-Name: (maps to
using the maven deps is fine. the purpose i had in mind for the
requirements and libraries nodes was just to enable display of the
component's requirements on a page about the component... (whether it's
built with maven or not). but using the maven deps would be more detailed
and more
your plan makes sense to me. it seems like moving ahead with a wicket
component metadata standard would be a good thing to do in parallel though.
+1
the problem here though is that for things to work in parallel, well,
by definition, you need more than 1 person doing stuff :)
i guess the
i don't have time to develop the metadata standard, but i could make time to
review it. there are a few good things on that wiki page, but i'd say a bit
more thinking could be applied (anyone want to help francisco?) and then get
review from me and any other core devs who want to chime in. if
that's too bad. i was hoping nexus was a centralized index of all known
public repos.
your plan makes sense to me. it seems like moving ahead with a wicket
component metadata standard would be a good thing to do in parallel though.
jon
francisco treacy-2 wrote:
hi jon,
it would
hi jon,
it would be nice to enable other parties to build similar wicket
component searching technologies that are not linked to wicket hub
definitely
my simplistic understanding was that nexus could search for jars with
certain files in them.
not unless you extend it
it ought to be
i don't completely agree:
- to be searched by nexus, repo needs to be nexus-aware: i.e.
nexus-maven-repository-index.properties and
nexus-maven-repository-index.zip files need to be deployed to the
/.index folder at maven repository root.
we are mainly talking about wicketstuff projects
you're certainly free to go in whatever direction you want, but i still like
the idea of a fully decentralized model. there may someday be wicket
components
in central or elsewhere, even outside maven repos (downloadable via HTTP
like
matej's inmethod stuff was for a while)
i also think the
you're certainly free to go in whatever direction you want,
to be clear, i fully agree on the decentralized model for:
- people and the development of this app, and data contributed by
wicket users: this should be as democratic as possible
- artifacts / components:
there may someday be wicket
i think maven searching is an ideal way to publish and discover wicket
components at
present. i never meant to imply that that should be the only way to do this
or that the
idea of a wicket component jar should be tied to something like a repository
or a transport.
i also don't think it should
wasn't this someone martijn?
On Tue, Dec 16, 2008 at 8:55 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
For perusing the maven repository, one should contact the guys from
nexus. They have an api for reading/indexing the repository. Don't
crawl the repository-that will surely get you
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
you could search for artifacts with the appropriate metadata, or search
cool. this definitely looks like the right approach to me (assuming it
indexes most of the big repos)
jon
Rodolfo Hansen wrote:
Yes, you should use the nexus index for the repository
http://nexus.sonatype.org/
The indexer api is pretty straight forward:
btw, maybe this maven artifact searching thing should be integrated somehow
with an existing wicket search engine?
http://www.google.com/coop/cse?cx=00079654818618231%3Aenjwek-gxxg
is that possible with google custom searches alastair?
Jonathan Locke wrote:
cool. this definitely
here it is:
http://code.google.com/p/wickethub/ (source code for the
http://wickethub.org/ webapp)
a small piece of code (with not even unit tests so far) but hopefully
the way to start addressing our ideas:
http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
yeah, you really do need a maven expert's help i think. i was chatting with
someone about this and they said something to the effect of: oh, god no
don't crawl the maven repo. you'll get banned. so there's some more
official way of doing this apparently.
francisco treacy-2 wrote:
here it
hi nino,
have you seen jon's idea of automatic component , and/or wickethub.org
thread? discussion went around providing to wicket component
developers some sort of archetype that can help to 'standardize'/
'give more structure' - also useful to perhaps crawl those artifacts
(with metadata) and
Ahh, no did'nt follow the thing that far, will read up on it now..
I'll be looking forward to see some stuff in a couple of weeks :)
francisco treacy wrote:
hi nino,
have you seen jon's idea of automatic component , and/or wickethub.org
thread? discussion went around providing to wicket
20 matches
Mail list logo
