You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Graham Leggett <mi...@sharp.fm> on 2006/12/11 16:28:23 UTC
maven2 repository of eclipse jars
Hi all,
I have seen some effort scattered here and there for providing maven2
repositories containing the jars that make up the eclipse platform. It
would be great if an automated repository could be created that would keep
eclipse jars accessible to maven.
The eclipse:make-artifacts goal in the maven-eclipse-plugin is capable of
scanning an eclipse installation, and importing all the jars in that
installation into a maven2 repository.
Eclipse itself is capable of auto-updating itself from the command line,
without human or GUI intervention:
http://publib.boulder.ibm.com/infocenter/imshelp1/v3r0/index.jsp?topic=/com.ibm.cia.infocenter.doc/references/rupdatecommand.html
These two features together, with some scripting and a place to host the
repository, is in theory all that would be needed to make eclipse jars
automatically available to maven users.
Thoughts?
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Carlos Sanchez <ca...@apache.org>.
the idea is to setup a repository with eclipse artifacts generated
from install-files and sync org.eclipse.* from there to the central
maven repo, not to create new things in ibiblio
On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
> Carlos Sanchez wrote:
>
> > that sounds good and can be setup as if it were another mirror, the
> > important questions
> > who will volunteer to do it?
> > is enough people asking for them that it makes sense?
>
> In theory, keeping such a repository up to date could be done from a
> zone, and it's not a problem for me to set up (having already figured
> out the details), but the repository itself contains Eclipse code -
> would ibiblio host a mirror of such a thing?
>
> Regards,
> Graham
> --
>
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Carlos Sanchez <ca...@apache.org>.
Scott Lewis is already helping with eclipse-maven relationship
This is a proposal for a new project at Eclipse foundation that will
increase this collaboration http://www.eclipse.org/proposals/kepler/
On 12/11/06, Tom Huybrechts <to...@gmail.com> wrote:
> Please consider http://jira.codehaus.org/browse/MECLIPSE-201 if you
> want to deploy these artifacts to central. Once the POMs are out
> released, they can't be changed untill there is a new release.
>
> Would'nt it be a good idea to try to involve people from Eclipse in this ?
>
> Tom
>
> On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
> > Carlos Sanchez wrote:
> >
> > > that sounds good and can be setup as if it were another mirror, the
> > > important questions
> > > who will volunteer to do it?
> > > is enough people asking for them that it makes sense?
> >
> > In theory, keeping such a repository up to date could be done from a
> > zone, and it's not a problem for me to set up (having already figured
> > out the details), but the repository itself contains Eclipse code -
> > would ibiblio host a mirror of such a thing?
> >
> > Regards,
> > Graham
> > --
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Tom Huybrechts <to...@gmail.com>.
Please consider http://jira.codehaus.org/browse/MECLIPSE-201 if you
want to deploy these artifacts to central. Once the POMs are out
released, they can't be changed untill there is a new release.
Would'nt it be a good idea to try to involve people from Eclipse in this ?
Tom
On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
> Carlos Sanchez wrote:
>
> > that sounds good and can be setup as if it were another mirror, the
> > important questions
> > who will volunteer to do it?
> > is enough people asking for them that it makes sense?
>
> In theory, keeping such a repository up to date could be done from a
> zone, and it's not a problem for me to set up (having already figured
> out the details), but the repository itself contains Eclipse code -
> would ibiblio host a mirror of such a thing?
>
> Regards,
> Graham
> --
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Graham Leggett <mi...@sharp.fm>.
Carlos Sanchez wrote:
> that sounds good and can be setup as if it were another mirror, the
> important questions
> who will volunteer to do it?
> is enough people asking for them that it makes sense?
In theory, keeping such a repository up to date could be done from a
zone, and it's not a problem for me to set up (having already figured
out the details), but the repository itself contains Eclipse code -
would ibiblio host a mirror of such a thing?
Regards,
Graham
--
Re: maven2 repository of eclipse jars
Posted by Carlos Sanchez <ca...@apache.org>.
that sounds good and can be setup as if it were another mirror, the
important questions
who will volunteer to do it?
is enough people asking for them that it makes sense?
On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
> Hi all,
>
> I have seen some effort scattered here and there for providing maven2
> repositories containing the jars that make up the eclipse platform. It
> would be great if an automated repository could be created that would keep
> eclipse jars accessible to maven.
>
> The eclipse:make-artifacts goal in the maven-eclipse-plugin is capable of
> scanning an eclipse installation, and importing all the jars in that
> installation into a maven2 repository.
>
> Eclipse itself is capable of auto-updating itself from the command line,
> without human or GUI intervention:
> http://publib.boulder.ibm.com/infocenter/imshelp1/v3r0/index.jsp?topic=/com.ibm.cia.infocenter.doc/references/rupdatecommand.html
>
> These two features together, with some scripting and a place to host the
> repository, is in theory all that would be needed to make eclipse jars
> automatically available to maven users.
>
> Thoughts?
>
> Regards,
> Graham
> --
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Carlos Sanchez <ca...@apache.org>.
On 12/11/06, Fabrizio Giustina <fg...@apache.org> wrote:
> - the 4th token MUST be separated with "-" in maven, while in osgi
> MUST be "." (this is handled by the make-artifacts goal actually). A
> version like 1.2.3-4 in maven is parsed as [major 1, minor 2, patch 3,
> build 4], a version like 1.2.3.4 is parsed as [major 0, minor 0, patch
> 0, build 0, qualifier "1.2.3.4"] (funny, I discovered this only
> recently by looking at DefaultVersion unit tests... I can't say I like
> it but that's how maven works and it's expected to work, you will
> never notice it till you will experiment 4 digits version numbers, and
> osgi bundles HAVE 4 digits version numbers).
i'd say that's a bug more than a "feature", I given the increasing
importance OSGi is getting we should probably accommodate it.
For what you say we need the build number as part of the version in
eclipse stuff. There's no such thing as 3.2.0, it'll be always 3.2.0.x
and that should be the Maven version
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Jason van Zyl <ja...@maven.org>.
On 12 Dec 06, at 4:18 AM 12 Dec 06, Tom Huybrechts wrote:
> On 12/12/06, Jason van Zyl <ja...@maven.org> wrote:
>
> This message (1) on pde-build-dev contains the state resolver as an
> attachment. I used this to calculate access rules for the JDT
> compiler, and to generate POMs for bundles.
>
> http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00262.html
I'll take a look. Not sure how that relates to the effort Jeff was
talking about as he said many copies were in use but that looks good.
I'll point Eugene at that as well.
Jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Tom Huybrechts <to...@gmail.com>.
On 12/12/06, Jason van Zyl <ja...@maven.org> wrote:
>
> On 11 Dec 06, at 10:25 PM 11 Dec 06, Scott Lewis wrote:
>
> > Hi Jason,
> >
> >
> > What is the State resolver?
>
> Dependency resolver. Basically a state machine that consumes OSGi
> dependency information, determines what's missing and asks for more.
> How the conditions are satisfied is up to the implementation and I
> believe this is what varies across usage. This is what I was going to
> try and plug into Maven to make it understand OSGi dependencies.
>
> > Is this a name for the PDE code that manages the meta info for a
> > plugin/feature (e.g. manifest.mf, plugin.xml, etc)? To your
> > knowledge is there a PDE and/or platform bug against this
> > particular need/use case? If so, what is it? I did a quick search
> > for 'state resolver' in Eclipse classification, but nothing that
> > sounded like what you are describing came up.
> >
>
> I have no idea what's in there. I've always just chatted with Jeff
> about it.
>
> >>
> >>> The PDE currently does all this and the Jeff is the lead for the
> >>> Equinox team (which also includes Pascal Rapicault, one of the
> >>> PDE developers along with others connected with the Equinox
> >>> team). As far as I know doesn't have any outstanding work items
> >>> to do anything specific to unifying things for Maven.
> >>
> >> It's not for Maven, it's something that would benefit Eclipse and
> >> Maven would be a by product beneficiary. I asked "where's the
> >> code", to which he replied "well, in several places". So in order
> >> for us to consume it there would have to be something concrete we
> >> could use. What Eugene has now is workable for non-OSGi developers
> >> but won't cut it otherwise.
> >>
> >>> I'm meeting/seeing Jeff on Wednesday am at foundation BOD
> >>> meeting, so if there is some required change to the PDE or
> >>> Equinox then I would be happy to speak with him about it
> >>> directly. But I would need to understand what exactly was
> >>> required of them and why, as I have spoken with Jeff about Maven
> >>> integration before.
> >>
> >> Unify your State resolver code so we can use it. That's it really.
> >
> > I'm just trying to understand this...what would it mean in
> > refactoring/code restructuring terms to 'unify the state resolver
> > code'? I believe that the code that parses the plugin and feature
> > models (i.e. the inter-bundle and inter-feature dependency
> > information in manifest.mf, plugin.xml, feature.xml, etc) is likely
> > spread across multiple bundles/plugins, but I believe the
> > buckminster folks are using these APIs successfully...
>
> Information from a manifest or a plugin.xml can be sources for the
> state resolver from what Jeff has explained to me. The State resolver
> is something is tuned into OSGi dependency conventions. The version
> Jeff tried to put together for me came out of Equinox. Where all the
> variants live I don't know. I'll go to Ottawa one of these days and
> just find out! :-)
>
> > and of course the PDE is doing so...so I don't think it's
> > 'internal' API (although it could be). Would unification in
> > practice mean putting this code in a single API/package/bundle? Or
> > is there something else about this that I'm missing?
>
> I think that's what Jeff is talking about.
>
> >
> > One point though...since Equinox is an implementation of OSGi, and
> > Eclipse plugins and features have meta-information *beyond* what
> > OSGi defines by spec, I imagine that there has to be at least a
> > bundle-level separation between (e.g.) bundle dependency info in
> > manifest.mf...which is read/used by the Equinox platform, and
> > feature-level dependency info (in feature.xml) that is read/used by
> > the PDE.
>
> I would imagine this is accounted for because the code I saw came
> from Equinox. Not sure if there is any distinction between OSGi-ness
> and Eclipse-ness in there. But it would be useful as I would like to
> account for straight-up OSGi development that is not Eclipse related.
> People using IDEA or Netbeans might be doing OSGi work.
>
> >
> > If there is a description of what you mean by 'unify state resolver
> > code' then please let me know where it is and I'll examine.
>
> If you're going to talk to Jeff I'm sure he can explain where all
> this stuff lives in Eclipse-land how best it would tied together for
> external use for something like Maven. I just know what it's supposed
> to do, not the mechanics of how folks in Eclipse-land would all use
> the same code in addition to giving clients a single package to use.
>
> Jason.
>
This message (1) on pde-build-dev contains the state resolver as an
attachment. I used this to calculate access rules for the JDT
compiler, and to generate POMs for bundles.
http://dev.eclipse.org/mhonarc/lists/pde-build-dev/msg00262.html
> >
> > Thanksinadvance,
> >
> > Scott
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Jason van Zyl <ja...@maven.org>.
On 11 Dec 06, at 10:25 PM 11 Dec 06, Scott Lewis wrote:
> Hi Jason,
>
>
> What is the State resolver?
Dependency resolver. Basically a state machine that consumes OSGi
dependency information, determines what's missing and asks for more.
How the conditions are satisfied is up to the implementation and I
believe this is what varies across usage. This is what I was going to
try and plug into Maven to make it understand OSGi dependencies.
> Is this a name for the PDE code that manages the meta info for a
> plugin/feature (e.g. manifest.mf, plugin.xml, etc)? To your
> knowledge is there a PDE and/or platform bug against this
> particular need/use case? If so, what is it? I did a quick search
> for 'state resolver' in Eclipse classification, but nothing that
> sounded like what you are describing came up.
>
I have no idea what's in there. I've always just chatted with Jeff
about it.
>>
>>> The PDE currently does all this and the Jeff is the lead for the
>>> Equinox team (which also includes Pascal Rapicault, one of the
>>> PDE developers along with others connected with the Equinox
>>> team). As far as I know doesn't have any outstanding work items
>>> to do anything specific to unifying things for Maven.
>>
>> It's not for Maven, it's something that would benefit Eclipse and
>> Maven would be a by product beneficiary. I asked "where's the
>> code", to which he replied "well, in several places". So in order
>> for us to consume it there would have to be something concrete we
>> could use. What Eugene has now is workable for non-OSGi developers
>> but won't cut it otherwise.
>>
>>> I'm meeting/seeing Jeff on Wednesday am at foundation BOD
>>> meeting, so if there is some required change to the PDE or
>>> Equinox then I would be happy to speak with him about it
>>> directly. But I would need to understand what exactly was
>>> required of them and why, as I have spoken with Jeff about Maven
>>> integration before.
>>
>> Unify your State resolver code so we can use it. That's it really.
>
> I'm just trying to understand this...what would it mean in
> refactoring/code restructuring terms to 'unify the state resolver
> code'? I believe that the code that parses the plugin and feature
> models (i.e. the inter-bundle and inter-feature dependency
> information in manifest.mf, plugin.xml, feature.xml, etc) is likely
> spread across multiple bundles/plugins, but I believe the
> buckminster folks are using these APIs successfully...
Information from a manifest or a plugin.xml can be sources for the
state resolver from what Jeff has explained to me. The State resolver
is something is tuned into OSGi dependency conventions. The version
Jeff tried to put together for me came out of Equinox. Where all the
variants live I don't know. I'll go to Ottawa one of these days and
just find out! :-)
> and of course the PDE is doing so...so I don't think it's
> 'internal' API (although it could be). Would unification in
> practice mean putting this code in a single API/package/bundle? Or
> is there something else about this that I'm missing?
I think that's what Jeff is talking about.
>
> One point though...since Equinox is an implementation of OSGi, and
> Eclipse plugins and features have meta-information *beyond* what
> OSGi defines by spec, I imagine that there has to be at least a
> bundle-level separation between (e.g.) bundle dependency info in
> manifest.mf...which is read/used by the Equinox platform, and
> feature-level dependency info (in feature.xml) that is read/used by
> the PDE.
I would imagine this is accounted for because the code I saw came
from Equinox. Not sure if there is any distinction between OSGi-ness
and Eclipse-ness in there. But it would be useful as I would like to
account for straight-up OSGi development that is not Eclipse related.
People using IDEA or Netbeans might be doing OSGi work.
>
> If there is a description of what you mean by 'unify state resolver
> code' then please let me know where it is and I'll examine.
If you're going to talk to Jeff I'm sure he can explain where all
this stuff lives in Eclipse-land how best it would tied together for
external use for something like Maven. I just know what it's supposed
to do, not the mechanics of how folks in Eclipse-land would all use
the same code in addition to giving clients a single package to use.
Jason.
>
> Thanksinadvance,
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Jason,
Jason van Zyl wrote:
> On 11 Dec 06, at 9:10 PM 11 Dec 06, Scott Lewis wrote:
>
>> Hi Jason,
>>
>> Jason van Zyl wrote:
>>
>> So m2eclipse *does* depend upon the Maven embedder currently...and at
>> the moment there is no way to use the meta info in manifest.mf,
>> plugin.xml, (and read/changed in memory in the PDE) to 'build' a pom
>> representationand have the Maven embedder operate on it/with it.
>>
>
> No, waiting for the state resolver to drop out and then I can make a
> project builder that attempts to make use of it for doing OSGi/Eclipse
> Plugin work. So when that happens we can give that side of it a whirl.
> There's all sorts of other interesting things to worry about in the
> meantime like integrating Archetypes (basically taking the work Milos
> has done for Netbeans), Maven SCM, project bootstrapping (or workspace
> materialization I think Buckminster calls it) all of which will be of
> interest to Maven users. Eugene is not happy with the extension in its
> current state but when he is I would like to bring it here along with
> the IDEA integration, and I'm working with Milos/Netbeans to bring the
> Netbeans integration here as well.
Very good.
>
>>>
>>>> I think it's a terrific/necessary idea to reuse the classpath (and
>>>> other meta info/dependency info) within Eclipse itself, as trying
>>>> to/rewriting/keeping in synch all of that code (to parse
>>>> manifest.mf, .classpath, .project, plugin.xml, feature.xml,
>>>> site.xml) would really be a waste since Equinox and PDE does this
>>>> already (as it obviously has to).
>>>>
>>>
>>> It would be nice unfortunately stuff needs to be unified on the
>>> Eclipse side first so Jeff said he would help facilitate that with
>>> Tom on the resolver side and Wassim(sp?) on the container side.
>>
>> What needs to be unified on the Eclipse side first?
>
> Jeff said that versions of the State resolver are used in various
> incarnations in several places and the within Eclipse land he would
> like to unify this
What is the State resolver? Is this a name for the PDE code that
manages the meta info for a plugin/feature (e.g. manifest.mf,
plugin.xml, etc)? To your knowledge is there a PDE and/or platform bug
against this particular need/use case? If so, what is it? I did a
quick search for 'state resolver' in Eclipse classification, but nothing
that sounded like what you are describing came up.
>
>> The PDE currently does all this and the Jeff is the lead for the
>> Equinox team (which also includes Pascal Rapicault, one of the PDE
>> developers along with others connected with the Equinox team). As
>> far as I know doesn't have any outstanding work items to do anything
>> specific to unifying things for Maven.
>
> It's not for Maven, it's something that would benefit Eclipse and
> Maven would be a by product beneficiary. I asked "where's the code",
> to which he replied "well, in several places". So in order for us to
> consume it there would have to be something concrete we could use.
> What Eugene has now is workable for non-OSGi developers but won't cut
> it otherwise.
>
>> I'm meeting/seeing Jeff on Wednesday am at foundation BOD meeting, so
>> if there is some required change to the PDE or Equinox then I would
>> be happy to speak with him about it directly. But I would need to
>> understand what exactly was required of them and why, as I have
>> spoken with Jeff about Maven integration before.
>
> Unify your State resolver code so we can use it. That's it really.
I'm just trying to understand this...what would it mean in
refactoring/code restructuring terms to 'unify the state resolver
code'? I believe that the code that parses the plugin and feature
models (i.e. the inter-bundle and inter-feature dependency information
in manifest.mf, plugin.xml, feature.xml, etc) is likely spread across
multiple bundles/plugins, but I believe the buckminster folks are using
these APIs successfully...and of course the PDE is doing so...so I don't
think it's 'internal' API (although it could be). Would unification in
practice mean putting this code in a single API/package/bundle? Or is
there something else about this that I'm missing?
One point though...since Equinox is an implementation of OSGi, and
Eclipse plugins and features have meta-information *beyond* what OSGi
defines by spec, I imagine that there has to be at least a bundle-level
separation between (e.g.) bundle dependency info in manifest.mf...which
is read/used by the Equinox platform, and feature-level dependency info
(in feature.xml) that is read/used by the PDE.
If there is a description of what you mean by 'unify state resolver
code' then please let me know where it is and I'll examine.
Thanksinadvance,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Jason van Zyl <ja...@maven.org>.
On 11 Dec 06, at 9:10 PM 11 Dec 06, Scott Lewis wrote:
> Hi Jason,
>
> Jason van Zyl wrote:
>
> So m2eclipse *does* depend upon the Maven embedder currently...and
> at the moment there is no way to use the meta info in manifest.mf,
> plugin.xml, (and read/changed in memory in the PDE) to 'build' a
> pom representationand have the Maven embedder operate on it/with it.
>
No, waiting for the state resolver to drop out and then I can make a
project builder that attempts to make use of it for doing OSGi/
Eclipse Plugin work. So when that happens we can give that side of it
a whirl. There's all sorts of other interesting things to worry about
in the meantime like integrating Archetypes (basically taking the
work Milos has done for Netbeans), Maven SCM, project bootstrapping
(or workspace materialization I think Buckminster calls it) all of
which will be of interest to Maven users. Eugene is not happy with
the extension in its current state but when he is I would like to
bring it here along with the IDEA integration, and I'm working with
Milos/Netbeans to bring the Netbeans integration here as well.
>>
>>> I think it's a terrific/necessary idea to reuse the classpath
>>> (and other meta info/dependency info) within Eclipse itself, as
>>> trying to/rewriting/keeping in synch all of that code (to parse
>>> manifest.mf, .classpath, .project, plugin.xml, feature.xml,
>>> site.xml) would really be a waste since Equinox and PDE does this
>>> already (as it obviously has to).
>>>
>>
>> It would be nice unfortunately stuff needs to be unified on the
>> Eclipse side first so Jeff said he would help facilitate that with
>> Tom on the resolver side and Wassim(sp?) on the container side.
>
> What needs to be unified on the Eclipse side first?
Jeff said that versions of the State resolver are used in various
incarnations in several places and the within Eclipse land he would
like to unify this
> The PDE currently does all this and the Jeff is the lead for the
> Equinox team (which also includes Pascal Rapicault, one of the PDE
> developers along with others connected with the Equinox team). As
> far as I know doesn't have any outstanding work items to do
> anything specific to unifying things for Maven.
It's not for Maven, it's something that would benefit Eclipse and
Maven would be a by product beneficiary. I asked "where's the code",
to which he replied "well, in several places". So in order for us to
consume it there would have to be something concrete we could use.
What Eugene has now is workable for non-OSGi developers but won't cut
it otherwise.
> I'm meeting/seeing Jeff on Wednesday am at foundation BOD meeting,
> so if there is some required change to the PDE or Equinox then I
> would be happy to speak with him about it directly. But I would
> need to understand what exactly was required of them and why, as I
> have spoken with Jeff about Maven integration before.
Unify your State resolver code so we can use it. That's it really.
Jason.
>
> Thanks,
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Jason,
Jason van Zyl wrote:
> On 11 Dec 06, at 8:22 PM 11 Dec 06, Scott Lewis wrote:
>
>> Hi Jason,
>>
>> Jason van Zyl wrote:
>>> On 11 Dec 06, at 7:13 PM 11 Dec 06, Scott Lewis wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> A quick comment: with Eclipse, version dependency requirements can
>>>> be specified at the level of individual bundles/plugins and at the
>>>> level of features (sets of plugins).
>>>>
>>>> This is described in that document under these subsections
>>>>
>>>> How to specify plug-in requirements:
>>>> http://wiki.eclipse.org/index.php/Version_Numbering#How_to_specify_plug-in_requirements
>>>>
>>>>
>>>> Versioning features:
>>>> http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_features
>>>>
>>>>
>>>> I'm sure this conclusion is obvious to all, but for Maven to 'know'
>>>> about and resolve these inter-plugin and inter-feature version
>>>> dependencies, it's got to understand the version requirements info
>>>> located in manifest.mf (at plugin level) and feature.xml (at
>>>> feature level).
>>>>
>>>
>>> We would purely delegate to the State resolver in Equinox. I have
>>> talked with Jeff McAffer about trying to get this resolver cleaned
>>> up and packaged up separately. It's used by in various bastardized
>>> versions in a few places and I talked to Tom Watts briefly at
>>> ApacheCon. Once this is done we could reuse it. Jeff took a first
>>> stab at decoupling quite some time ago. We are attempting to use
>>> this so we can completely reuse the classpath container code in
>>> Eclipse itself inside the Maven Eclipse Extension (which should
>>> hopefully be landing here at some point in the near future).
>>
>> So I guess I now need to ask: what is the Maven Eclipse Extension?
>
> Boy, you have a short memory :-)
I suppose I do. :). But in my own defense: !"Maven Eclipse
Extension".equals("m2eclipse").
>
> http://archive.m2eclipse.codehaus.org/dev/454134FB.4080208%40composent.com
>
>
> Unless you're a different Scott Lewis.
No, that's me.
>
>> Didn't find via google search. Does it use/depend upon the Maven 2
>> embedder or does is use some other part of Maven? And is there a
>> development/release plan associated with the Maven Eclipse Extension?
>>
>
> Whole bunch of hits there but the important ones are:
>
> http://jira.codehaus.org/browse/MNGECLIPSE
>
> and the archives for anyone not familiar with the project:
>
> http://archive.m2eclipse.codehaus.org/
So m2eclipse *does* depend upon the Maven embedder currently...and at
the moment there is no way to use the meta info in manifest.mf,
plugin.xml, (and read/changed in memory in the PDE) to 'build' a pom
representationand have the Maven embedder operate on it/with it.
>
>> I think it's a terrific/necessary idea to reuse the classpath (and
>> other meta info/dependency info) within Eclipse itself, as trying
>> to/rewriting/keeping in synch all of that code (to parse manifest.mf,
>> .classpath, .project, plugin.xml, feature.xml, site.xml) would really
>> be a waste since Equinox and PDE does this already (as it obviously
>> has to).
>>
>
> It would be nice unfortunately stuff needs to be unified on the
> Eclipse side first so Jeff said he would help facilitate that with Tom
> on the resolver side and Wassim(sp?) on the container side.
What needs to be unified on the Eclipse side first? The PDE currently
does all this and the Jeff is the lead for the Equinox team (which also
includes Pascal Rapicault, one of the PDE developers along with others
connected with the Equinox team). As far as I know doesn't have any
outstanding work items to do anything specific to unifying things for
Maven.
I'm meeting/seeing Jeff on Wednesday am at foundation BOD meeting, so if
there is some required change to the PDE or Equinox then I would be
happy to speak with him about it directly. But I would need to
understand what exactly was required of them and why, as I have spoken
with Jeff about Maven integration before.
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Jason van Zyl <ja...@maven.org>.
On 11 Dec 06, at 8:22 PM 11 Dec 06, Scott Lewis wrote:
> Hi Jason,
>
> Jason van Zyl wrote:
>> On 11 Dec 06, at 7:13 PM 11 Dec 06, Scott Lewis wrote:
>>
>>> Hi Tom,
>>>
>>> A quick comment: with Eclipse, version dependency requirements
>>> can be specified at the level of individual bundles/plugins and
>>> at the level of features (sets of plugins).
>>>
>>> This is described in that document under these subsections
>>>
>>> How to specify plug-in requirements: http://wiki.eclipse.org/
>>> index.php/Version_Numbering#How_to_specify_plug-in_requirements
>>>
>>> Versioning features: http://wiki.eclipse.org/index.php/
>>> Version_Numbering#Versioning_features
>>>
>>> I'm sure this conclusion is obvious to all, but for Maven to
>>> 'know' about and resolve these inter-plugin and inter-feature
>>> version dependencies, it's got to understand the version
>>> requirements info located in manifest.mf (at plugin level) and
>>> feature.xml (at feature level).
>>>
>>
>> We would purely delegate to the State resolver in Equinox. I have
>> talked with Jeff McAffer about trying to get this resolver cleaned
>> up and packaged up separately. It's used by in various bastardized
>> versions in a few places and I talked to Tom Watts briefly at
>> ApacheCon. Once this is done we could reuse it. Jeff took a first
>> stab at decoupling quite some time ago. We are attempting to use
>> this so we can completely reuse the classpath container code in
>> Eclipse itself inside the Maven Eclipse Extension (which should
>> hopefully be landing here at some point in the near future).
>
> So I guess I now need to ask: what is the Maven Eclipse Extension?
Boy, you have a short memory :-)
http://archive.m2eclipse.codehaus.org/dev/454134FB.4080208%
40composent.com
Unless you're a different Scott Lewis.
> Didn't find via google search. Does it use/depend upon the Maven 2
> embedder or does is use some other part of Maven? And is there a
> development/release plan associated with the Maven Eclipse Extension?
>
Whole bunch of hits there but the important ones are:
http://jira.codehaus.org/browse/MNGECLIPSE
and the archives for anyone not familiar with the project:
http://archive.m2eclipse.codehaus.org/
> I think it's a terrific/necessary idea to reuse the classpath (and
> other meta info/dependency info) within Eclipse itself, as trying
> to/rewriting/keeping in synch all of that code (to parse
> manifest.mf, .classpath, .project, plugin.xml, feature.xml,
> site.xml) would really be a waste since Equinox and PDE does this
> already (as it obviously has to).
>
It would be nice unfortunately stuff needs to be unified on the
Eclipse side first so Jeff said he would help facilitate that with
Tom on the resolver side and Wassim(sp?) on the container side.
jason.
> Thanksinadvance,
>
> Scott
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Jason,
Jason van Zyl wrote:
> On 11 Dec 06, at 7:13 PM 11 Dec 06, Scott Lewis wrote:
>
>> Hi Tom,
>>
>> A quick comment: with Eclipse, version dependency requirements can
>> be specified at the level of individual bundles/plugins and at the
>> level of features (sets of plugins).
>>
>> This is described in that document under these subsections
>>
>> How to specify plug-in requirements:
>> http://wiki.eclipse.org/index.php/Version_Numbering#How_to_specify_plug-in_requirements
>>
>>
>> Versioning features:
>> http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_features
>>
>> I'm sure this conclusion is obvious to all, but for Maven to 'know'
>> about and resolve these inter-plugin and inter-feature version
>> dependencies, it's got to understand the version requirements info
>> located in manifest.mf (at plugin level) and feature.xml (at feature
>> level).
>>
>
> We would purely delegate to the State resolver in Equinox. I have
> talked with Jeff McAffer about trying to get this resolver cleaned up
> and packaged up separately. It's used by in various bastardized
> versions in a few places and I talked to Tom Watts briefly at
> ApacheCon. Once this is done we could reuse it. Jeff took a first stab
> at decoupling quite some time ago. We are attempting to use this so we
> can completely reuse the classpath container code in Eclipse itself
> inside the Maven Eclipse Extension (which should hopefully be landing
> here at some point in the near future).
So I guess I now need to ask: what is the Maven Eclipse Extension?
Didn't find via google search. Does it use/depend upon the Maven 2
embedder or does is use some other part of Maven? And is there a
development/release plan associated with the Maven Eclipse Extension?
I think it's a terrific/necessary idea to reuse the classpath (and other
meta info/dependency info) within Eclipse itself, as trying
to/rewriting/keeping in synch all of that code (to parse manifest.mf,
.classpath, .project, plugin.xml, feature.xml, site.xml) would really be
a waste since Equinox and PDE does this already (as it obviously has to).
Thanksinadvance,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Jason van Zyl <ja...@maven.org>.
On 11 Dec 06, at 7:13 PM 11 Dec 06, Scott Lewis wrote:
> Hi Tom,
>
> A quick comment: with Eclipse, version dependency requirements can
> be specified at the level of individual bundles/plugins and at the
> level of features (sets of plugins).
>
> This is described in that document under these subsections
>
> How to specify plug-in requirements: http://wiki.eclipse.org/
> index.php/Version_Numbering#How_to_specify_plug-in_requirements
>
> Versioning features: http://wiki.eclipse.org/index.php/
> Version_Numbering#Versioning_features
>
> I'm sure this conclusion is obvious to all, but for Maven to 'know'
> about and resolve these inter-plugin and inter-feature version
> dependencies, it's got to understand the version requirements info
> located in manifest.mf (at plugin level) and feature.xml (at
> feature level).
>
We would purely delegate to the State resolver in Equinox. I have
talked with Jeff McAffer about trying to get this resolver cleaned up
and packaged up separately. It's used by in various bastardized
versions in a few places and I talked to Tom Watts briefly at
ApacheCon. Once this is done we could reuse it. Jeff took a first
stab at decoupling quite some time ago. We are attempting to use this
so we can completely reuse the classpath container code in Eclipse
itself inside the Maven Eclipse Extension (which should hopefully be
landing here at some point in the near future).
Jason.
> Scott
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Tom,
Tom Huybrechts wrote:
> On 12/11/06, Fabrizio Giustina <fg...@apache.org> wrote:
>> On 12/11/06, Tom Huybrechts <to...@gmail.com> wrote:
>> > In any Eclipse install, each Import-Package is provided by at least
>> > one bundle, and you can make a POM dependency on that bundle. It is
>> > quite easy to implement this by feeding all bundles in the install
>> > into the resolver and having it calculate the package wiring. This
>> > buys you one more thing: you can automatically validate if the install
>> > is consistent.
>>
>> this is only true with the main eclipse platform distribution, it's
>> not so easy for anything that depends on other projects. Take WTP,
>> birt, emf, get or anything else... they could depend on anything in
>> the target platform or in other projects: you will be able to find a
>> matching bundle only by deploying the whole callisto or europa
>> coordinated build together (and it will not so easy neither in that
>> way, since there are still some duplicate jars with slightly different
>> versions)
>>
>
> It's true that you couldn't do a deploy of say WTP without having its
> dependencies available. I have a target platform POM for this (which
> only gathers dependencies to all Eclipse artifacts I have deployed
> previously). The state is then calculated over the target platform and
> the new dependencies. If there are duplicates, the resolving process
> will pick one - the same one that would be used at runtime.
A quick comment: with Eclipse, version dependency requirements can be
specified at the level of individual bundles/plugins and at the level of
features (sets of plugins).
This is described in that document under these subsections
How to specify plug-in requirements:
http://wiki.eclipse.org/index.php/Version_Numbering#How_to_specify_plug-in_requirements
Versioning features:
http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_features
I'm sure this conclusion is obvious to all, but for Maven to 'know'
about and resolve these inter-plugin and inter-feature version
dependencies, it's got to understand the version requirements info
located in manifest.mf (at plugin level) and feature.xml (at feature level).
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Tom Huybrechts <to...@gmail.com>.
On 12/11/06, Fabrizio Giustina <fg...@apache.org> wrote:
> On 12/11/06, Tom Huybrechts <to...@gmail.com> wrote:
> > In any Eclipse install, each Import-Package is provided by at least
> > one bundle, and you can make a POM dependency on that bundle. It is
> > quite easy to implement this by feeding all bundles in the install
> > into the resolver and having it calculate the package wiring. This
> > buys you one more thing: you can automatically validate if the install
> > is consistent.
>
> this is only true with the main eclipse platform distribution, it's
> not so easy for anything that depends on other projects. Take WTP,
> birt, emf, get or anything else... they could depend on anything in
> the target platform or in other projects: you will be able to find a
> matching bundle only by deploying the whole callisto or europa
> coordinated build together (and it will not so easy neither in that
> way, since there are still some duplicate jars with slightly different
> versions)
>
It's true that you couldn't do a deploy of say WTP without having its
dependencies available. I have a target platform POM for this (which
only gathers dependencies to all Eclipse artifacts I have deployed
previously). The state is then calculated over the target platform and
the new dependencies. If there are duplicates, the resolving process
will pick one - the same one that would be used at runtime.
> fabrizio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Fabrizio Giustina <fg...@apache.org>.
On 12/11/06, Tom Huybrechts <to...@gmail.com> wrote:
> In any Eclipse install, each Import-Package is provided by at least
> one bundle, and you can make a POM dependency on that bundle. It is
> quite easy to implement this by feeding all bundles in the install
> into the resolver and having it calculate the package wiring. This
> buys you one more thing: you can automatically validate if the install
> is consistent.
this is only true with the main eclipse platform distribution, it's
not so easy for anything that depends on other projects. Take WTP,
birt, emf, get or anything else... they could depend on anything in
the target platform or in other projects: you will be able to find a
matching bundle only by deploying the whole callisto or europa
coordinated build together (and it will not so easy neither in that
way, since there are still some duplicate jars with slightly different
versions)
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Tom Huybrechts <to...@gmail.com>.
>
> - last but not least: package-level dependencies can't be handled by
> maven as is. IMHO this could not be a big problem at the moment: you
> could be forced to manually add transitive dependencies but at the
> end it doesn't really hurt (BTW, in eclipse builds package-level
> dependencies are very rare)
>
In any Eclipse install, each Import-Package is provided by at least
one bundle, and you can make a POM dependency on that bundle. It is
quite easy to implement this by feeding all bundles in the install
into the resolver and having it calculate the package wiring. This
buys you one more thing: you can automatically validate if the install
is consistent.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Fabrizio,
Fabrizio Giustina wrote:
> On 12/11/06, Scott Lewis <sl...@simulalabs.com> wrote:
>> There is a (recently proposed/adopted) version numbering spec that
>> describes using the qualifier segment to distinguish between release,
>> integration, and nightly builds. See here for the details:
>
> I can see that the docs outline rules in choosing a qualifier name for
> specific branches, but I still can't see anything useful that could be
> used to identify a final release (maybe I don't look in the correct
> place?).
I suppose I'm a little confused by what you mean by 'final release'.
Each plugin/bundle within Eclipse can/potentially does have a distinct
version identifier, and so different configurations of bundles/plugins
(including Eclipse the IDE) have a variety of different versions of
various bundles/plugins (and different version dependencies...as
described by "How to specify plug-in requirements" section on this page).
The Eclipse platform and IDE has a convention of naming the Eclipse IDE
yearly 'release' according to 2005: 3.1.0, 2006: 3.2.0, 2007: 3.2.0,
etc. All the dependencies on the versions of the various plugins that
go into the Eclipse platform are expressed via the manifest.mf as
described by the version number page.
There is the additional concept of a 'feature' in Eclipse (and
Eclipse-based apps) that has it's own version number (a feature is an
arbitrary set of plugins...like, for example, Eclipse IDE itself). For
many applications (like Eclipse IDE itself), the 'final release' version
number is frequently associated with the number specified for a
top-level feature rather than the individual plugins that make up that
feature.
>
> To be clear, this is the list of differences between eclipse and maven
> versioning that I tried to solve (or still needs to be solved):
>
> - in maven final releases don't have a build number attached, while
> snapshots do. For eclipse everything has a build number attached and
> there is no way to distinguish between snapshot-equivalent builds and
> releases (this needs to be done manually by passing the
> -DstripQualifier=true flag to make-artifacts)
At the plugin level, that's true. But it's not necessarily true at the
feature level (i.e. features can/do have distinction between
snapshot-equivalent builds and releases).
>
> - the eclipse qualifier (=the maven build number, or "the 4th token")
> can be a string, in maven MUST be numeric (the make-artifacts support
> a forced qualifier/build number for this)
>
> - the 4th token MUST be separated with "-" in maven, while in osgi
> MUST be "." (this is handled by the make-artifacts goal actually). A
> version like 1.2.3-4 in maven is parsed as [major 1, minor 2, patch 3,
> build 4], a version like 1.2.3.4 is parsed as [major 0, minor 0, patch
> 0, build 0, qualifier "1.2.3.4"] (funny, I discovered this only
> recently by looking at DefaultVersion unit tests... I can't say I like
> it but that's how maven works and it's expected to work, you will
> never notice it till you will experiment 4 digits version numbers, and
> osgi bundles HAVE 4 digits version numbers).
>
> - not a problem, but just a note: in eclipse each artifact in a single
> build can have a different qualifiers: this makes linking projects
> from the same release a real mess (the make-artifacts supports
> replacing qualifier with a forced build number for this too)
>
> - osgi bundles can specify a dependency without a version number,
> maven can't (this is handled by make-artifacts by adding a "any
> version >0" version tag)
>
> - not strictly a problem, just another note: version ranges in osgi
> bundles are hard requirements, while maven usually uses soft
> requirements. This makes the correct versioning number more and more
> required since you can easily run into "over-costrained version"
> problems: for example you will run into it when org.apache.xerces is
> deployed with a build number, and another osgi bundles depends on it
> using a strict requirement with a 3 digit only version (which in OSGI
> also matches a build with a qualifier, in maven doesn't).
>
> - last but not least: package-level dependencies can't be handled by
> maven as is. IMHO this could not be a big problem at the moment: you
> could be forced to manually add transitive dependencies but at the
> end it doesn't really hurt (BTW, in eclipse builds package-level
> dependencies are very rare)
>
> this is what I found out by months of trial and errors, I will be
> happy to complete this list with any other issue found by users.
Good idea. This is a very useful list.
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Fabrizio Giustina <fg...@apache.org>.
On 12/11/06, Scott Lewis <sl...@simulalabs.com> wrote:
> There is a (recently proposed/adopted) version numbering spec that
> describes using the qualifier segment to distinguish between release,
> integration, and nightly builds. See here for the details:
I can see that the docs outline rules in choosing a qualifier name for
specific branches, but I still can't see anything useful that could be
used to identify a final release (maybe I don't look in the correct
place?).
To be clear, this is the list of differences between eclipse and maven
versioning that I tried to solve (or still needs to be solved):
- in maven final releases don't have a build number attached, while
snapshots do. For eclipse everything has a build number attached and
there is no way to distinguish between snapshot-equivalent builds and
releases (this needs to be done manually by passing the
-DstripQualifier=true flag to make-artifacts)
- the eclipse qualifier (=the maven build number, or "the 4th token")
can be a string, in maven MUST be numeric (the make-artifacts support
a forced qualifier/build number for this)
- the 4th token MUST be separated with "-" in maven, while in osgi
MUST be "." (this is handled by the make-artifacts goal actually). A
version like 1.2.3-4 in maven is parsed as [major 1, minor 2, patch 3,
build 4], a version like 1.2.3.4 is parsed as [major 0, minor 0, patch
0, build 0, qualifier "1.2.3.4"] (funny, I discovered this only
recently by looking at DefaultVersion unit tests... I can't say I like
it but that's how maven works and it's expected to work, you will
never notice it till you will experiment 4 digits version numbers, and
osgi bundles HAVE 4 digits version numbers).
- not a problem, but just a note: in eclipse each artifact in a single
build can have a different qualifiers: this makes linking projects
from the same release a real mess (the make-artifacts supports
replacing qualifier with a forced build number for this too)
- osgi bundles can specify a dependency without a version number,
maven can't (this is handled by make-artifacts by adding a "any
version >0" version tag)
- not strictly a problem, just another note: version ranges in osgi
bundles are hard requirements, while maven usually uses soft
requirements. This makes the correct versioning number more and more
required since you can easily run into "over-costrained version"
problems: for example you will run into it when org.apache.xerces is
deployed with a build number, and another osgi bundles depends on it
using a strict requirement with a 3 digit only version (which in OSGI
also matches a build with a qualifier, in maven doesn't).
- last but not least: package-level dependencies can't be handled by
maven as is. IMHO this could not be a big problem at the moment: you
could be forced to manually add transitive dependencies but at the
end it doesn't really hurt (BTW, in eclipse builds package-level
dependencies are very rare)
this is what I found out by months of trial and errors, I will be
happy to complete this list with any other issue found by users.
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Scott Lewis <sl...@simulalabs.com>.
Hi Fabrizio,
A small clarification below
Fabrizio Giustina wrote:
> Hi Graham
>
> On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
>> These two features together, with some scripting and a place to host the
>> repository, is in theory all that would be needed to make eclipse jars
>> automatically available to maven users.
>
> I think that at the moment having a manually-updated repo could be
> enough, at least for some time. It's just a matter of downloading an
> eclipse release and run the mvn eclipse plugin that takes care of
> generating jars and uploading them.
>
> I think that it's better to have a final repository and to allow some
> more testing: at the moment everything looks really good (I am
> developing rcp applications since a couple of months and I am pretty
> happy of what we have now), but there is still something that requires
> a human eye.
>
> For example the versioning scheme of eclipse artifacts doesn't
> perfectly match the one used by maven: eclipse jars always have a
> qualifier (build number in maven) and there is no difference between a
> final release and a nightly build.
There is a (recently proposed/adopted) version numbering spec that
describes using the qualifier segment to distinguish between release,
integration, and nightly builds. See here for the details:
http://wiki.eclipse.org/index.php/Version_Numbering
This is done consistently with the platform now, and the other Europa
projects are committed to it for Europa simulataneous release.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven2 repository of eclipse jars
Posted by Fabrizio Giustina <fg...@apache.org>.
Hi Graham
On 12/11/06, Graham Leggett <mi...@sharp.fm> wrote:
> These two features together, with some scripting and a place to host the
> repository, is in theory all that would be needed to make eclipse jars
> automatically available to maven users.
I think that at the moment having a manually-updated repo could be
enough, at least for some time. It's just a matter of downloading an
eclipse release and run the mvn eclipse plugin that takes care of
generating jars and uploading them.
I think that it's better to have a final repository and to allow some
more testing: at the moment everything looks really good (I am
developing rcp applications since a couple of months and I am pretty
happy of what we have now), but there is still something that requires
a human eye.
For example the versioning scheme of eclipse artifacts doesn't
perfectly match the one used by maven: eclipse jars always have a
qualifier (build number in maven) and there is no difference between a
final release and a nightly build.
The mvn eclipse plugin is now able to convert qualifiers to the mvn
version scheme or to strip them in order to generate the "final"
released artifacts, but you have to tell it how to do: for example you
should be careful in turning the build number on when deploying
eclipse 3.3 Mx artifacts and turn it off when deploying eclipse 3.3
(final). If you don't do that, any 3.3 nightly/intergration/milestone
build will generate artifacts with the same version. That should not
be a problem if we plan to only release eclipse major versions, but
it's something that need to be checked... a fix to the build number
conversion is also in place only from a couple of weeks, so it's
better to let it settle for a while before starting to make everything
automatic...
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org