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 be tied to a specific repo of discovered meta
information like 
wicket hub. that creates a centralized architecture and as much as i like
the idea of wicket 
hub a lot, it would be nice to enable other parties to build similar wicket
component 
searching technologies that are not linked to wicket hub. for example,
someone could 
gather wicket components for an IDE plugin, to store in some other type of
repository 
than maven or to create an index for some future google search plugin.

my simplistic understanding was that nexus could search for jars with
certain files in them.
all we need from nexus is the ability to get a list of jar artifacts which
contain the file
"META-INF/wicket/components.xml" because all such files will be wicket
component jars
(subject to downloading and parsing, of course). if nexus can't do that, i
think that's
a flaw in nexus and it ought to be extended so that it can do that. it would
be worth
talking to them about our needs to see if they could help us. i think that a
nexus driven 
wicket component repository would be beneficial advertising for the nexus
project, and
it should not be too hard to achieve.

      jon


francisco treacy-2 wrote:
> 
>> 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
>> components in central or elsewhere, even outside maven repos
>> (downloadable via HTTP
>> like matej's inmethod stuff was for a while)
> 
> we should support any mavenized or non-mavenized artifacts, wherever
> those may live - you're right there (however i thought you said before
> you were interested at present only by components delivered by maven).
> 
>> parsing the metadata would be done after you download the artifact that
>> you
>> found.
> 
> okay, fair enough. i have some doubts though:
> 
> 1. in this scenario, downloading every artifact on earth just to open
> it and "see if there's some wicket info inside" is... impossible.
> 
> 2.
>> you just need to find the artifact with nexus.
> 
> in your original blog post you say "Basically, I'd like to see us
> crawl maven repos looking for JAR'ed Wicket components with a
> particular set of meta-data"
> i don't see how nexus can help there. let's put another example:
> 
> i create a mootools integration component, i mavenize it with package
> name "com.mymootools.wicket" and publish it in central repo.  how does
> nexus help in finding that, if it doesn't know anything about
> META-INF/*.xml?
> 
> ... *unless* you're planning people to "submit their jar urls to
> wickethub". that would be a whole other story. but then again, nexus
> would be useless as we will already have the urls to components (no
> need to crawl or search - only to download the jar, open it up and
> update metadata in wickethub)
> 
> for screenshots and the internal structure of the xml file, we shall
> see later, but i generally agree with you
> 
> francisco
> 
> 
>> parsing the metadata would be done after you download the artifact that
>> you
>> found.
>> at that point you can do anything with it, including extracting URLs or
>> even
>> embedded
>> images (might be a nice option for screenshots).
>>
>> putting jar metadata in META-INF is much more appropriate in my mind
>> because
>> it's
>> not maven-specific. the idea of a wicket component is not a maven-centric
>> idea and
>> a maven repository is just one way to publish a component. there are
>> certainly going
>> to be others.
>>
>> i do think that it might be a good idea to make the component metadata a
>> separate
>> xml file in a subfolder of META-INF instead of putting that info directly
>> in
>> the existing
>> jar properties file.  this is a lot more extensible and would allow
>> multiple
>> components
>> in a single jar and would also uniquely identify a wicket component and
>> be
>> quite
>> searchable with nexus by just looking for:
>>
>>    META-INF/wicket/components.xml               // define components in
>> this jar (relative reference to metadata files, in this case:
>>                                                                       //
>> component1/metadata.xml and component2/metadata.xml)
>>    META-INF/wicket/component1/metadata.xml          // define metadata
>> for
>> first component
>>    META-INF/wicket/component2/metadata.xml          // metadata for
>> second
>> component
>>    META-INF/wicket/component2/screenshots/1.jpg    // embedded
>> screenshots
>> for second component
>>    META-INF/wicket/component2/screenshots/2.jpg
>>
>> at least as i understand it... if not, maybe nexus needs to be
>> extended...
>>
>>
>> francisco treacy-2 wrote:
>>>
>>> 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 currently hosted in a
>>> non-indexed (nothing at
>>> http://wicketstuff.org/maven/repository/.index/) community-owned repo.
>>> as far as i know, there are no wicket components in maven central
>>> repo.
>>>  i insist, so long as wicketstuff is *our repo* we can do whatever we
>>> want with it. we can decide *not to ban* wickethub's crawler (our
>>> crawler). we still can use nexus though, but we're not forced to do so
>>>
>>> - moreover, no specific metadata indexed:
>>>
>>> "Nexus indexer component provides an API to index Maven repository,
>>> merge and download index updates. It also provides an API to search
>>> through registered indexes using various search criteria, including:
>>>
>>>     * Browse through repository indexes
>>>     * Search jars by artifactId and groupId
>>>     * Search jars by the packaging type (e.g. to find Maven plugins or
>>> Archetypes)
>>>     * Search jars by sha1 (e.g. to identify arbitrary jars with actual
>>> Maven artifacts)
>>>     * Search Maven artifacts/jar by class name (e.g. resolve classpath
>>> issues from build errors or class not found exceptions)"
>>>
>>> ...knowing that we need to index specific metadata
>>> (http://cwiki.apache.org/confluence/display/WICKET/Wicket+Component+JAR+Metadata).
>>> by the way, i wouldn't store metadata under META-INF inside the jar; i
>>> would rather include it in the pom file.
>>>
>>> let's put an example, let's say we need to display up-to-date url of
>>> screenshots (or examples or whatever)
>>>
>>> Screenshots=http://mycomponents.com/slider/screenshots/1.jpg,http://mycomponents.com/slider/screenshots/2.jpg,...
>>>
>>> wickethub will somehow need to know about those urls. how could it
>>> grab that out of nexus? i had a look at their lucene api and i'm not
>>> aware of the aforementioned scenario being possible.
>>>
>>> wickethub's crawler is a custom solution. it has to be smarter in that
>>> regard - to be able to keep synchronized custom data *we* (but not
>>> everybody) will be using in maven artifacts.
>>>
>>> francisco
>>>
>>>
>>>
>>> On Thu, Jan 15, 2009 at 5:37 PM, Jonathan Locke
>>> <jonathan.lo...@gmail.com> wrote:
>>>>
>>>>
>>>> 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:
>>>>> http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-NexusIndexerAPIExample
>>>>>
>>>>> you could search for artifacts with the appropriate metadata, or
>>>>> search
>>>>> inside the jars for some specific file / class (I think)
>>>>>
>>>>> On Thu, Jan 15, 2009 at 5:00 AM, francisco treacy <
>>>>> francisco.tre...@gmail.com> wrote:
>>>>>
>>>>>> 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 banned.
>>>>>>
>>>>>> i replied >
>>>>>>
>>>>>> martijn, banning policies are issued by repository owners. i don't
>>>>>> know which repo you're referring to as "the maven repository".
>>>>>> central? apache?
>>>>>>
>>>>>> i suggested setting up or reusing a repo that would be mainly for
>>>>>> wicket components, and owned by the project/ community. advantages:
>>>>>>
>>>>>>  - we simply don't ban wickethub's crawler
>>>>>>  - we provide guidelines for wicket developers to easily publish
>>>>>> their
>>>>>> artifacts (and possibly check if metadata is present, etc)
>>>>>>
>>>>>> as for the rest ('non-compliant'), that would be maintained manually
>>>>>> so no crawling involved.
>>>>>>
>>>>>> francisco
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 14, 2009 at 11:40 PM, Jonathan Locke
>>>>>> <jonathan.lo...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > 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 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
>>>>>> >>>>
>>>>>> >>>>
>>>>>> http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
>>>>>> >>>> http://www.nabble.com/wickethub.org-td20995774.html
>>>>>> >>
>>>>>> >> let me know if you're interested in contributing. i'd particularly
>>>>>> >> like to find a maven power-user(s) who'd like to help implementing
>>>>>> >> some of jon's "automatic component repo" thingy.
>>>>>> >> nino, what about the "archetypes for wicketstuff"?
>>>>>> >>
>>>>>> >> francisco
>>>>>> >>
>>>>>> >>
>>>>>> >> On Sat, Dec 20, 2008 at 9:00 PM, Nino Martinez
>>>>>> >> <nino.martinez.w...@gmail.com> wrote:
>>>>>> >>> 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 component
>>>>>> >>>> developers some sort of archetype that can help to
>>>>>> 'standardize'/
>>>>>> >>>> 'give more structure'  - also useful to perhaps crawl those
>>>>>> artifacts
>>>>>> >>>> (with metadata) and keep them up-to-date in a sort of registry.
>>>>>> it
>>>>>> >>>> would be good to join efforts.
>>>>>> >>>>
>>>>>> >>>>
>>>>>> http://www.nabble.com/idea:-automatic-component-repo-to17979177.html
>>>>>> >>>>
>>>>>> >>>>
>>>>>> http://web.mac.com/jonathan.locke/iWeb/JonathanLocke/Blog/ECA681FB-4B9C-4C27-9947-C9901F99E154.html
>>>>>> >>>> http://www.nabble.com/wickethub.org-td20995774.html
>>>>>> >>>>
>>>>>> >>>> i'd really like to really tackle this one, once i'm back from
>>>>>> holidays
>>>>>> >>>> in about 2 weeks. gonna tidy up a bit and open source that
>>>>>> wickethub
>>>>>> >>>> code.
>>>>>> >>>>
>>>>>> >>>> cheers,
>>>>>> >>>> francisco
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> On Sat, Dec 20, 2008 at 9:22 AM, Nino Martinez
>>>>>> >>>> <nino.martinez.w...@gmail.com> wrote:
>>>>>> >>>>
>>>>>> >>>>>
>>>>>> >>>>> Hi
>>>>>> >>>>>
>>>>>> >>>>> I were thinking that it would be nice to have archetypes for
>>>>>> single
>>>>>> >>>>> wicketstuff core project and one with a multi module (the stuff
>>>>>> project
>>>>>> >>>>> and
>>>>>> >>>>> a example one), I guess it would provide event more structure..
>>>>>> >>>>>
>>>>>> >>>>> WDYT?
>>>>>> >>>>>
>>>>>> >>>>> regards Nino
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> >>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> >>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> >>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > --
>>>>>> > View this message in context:
>>>>>> http://www.nabble.com/Wicket-stuff-core%2C-archetypes--tp21102842p21466906.html
>>>>>> > Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> > For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Wicket-stuff-core%2C-archetypes--tp21102842p21481411.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Wicket-stuff-core%2C-archetypes--tp21102842p21519208.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Wicket-stuff-core%2C-archetypes--tp21102842p21520646.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to