Technically speaking, the m2e bundle should've versioned its exports,
so that consumers can import only the packages that they need with the
version ranges that work for them.
In this situation I don't think bumping the bundle version to 2.0 is
worth breaking most (all?) consumers ; everyone will simply adjust the
import range to [1.x.0;3.0.0) and be done with it.
FTR, we're also consuming the archetype manager APIs, but not the ones
that will change.
Robert
On Thu, Mar 19, 2015 at 7:41 AM, Fred Bricon <fbricon(a)gmail.com> wrote:
Yes, exactly my point. major bump or not, due to archetyper classes
changes,
that is the question.
On Thu, Mar 19, 2015 at 1:29 AM, Greg Amerson <gregory.amerson(a)liferay.com>
wrote:
>
> Thanks for the details Fred. This change doesn't break our API usage
> because we just depend on some m2e-core internal APIs which don't appear to
> change with that changeset.
>
> Speaking of which, looking at just this one commit:
>
https://github.com/fbricon/m2e-core/commit/29e014e49fb2cb442ed2f935590ad1...
>
> For org.eclipse.m2e.core API I don't see any non-internal API changes,
> thus there is no reason here to necessitate a 1.6->2.0 jump. That leaves
> the jars that are bundled in the maven runtime will change with the new
> archetyper 2.3 version. So I guess that is where the 1.6->2.0 major version
> bump is required right?
>
> On Thu, Mar 19, 2015 at 11:39 AM, Fred Bricon <fbricon(a)gmail.com> wrote:
>>
>> Greg,
>>
>> only internal m2e classes have been modified, but the archetype runtime
>> doesn't expose the same Maven classes anymore
>> (org.apache.maven.archetype.Archetype -> ArchetypeManager) so... it might
>> not even apply for a major version bump after all. that's debatable I guess.
>>
>> Here's the extent of the changes, so far :
>>
https://github.com/eclipse/m2e-core/compare/master...fbricon:archetyper-2...
>>
>> If we can keep on with 1.6 with these changes, fine by me :-)
>>
>> The downside of moving to 2.0 is a lot of m2e extensions would probably
>> need to be rebuilt if they use version ranges like [1.0, 2.0). That's
>> impacts definitely more adopters than the handful that depends on the
>> archetype API.
>>
>>
>> On Wed, Mar 18, 2015 at 11:02 PM, Greg Amerson
>> <gregory.amerson(a)liferay.com> wrote:
>>>
>>> Hey Fred,
>>>
>>> Just want to clarify some of the APIs that may be changing. In our
>>> adopter product we have code that looks like this:
>>>
>>> final ArchetypeManager archetypeManager =
>>> MavenPluginActivator.getDefault().getArchetypeManager();
>>> final ArtifactRepository remoteArchetypeRepository =
>>> archetypeManager.getArchetypeRepository( archetype );
>>> ...
>>> final List<IProject> newProjects =
>>> projectConfigurationManager.createArchetypeProjects(
>>> location, archetype, groupId, artifactId, version,
>>> javaPackage, properties, configuration, monitor );
>>>
>>>
>>> I'm assuming you mean some of these APIs will change in incompatible
>>> ways in the proposed m2e 2.0? Well I guess ArchetypeManager was always
>>> marked internal, so its fair game to be changed even if m2e doesn't go
to
>>> 2.0. But the IProjectConfigurationManager was "API", so is that one
of the
>>> interfaces that will undergo breaking change in 2.0?
>>>
>>> On Thu, Mar 19, 2015 at 10:00 AM, Jason van Zyl <jason(a)takari.io>
wrote:
>>>>
>>>> Is there any downside at all to upgrading? If you've done the work
and
>>>> fixed all those issues I'm super happy you've moved us forward.
>>>>
>>>> Honestly I doubt anyone has tied into the guts of Archetype aside from
>>>> you and really I think it's a small price to pay if the odd party is.
You've
>>>> updated the code and I assume made it easier to deal with so I only see
>>>> upside.
>>>>
>>>> +1
>>>>
>>>> On Mar 18, 2015, at 7:45 PM, Fred Bricon <fbricon(a)gmail.com>
wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > I have an initial POC that uses maven-archetype-plugin 2.3, instead
>>>> > of the 2.0.alpha4 version (which was released in the 17th century,
give or
>>>> > take).
>>>> >
>>>> > I checked it fixes the following issues :
>>>> > -
https://bugs.eclipse.org/459453,
>>>> > -
https://bugs.eclipse.org/424010,
>>>> > -
https://bugs.eclipse.org/394918,
>>>> > -
https://bugs.eclipse.org/374660,
>>>> > -
https://bugs.eclipse.org/405945 (on OSX at least),
>>>> > -
https://bugs.eclipse.org/415114,
>>>> > -
https://bugs.eclipse.org/429287
>>>> >
>>>> > Bugs
https://bugs.eclipse.org/446657,
https://bugs.eclipse.org/348893
>>>> > may or not be fixed (I can't test proxies)
>>>> >
>>>> > Most of these issues were automatically closed already after 1 year
>>>> > of inactivity. Doesn't mean the bugs are not there. My level of
annoyance
>>>> > just reached a point where I'd like to take action now.
>>>> >
>>>> > The only problem with the archetype update is it will break 3rd
party
>>>> > adopters (JBoss Tools at least) depending on the archetype API
>>>> > (package/class names changed between 2.0.alpha4 and 2.3). I
don't plan on
>>>> > introducing a compatibility layer, not worth the hassle IMHO.
>>>> > Given that I'm also in charge of the JBoss Tools integration,
I'm
>>>> > fine with the impact :-)
>>>> >
>>>> > Getting the fix in will require m2e to bump its version to 2.0 (and
>>>> > open a bunch of CQs in ipzilla)
>>>> >
>>>> > I'd really like to get that change in for Eclipse Mars, if
possible.
>>>> > Is it too late from a release plan standpoint (i.e. 1.6 -> 2.0)?
PMC, fellow
>>>> > m2e committers wdyt?
>>>> >
>>>> > Fred
>>>> >
>>>> > --
>>>> > "Have you tried turning it off and on again" - The IT
Crowd
>>>> > _______________________________________________
>>>> > m2e-dev mailing list
>>>> > m2e-dev(a)eclipse.org
>>>> > To change your delivery options, retrieve your password, or
>>>> > unsubscribe from this list, visit
>>>> >
https://dev.eclipse.org/mailman/listinfo/m2e-dev
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>>
http://twitter.com/jvanzyl
>>>>
http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>>
>>>> First, the taking in of scattered particulars under one Idea,
>>>> so that everyone understands what is being talked about ... Second,
>>>> the separation of the Idea into parts, by dividing it at the joints,
>>>> as nature directs, not breaking any limb in half as a bad carver might.
>>>>
>>>> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> m2e-dev mailing list
>>>> m2e-dev(a)eclipse.org
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from this list, visit
>>>>
https://dev.eclipse.org/mailman/listinfo/m2e-dev
>>>
>>>
>>>
>>>
>>> --
>>> Greg Amerson
>>> Liferay Developer Tools
>>> Liferay, Inc.
www.liferay.com
>>>
>>> _______________________________________________
>>> m2e-wtp-dev mailing list
>>> m2e-wtp-dev(a)eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>>
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev
>>
>>
>>
>>
>> --
>> "Have you tried turning it off and on again" - The IT Crowd
>>
>> _______________________________________________
>> m2e-wtp-dev mailing list
>> m2e-wtp-dev(a)eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>>
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev
>
>
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc.
www.liferay.com
>
> _______________________________________________
> m2e-wtp-dev mailing list
> m2e-wtp-dev(a)eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
>
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev
--
"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-dev mailing list
m2e-dev(a)eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev