You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Carlos Sanchez <ca...@apache.org> on 2007/05/06 03:28:56 UTC
Re: Eclipse RCP/PDE building and Maven
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, and
improve the Eclipse plugins to Maven repository conversion, so we can
run it as soon as a new version of eclipse goes out. 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,...
other interesting thing i heard about was the possibility of using an
extension in eclipse to access a maven repository as an update site.
On 3/29/07, Barrie Treloar <ba...@gmail.com> wrote:
> On 3/30/07, Carlos Sanchez <ca...@apache.org> wrote:
> > yes, we have to organize this stuff better, probably gather a list of
> > interested people too.
>
> I'm all for pushing this further, but am more than willing to let
> someone else drive this.
>
> Suggestions on how to make this happen?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Eclipse RCP/PDE building and Maven
Posted by st...@belgacom.be.
-----Original Message-----
From: Tom Huybrechts [mailto:tom.huybrechts@gmail.com]
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 <ja...@maven.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Tom Huybrechts <to...@gmail.com>.
On 5/14/07, Jason van Zyl <ja...@maven.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Carlos Sanchez <ca...@apache.org>.
On 5/16/07, Jason van Zyl <ja...@maven.org> wrote:
>
> On 14 May 07, at 9:47 AM 14 May 07, Carlos Sanchez wrote:
>
> > On 5/14/07, Jason van Zyl <ja...@maven.org> wrote:
> >>
> >> 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.
> >
>
> In all honesty I very much doubt that. The tycho stuff has been in
> production for over a year and is being used now by three very large
> organizations with very rigid build certifications policies. The
> second two have only been using it for a couple months but the author
> has been using it in production for a year.
I'm talking about the maven-bundle-plugin vs the eclipse plugin
EclipseOSGiManifestWriter that generates a limited manifest and it's
not configurable as the bundle plugin is.
i see both eclipse and bundle plugin playing together for eclipse plugin builds
>
> Is the Felix plugin being used anywhere in production, and if so for
> how long?
>
> >>
> >> > 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.
>
> Who on the team is not going to have Eclipse installed? Even on a
> build server you would just install Eclipse. Not doing that means
> you're going to end up with a GB of duplication if you're using/
> testing with multiple versions of Eclipse.
>
> >
> >>
> >> > 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Graham Leggett <mi...@sharp.fm>.
On Wed, May 16, 2007 2:03 pm, Barrie Treloar wrote:
>> Who on the team is not going to have Eclipse installed? Even on a
>> build server you would just install Eclipse. Not doing that means
>> you're going to end up with a GB of duplication if you're using/
>> testing with multiple versions of Eclipse.
In our case, our build servers don't have Eclipse, because our build
servers are headless Unix boxes. :(
This doesn't mean our headless boxes can't have an eclipse installation
directory available to them though.
> At the moment I have used the maven-eclipse-plugin to duplicate the
> Eclipse installation into the repository. The benefit of this is the
> ability to create Eclipse Target Platforms using transitive
> dependencies.
If a plugin exists that is able to import an eclipse installation into a
maven repository just by providing the location of eclipse, it seems
logical that it should be possible to point at an eclipse installation as
a maven repository of type "eclipse", as opposed to type "legacy" or
"default".
The only problem would be that information normally extracted from a pom,
now has to be extracted from the plugin after the plugin has been
downloaded. I'm not sure how much of a problem this would be, I don't know
the internal workings of the dependency plugin that well.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Barrie Treloar <ba...@gmail.com>.
> > 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.
>
> Who on the team is not going to have Eclipse installed? Even on a
> build server you would just install Eclipse. Not doing that means
> you're going to end up with a GB of duplication if you're using/
> testing with multiple versions of Eclipse.
The Maven repository is in a known location for Maven.
However the Eclipse installation will require some non-pom
configuration details to be provided. (I agree that it is likely to be
installed on all machines)
It would also require verification that the installation specified is
the version required. (i.e. pom defines version 3.2.2 but local
installation is 3.1.0)
All of these issue can be resolved, it would be nice if it could be
done in a consistent way.
At the moment I have used the maven-eclipse-plugin to duplicate the
Eclipse installation into the repository. The benefit of this is the
ability to create Eclipse Target Platforms using transitive
dependencies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Jason van Zyl <ja...@maven.org>.
On 14 May 07, at 9:47 AM 14 May 07, Carlos Sanchez wrote:
> On 5/14/07, Jason van Zyl <ja...@maven.org> wrote:
>>
>> 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.
>
In all honesty I very much doubt that. The tycho stuff has been in
production for over a year and is being used now by three very large
organizations with very rigid build certifications policies. The
second two have only been using it for a couple months but the author
has been using it in production for a year.
Is the Felix plugin being used anywhere in production, and if so for
how long?
>>
>> > 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.
Who on the team is not going to have Eclipse installed? Even on a
build server you would just install Eclipse. Not doing that means
you're going to end up with a GB of duplication if you're using/
testing with multiple versions of Eclipse.
>
>>
>> > 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Damien Lecan <ml...@dlecan.com>.
2007/5/14, Carlos Sanchez <ca...@apache.org>:
> Target platform provisioning via file system
> 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.
That will be a very interesting piece of code.
Where will you put it in ?
Thanks
Damien Lecan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Carlos Sanchez <ca...@apache.org>.
On 5/14/07, Jason van Zyl <ja...@maven.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Jason van Zyl <ja...@maven.org>.
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.
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Eclipse RCP/PDE building and Maven
Posted by Barrie Treloar <ba...@gmail.com>.
On 5/6/07, Carlos Sanchez <ca...@apache.org> wrote:
> I think we need an Eclipse section in the wiki and put all the pages under that
Yes please.
I created http://docs.codehaus.org/display/MAVENUSER/Eclipse+Integration
to start hanging all this together.
> Also another thing I wanted to do is cleanup the maven eclipse plugin,
> deprecate all OSGi stuff in favor of the Felix bundle 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. 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,...
To you want to write this up on the wiki as a starting point for
organizing this work?
I'm keen to help out, but I doubt I have time to any lead stuff.
Of course I have the selfish desire to get something working for our
projects that need all this so I have a bit more time than normal.
> other interesting thing i heard about was the possibility of using an
> extension in eclipse to access a maven repository as an update site.
Neat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org