Vincent Massol wrote:
>
> After reading this very interesting thread on CJAN/JJAR, here follows my
> remarks / comments / ideas ...
>
> I should point out that I really everything that I have read so far. Very
> interesting !
>
> In no specific order ...
>
> 1) We need to communicate from the minimalist jar on the client side to the
> server side repository. More than that we need to call services : dependency
> list service, fetch service, news service, ... Why reinvent the wheel ?
> There is something already done for that, it is called Web Services ... We
> don't have to implement the full web service stack (XML, SOAP, WSDL, UDDI,
> ...). Just using XML and SOAP would be enough to start with.
My thinking here is two parts :
1) I have XML working (sort of) with a tiny XML parser - things look
good.
2) I don't think web services are the way, as the notion of repository
doesn't necessarily mean 'central'. You can have a repository on your
own machine, that your projects and apps use. You can then just
synchronize once in a while if you care. For example, 'released apps'
that use it may want to target specific versions, like Velocity 1.0.1 or
Ant 1.3. But for development, you might want to always going against
latest version, or default version (they are two differnet things). So
specifying "*" for version in the API calls could mean latest, and "-"
mean default [or similar...].
> a) I can already see Geir's comment on that : the client side jar will be
> too big ! First I'm sure that we can fit it all in less than 300 kbytes
> which seem reasonable to me. Downloading 17kbytes or 300kbytes is the same
> even on a slow modem ... Second, as Peter pointed out, this is a bootstrap
> mechanism, which mean you only need to download it once so it is not *that*
> important. I understand Geir's point about embedded devices but I don't
> think this is what we are focusing on right now, is it ? (Eventually when
> SOAP/XML parser will be integrated in the JVM, the size will drop to a few
> Kbs ... :) ).
The XML turns out to not be a worry right now, and how long will it be
before you can count on targetting the 1.X JVM that has SOAP built in?
:)
>
> b) Not everyone has a SOAP client on it's computer yet so I would say that
> we also have to offer a simple XML interface at first. Like
> http://jakarta.apache.org/repository/fetch?file=log4j&version=...... But I
> would definitely not like to restrict to only this type of semantic and use
> SOAP/ XP (when ready) instead. We can even use Apache SOAP framework ... :)
>
> 2) The real goal that I'd like to see for such a project is to replace
> Jakarta's way of publishing new releases/ accessing release. I'd like to
> view this project as a set of Repository Services and have 2 sets of APIs :
> - one for publishing new libraries into the Repository. This could be used
> by any individual/group like JUnit, JDOM. It could also be used by GUMP
> itself to publish nightly builds and it should be used by Jakarta projects
> to release their files.
Yep - I was already starting to add that stuff, but figured it could
come later...
> - one for querying the repository. This would be used by end user using
> either Ant or Geir's command line tool. It could also be used by a specific
> classloader. It would also be used by the Jakarta web site download pages.
>
> The real challenge is to have a unified way of releasing
> libraries/applications for Jakarta (we can broaden the scope later if need
> be so that it reaches the size of a CPAN).
>
> 3) A nice service that I'd like to see in the set of services is a news
> service to which we could ask question like : Give me the list of new
> releases for the past 15 days. We can even set up a web page so that user
> make their queries online. Then it would be very easy for external news
> portal site to gather the list of new releases from Jakarta and aggegate
> this information with information from other sites.
>
> A very interesting project in my opinion in which I would be interested to
> participate .... :)
> Thanks.
>
> Vincent.
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
