On 5/14/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 5 May 07, at 6:28 PM 5 May 07, Carlos Sanchez wrote:
> I think we need an Eclipse section in the wiki and put all the
> pages under that
>
> Also another thing I wanted to do is cleanup the maven eclipse plugin,
> deprecate all OSGi stuff in favor of the Felix bundle plugin,
I don't know about that. We have two completely, and fully functional
options that have been in production for quite sometime while I doubt
there is much production use of the Felix plugin.
We have the code donated by PrincetonSoftech which is very well
documented in this article here:
http://www.eclipse.org/articles/article.php?file=Article-Eclipse-and-
Maven2/index.html
And the code for this project is here:
http://svn.codehaus.org/m2eclipse/maven-pst/
And we have Tom's work which is being used in a very large
organization and has been working well for quite some time:
http://svn.codehaus.org/m2eclipse/tycho/trunk/
The first solution is targeted at plugins, but the second is more
general with it's own lifecycle and set of plugins.
The felix bundle plugin is more complete, with more configuration
options that what we have at eclipse plugin.
> and
> improve the Eclipse plugins to Maven repository conversion, so we can
> run it as soon as a new version of eclipse goes out.
This is something I've discussed with Eugene, but what about treating
an Eclipse installation as another local repository. If you are
developing Eclipse plugins against a particular version of Eclipse
then you're going to have the installation present. This might make
it easier then trying to scrape out a local repository and convert it
which is what the two solutions do above. Not sure what other
solutions do but this seems less then optimal. Probably makes sense
to just use the Eclipse installation in its current form instead of
duplicating it.
Having them in the repo enables sharing them between the team, and I
can imagine that at some point we'll be able to build and test without
the installation but as jetty:run does with J2EE.
> One of the things
> to change is the use of artifactIds and groupIds, i think we should
> make the convention of using groupId.artifactId for all those
> deployments that use only a folder, like the eclipse plugins
> directory, WEB-INF/lib in a war,...
>
That seems fine at first blush but I would like to work completely
through the problem. I don't think having JARs named differently
based on where they are is such a great idea. Though I agree with the
new naming convention.
> other interesting thing i heard about was the possibility of using an
> extension in eclipse to access a maven repository as an update site.
>
That's cool, where was that? Jeff McAffer talked about a long time
ago just wondering if he went anywhere with that.
Target platform provisioning via file system
http://download.eclipse.org/eclipse/downloads/drops/S-3.3M4-200612141445/eclipse-news-M4.html
For what i see in the update site it adds all the contents of the repo
in the runtime. We'd need to point to a pom, get the dependencies and
add only those to the runtime I guess. I have some code already (the
wizard mostly), if somebody is interested on it, just waiting for a
place to put it in.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
