Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Maven Integration (M2E) » stable dev build 0.9.5.20080627-1151 is published
stable dev build 0.9.5.20080627-1151 is published [message #11267] Fri, 27 June 2008 18:56 Go to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
We have published stable development build 0.9.5.20080627-1151 and are
planning to get back to regular weekly schedule for publishing dev
builds. You can install the latest dev build from the dev update site at
http://m2eclipse.sonatype.org/update-dev/

Note that project dependencies have been significantly restructured,
which changed the installation requirements. So, core feature is now
require "WST XML editor" feature (which is part of the "Eclipse IDE for
Java" and "Eclipse IDE Java EE bundles" from Europe and Ganymede or can
be installed separately from the Europe or Ganymede update sites). See
more details at
http://docs.codehaus.org/display/M2ECLIPSE/Installation+Requ irements

The most notable addition in this dev build is the Form-based POM
editor. The editor supports browsing and editing and Maven POM elements
and provides additional cross-project navigation (to parent pom, to
dependencies, to plugins, to plugin and dependencies web sites, etc).
It also incorporates dependency hierarchy and dependency graph viewers
and can show effective POM (similar to "mvn help:effective-pom"
command). Kudos to the new member of m2eclipse team, Anton Kraev, for
investigating and implementing EMF-based POM editing model and first
prototype for the editor data binding.

Other noteworthy features include improved icons and decoration
markers and handling of JDT classpath variable M2_REPO (also used by
maven-eclipse-plugin) using settings from the active Maven installation.

As before, you can see New and Noteworthy features for this and
previous builds on the wiki at
http://docs.codehaus.org/display/M2ECLIPSE/New+and+Noteworth y

We would like to hear your feedback on the new POM editor as well as
on other features you would like to see in m2eclipse. Also, please don't
hesitate to submit bug reports to the project issue tracker [1] and
expand project documentation on the wiki [2].

regards,
m2eclipse team

[1] http://jira.codehaus.org/browse/MNGECLIPSE
[2] http://docs.codehaus.org/display/M2ECLIPSE
Re: stable dev build 0.9.5.20080627-1151 is published [message #11698 is a reply to message #11267] Sun, 20 July 2008 22:19 Go to previous messageGo to next message
Hervé Boutemy is currently offline Hervé BoutemyFriend
Messages: 5
Registered: July 2009
Junior Member
I like this way of publishing regular development builds.

But I find the versioning confusing: 0.9.5.20080627-1151 has never been
intended as becoming 0.9.5 but only a preview version.
In Maven versioning scheme, it would have been something like 0.9.5-alpha-1.
In Eclipse versioning scheme, shouldn't have it been a milestone, which is
exactly a "stable development build"?
Publishing 0.9.5-M1, then 0.9.5-M2, then 0.9.5 would be easier to
understand. And easier to read in New and Noteworthy.

Is it feasible to have milestones for the next stable dev builds?
Does it mean any change in the technical details, or only a way to name the
builds?

regards,

Hervé


Eugene Kuleshov wrote:

>
> We have published stable development build 0.9.5.20080627-1151 and are
> planning to get back to regular weekly schedule for publishing dev
> builds. You can install the latest dev build from the dev update site at
> http://m2eclipse.sonatype.org/update-dev/
>
> Note that project dependencies have been significantly restructured,
> which changed the installation requirements. So, core feature is now
> require "WST XML editor" feature (which is part of the "Eclipse IDE for
> Java" and "Eclipse IDE Java EE bundles" from Europe and Ganymede or can
> be installed separately from the Europe or Ganymede update sites). See
> more details at
> http://docs.codehaus.org/display/M2ECLIPSE/Installation+Requ irements
>
> The most notable addition in this dev build is the Form-based POM
> editor. The editor supports browsing and editing and Maven POM elements
> and provides additional cross-project navigation (to parent pom, to
> dependencies, to plugins, to plugin and dependencies web sites, etc).
> It also incorporates dependency hierarchy and dependency graph viewers
> and can show effective POM (similar to "mvn help:effective-pom"
> command). Kudos to the new member of m2eclipse team, Anton Kraev, for
> investigating and implementing EMF-based POM editing model and first
> prototype for the editor data binding.
>
> Other noteworthy features include improved icons and decoration
> markers and handling of JDT classpath variable M2_REPO (also used by
> maven-eclipse-plugin) using settings from the active Maven installation.
>
> As before, you can see New and Noteworthy features for this and
> previous builds on the wiki at
> http://docs.codehaus.org/display/M2ECLIPSE/New+and+Noteworth y
>
> We would like to hear your feedback on the new POM editor as well as
> on other features you would like to see in m2eclipse. Also, please don't
> hesitate to submit bug reports to the project issue tracker [1] and
> expand project documentation on the wiki [2].
>
> regards,
> m2eclipse team
>
> [1] http://jira.codehaus.org/browse/MNGECLIPSE
> [2] http://docs.codehaus.org/display/M2ECLIPSE
Re: stable dev build 0.9.5.20080627-1151 is published (build versions) [message #11769 is a reply to message #11698] Mon, 21 July 2008 17:26 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
Hervé,

The currently used version scheme is actually derived from Eclipse
practices. Basically the idea is that release is declared as a result of
testing and verification of the regular build.

Also note that we have to take into account how OSGi dependency
resolution works and how those versions are recognized by the Eclipse
update manager. For instance, any version like 0.9.5.20080627-1151 would
be smaller then 0.9.5.M1 (note that "-" is an invalid separator for the
4th section of version text).

Eclipse uses some prefixes i nthe version qualifier to differentiate
nightly, integration, milestone and release builds (something like N, I,
v), but those cause some troubles with update manager. So, we decided to
use simple timestamp-based scheme without prefixes and when releasing,
simply move build to the release update site.

regards,
Eugene


Hervé BOUTEMY wrote:
> I like this way of publishing regular development builds.
>
> But I find the versioning confusing: 0.9.5.20080627-1151 has never been
> intended as becoming 0.9.5 but only a preview version.
> In Maven versioning scheme, it would have been something like 0.9.5-alpha-1.
> In Eclipse versioning scheme, shouldn't have it been a milestone, which is
> exactly a "stable development build"?
> Publishing 0.9.5-M1, then 0.9.5-M2, then 0.9.5 would be easier to
> understand. And easier to read in New and Noteworthy.
>
> Is it feasible to have milestones for the next stable dev builds?
> Does it mean any change in the technical details, or only a way to name the
> builds?
>
> regards,
>
> Hervé
>
Re: stable dev build 0.9.5.20080627-1151 is published (build versions) [message #11805 is a reply to message #11769] Mon, 21 July 2008 21:58 Go to previous messageGo to next message
Hervé Boutemy is currently offline Hervé BoutemyFriend
Messages: 5
Registered: July 2009
Junior Member
ok, internal build version isn't changed with Eclipse practices.

If I understand, Milestones and Releases are only public simplified
identifiers, without any info in the deliverables.

What if the subject of this thread was changed to "stable dev build 0.9.5.M1
is published (build version 20080627-1151)", without any change in the
m2eclipse deliverables?
And New and Noteworthy showing this list:
* Known issues and workarounds
* 0.9.5 / build number 20080717-1821, July 17, 2008
* 0.9.5.M2 / build number 20080713-1542, July 13, 2008
* 0.9.5.M1 / build number 20080626-1519, June 26, 2008
* 0.9.4 / build number 20080603-0114, June 3, 2008
* 0.9.4.M2 / build number 20080516-1145, May 16, 2008
* 0.9.4.M1 / build number 20080512-1100, May 12, 2008
....

It seems like it is what is done with BIRT:
http://www.nabble.com/New-Eclipse-BIRT-Milestone-Build-Avail able-for-Download-td17447425.html

From a technical point of view, this wouldn't change anything. But from a
user point of view, these simplified versions are really easier to
understand.

WDYT?

Eugene Kuleshov wrote:

> Hervé,
>
> The currently used version scheme is actually derived from Eclipse
> practices. Basically the idea is that release is declared as a result of
> testing and verification of the regular build.
>
> Also note that we have to take into account how OSGi dependency
> resolution works and how those versions are recognized by the Eclipse
> update manager. For instance, any version like 0.9.5.20080627-1151 would
> be smaller then 0.9.5.M1 (note that "-" is an invalid separator for the
> 4th section of version text).
>
> Eclipse uses some prefixes i nthe version qualifier to differentiate
> nightly, integration, milestone and release builds (something like N, I,
> v), but those cause some troubles with update manager. So, we decided to
> use simple timestamp-based scheme without prefixes and when releasing,
> simply move build to the release update site.
>
> regards,
> Eugene
>
>
> Hervé BOUTEMY wrote:
>> I like this way of publishing regular development builds.
>>
>> But I find the versioning confusing: 0.9.5.20080627-1151 has never been
>> intended as becoming 0.9.5 but only a preview version.
>> In Maven versioning scheme, it would have been something like
>> 0.9.5-alpha-1. In Eclipse versioning scheme, shouldn't have it been a
>> milestone, which is exactly a "stable development build"?
>> Publishing 0.9.5-M1, then 0.9.5-M2, then 0.9.5 would be easier to
>> understand. And easier to read in New and Noteworthy.
>>
>> Is it feasible to have milestones for the next stable dev builds?
>> Does it mean any change in the technical details, or only a way to name
>> the builds?
>>
>> regards,
>>
>> Hervé
>>
Re: stable dev build 0.9.5.20080627-1151 is published (build versions) [message #11841 is a reply to message #11805] Mon, 21 July 2008 22:23 Go to previous messageGo to next message
Eugene Kuleshov is currently offline Eugene KuleshovFriend
Messages: 504
Registered: July 2009
Senior Member
I see where you are going. It seem like it needs bit more clarification.

If we look at Eclipse Platform practices and generally to the release
train schedule (Europa, Ganymede, etc), those projects all use
approximately 6 week iterations and call result of the iteration the
milestone, usually numbered as M1, M2, etc.

In m2eclipse we been trying to stick to the similar iteration time
windows. Those intervals will need to be aligned with other Eclipse
projects, once m2e is completely moved to Eclipse. However, there is a
difference. Traditionally, working towards 1.0 release we been using
"micro" version numbers instead of milestones, e.g. 0.9.3, 0.9.4, 0.9.5,
etc. I am not sure if it would make sense to change this scheme before
1.0 release. Also note that version we'll use after moving code to
Eclipse will change, and as per Eclipse guidelines, it most likely will
be something like 0.7.0 again. I will need to double check that.

Also note that at Eclipse, the increase in minor version number
actually mean API incompatibility. We don't currently respect that and
API will be only stabilized in 1.0 version. Unless, of course, we will
have explicit demands to provide backward compatibility for 3rd party
integrators. To the moment, there was no such demands been made.

regards,
Eugene


Hervé BOUTEMY wrote:
> ok, internal build version isn't changed with Eclipse practices.
>
> If I understand, Milestones and Releases are only public simplified
> identifiers, without any info in the deliverables.
>
> What if the subject of this thread was changed to "stable dev build 0.9.5.M1
> is published (build version 20080627-1151)", without any change in the
> m2eclipse deliverables?
> And New and Noteworthy showing this list:
> * Known issues and workarounds
> * 0.9.5 / build number 20080717-1821, July 17, 2008
> * 0.9.5.M2 / build number 20080713-1542, July 13, 2008
> * 0.9.5.M1 / build number 20080626-1519, June 26, 2008
> * 0.9.4 / build number 20080603-0114, June 3, 2008
> * 0.9.4.M2 / build number 20080516-1145, May 16, 2008
> * 0.9.4.M1 / build number 20080512-1100, May 12, 2008
> ...
>
> It seems like it is what is done with BIRT:
> http://www.nabble.com/New-Eclipse-BIRT-Milestone-Build-Avail able-for-Download-td17447425.html
>
> From a technical point of view, this wouldn't change anything. But from a
> user point of view, these simplified versions are really easier to
> understand.
>
> WDYT?
>
> Eugene Kuleshov wrote:
>
>
>> Hervé,
>>
>> The currently used version scheme is actually derived from Eclipse
>> practices. Basically the idea is that release is declared as a result of
>> testing and verification of the regular build.
>>
>> Also note that we have to take into account how OSGi dependency
>> resolution works and how those versions are recognized by the Eclipse
>> update manager. For instance, any version like 0.9.5.20080627-1151 would
>> be smaller then 0.9.5.M1 (note that "-" is an invalid separator for the
>> 4th section of version text).
>>
>> Eclipse uses some prefixes i nthe version qualifier to differentiate
>> nightly, integration, milestone and release builds (something like N, I,
>> v), but those cause some troubles with update manager. So, we decided to
>> use simple timestamp-based scheme without prefixes and when releasing,
>> simply move build to the release update site.
>>
>> regards,
>> Eugene
>>
>>
>> Hervé BOUTEMY wrote:
>>
>>> I like this way of publishing regular development builds.
>>>
>>> But I find the versioning confusing: 0.9.5.20080627-1151 has never been
>>> intended as becoming 0.9.5 but only a preview version.
>>> In Maven versioning scheme, it would have been something like
>>> 0.9.5-alpha-1. In Eclipse versioning scheme, shouldn't have it been a
>>> milestone, which is exactly a "stable development build"?
>>> Publishing 0.9.5-M1, then 0.9.5-M2, then 0.9.5 would be easier to
>>> understand. And easier to read in New and Noteworthy.
>>>
>>> Is it feasible to have milestones for the next stable dev builds?
>>> Does it mean any change in the technical details, or only a way to name
>>> the builds?
>>>
>>> regards,
>>>
>>> Hervé
>>>
>>>
>
>
Re: stable dev build 0.9.5.20080627-1151 is published (build versions) [message #11900 is a reply to message #11841] Wed, 23 July 2008 21:47 Go to previous message
Hervé Boutemy is currently offline Hervé BoutemyFriend
Messages: 5
Registered: July 2009
Junior Member
ok, thanks for the explanations

regards,

Hervé


Eugene Kuleshov wrote:

>
> I see where you are going. It seem like it needs bit more clarification.
>
> If we look at Eclipse Platform practices and generally to the release
> train schedule (Europa, Ganymede, etc), those projects all use
> approximately 6 week iterations and call result of the iteration the
> milestone, usually numbered as M1, M2, etc.
>
> In m2eclipse we been trying to stick to the similar iteration time
> windows. Those intervals will need to be aligned with other Eclipse
> projects, once m2e is completely moved to Eclipse. However, there is a
> difference. Traditionally, working towards 1.0 release we been using
> "micro" version numbers instead of milestones, e.g. 0.9.3, 0.9.4, 0.9.5,
> etc. I am not sure if it would make sense to change this scheme before
> 1.0 release. Also note that version we'll use after moving code to
> Eclipse will change, and as per Eclipse guidelines, it most likely will
> be something like 0.7.0 again. I will need to double check that.
>
> Also note that at Eclipse, the increase in minor version number
> actually mean API incompatibility. We don't currently respect that and
> API will be only stabilized in 1.0 version. Unless, of course, we will
> have explicit demands to provide backward compatibility for 3rd party
> integrators. To the moment, there was no such demands been made.
>
> regards,
> Eugene
>
>
> Hervé BOUTEMY wrote:
>> ok, internal build version isn't changed with Eclipse practices.
>>
>> If I understand, Milestones and Releases are only public simplified
>> identifiers, without any info in the deliverables.
>>
>> What if the subject of this thread was changed to "stable dev build
>> 0.9.5.M1 is published (build version 20080627-1151)", without any change
>> in the m2eclipse deliverables?
>> And New and Noteworthy showing this list:
>> * Known issues and workarounds
>> * 0.9.5 / build number 20080717-1821, July 17, 2008
>> * 0.9.5.M2 / build number 20080713-1542, July 13, 2008
>> * 0.9.5.M1 / build number 20080626-1519, June 26, 2008
>> * 0.9.4 / build number 20080603-0114, June 3, 2008
>> * 0.9.4.M2 / build number 20080516-1145, May 16, 2008
>> * 0.9.4.M1 / build number 20080512-1100, May 12, 2008
>> ...
>>
>> It seems like it is what is done with BIRT:
>>
http://www.nabble.com/New-Eclipse-BIRT-Milestone-Build-Avail able-for-Download-td17447425.html
>>
>> From a technical point of view, this wouldn't change anything. But from a
>> user point of view, these simplified versions are really easier to
>> understand.
>>
>> WDYT?
>>
>> Eugene Kuleshov wrote:
>>
>>
>>> Hervé,
>>>
>>> The currently used version scheme is actually derived from Eclipse
>>> practices. Basically the idea is that release is declared as a result of
>>> testing and verification of the regular build.
>>>
>>> Also note that we have to take into account how OSGi dependency
>>> resolution works and how those versions are recognized by the Eclipse
>>> update manager. For instance, any version like 0.9.5.20080627-1151 would
>>> be smaller then 0.9.5.M1 (note that "-" is an invalid separator for the
>>> 4th section of version text).
>>>
>>> Eclipse uses some prefixes i nthe version qualifier to differentiate
>>> nightly, integration, milestone and release builds (something like N, I,
>>> v), but those cause some troubles with update manager. So, we decided to
>>> use simple timestamp-based scheme without prefixes and when releasing,
>>> simply move build to the release update site.
>>>
>>> regards,
>>> Eugene
>>>
>>>
>>> Hervé BOUTEMY wrote:
>>>
>>>> I like this way of publishing regular development builds.
>>>>
>>>> But I find the versioning confusing: 0.9.5.20080627-1151 has never been
>>>> intended as becoming 0.9.5 but only a preview version.
>>>> In Maven versioning scheme, it would have been something like
>>>> 0.9.5-alpha-1. In Eclipse versioning scheme, shouldn't have it been a
>>>> milestone, which is exactly a "stable development build"?
>>>> Publishing 0.9.5-M1, then 0.9.5-M2, then 0.9.5 would be easier to
>>>> understand. And easier to read in New and Noteworthy.
>>>>
>>>> Is it feasible to have milestones for the next stable dev builds?
>>>> Does it mean any change in the technical details, or only a way to name
>>>> the builds?
>>>>
>>>> regards,
>>>>
>>>> Hervé
>>>>
>>>>
>>
>>
Previous Topic:Re: [m2eclipse-user] m2eclipse 0.9.4 candidate
Next Topic:Running test case in Eclipse?
Goto Forum:
  


Current Time: Tue Mar 19 02:11:12 GMT 2024

Powered by FUDForum. Page generated in 0.01929 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top