-----Original Message----- From: Tom Huybrechts [mailto:[EMAIL PROTECTED] Sent: 16 May 2007 22:57 To: Maven Users List Subject: Re: Eclipse RCP/PDE building and Maven
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. > > > 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. >From the point of view of repeatable builds, I want to build against a fixed and shared repository instead of any random Eclipse install. Based on the OSGi manifest, you can pick the right dependency in any Eclipse install, but these dependencies are typically very loose. Not like the Maven dependencies where all dependencies refer to a fixed artifacts. That said, this is a cool feature if you just need ease of use and quick configuration. You wouldn't even need to specify POM dependencies any more, just a link to an eclipse install where your dependencies should come from... Tom > > > 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. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
