5:20 a.m.
What is wrong with as7 name?
Just leave the name as is, "as7" I mean. When you change something just
move version for bundle +1 in minor part from 2.3.0 to 2.4.0 for
example. You need to do it for all bundles in component using maven +
tycho (see max email about it).
the name came because there was as7 and as7.1 different jars - just like is needed for
Hibernate tools now today.
After 7.1 latest jar release that is no longer the case.
For me it would make more sense to remove the as71 and keep as7 as the name until the day
we *actually*
need a different one, but I wouldn't be too fuzzed about it.
…about the original question about old plugins being on disk or not then that does not
really matter for p2.
p2 has a lifecycle where after an update it will actually keep the old plugins on disk,
but they will not be loaded
*unless* someone explicitly asks for them.
If nothing asks for it then P2 will remove/clean it up on next start afaik.
Thus for normal plugins they will actually stay around one restart and disappear on the
second run.
For as7 we are talking osgi services here which are "asked" for in a different
manner than via p2 dependencies -
I do not know how that behave thus something to look into by simply trying it out.
/max
On 01/09/2012 03:04 PM, Alexey Kazakov wrote:
> BTW as-bootstrap is broken:
>
> [ERROR] Child module
>
/home/igels/Projects/jbt-3.3/trunk/as/plugins/org.jboss.ide.eclipse.as.management.as7/pom.xml
> of /home/igels/Projects/jbt-3.3/trunk/as/plugins/pom.xml does not exist @
>
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:339)
> at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632)
> at
> org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
>
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> [ERROR]
> [ERROR] The project org.jboss.tools.as:plugins:2.3.0-SNAPSHOT
> (/home/igels/Projects/jbt-3.3/trunk/as/plugins/pom.xml) has 1 error
> [ERROR] Child module
>
/home/igels/Projects/jbt-3.3/trunk/as/plugins/org.jboss.ide.eclipse.as.management.as7/pom.xml
> of /home/igels/Projects/jbt-3.3/trunk/as/plugins/pom.xml does not exist
>
> On 01/08/2012 10:37 PM, Rob Stryker wrote:
>> Hi All:
>>
>> As per JBIDE-10598, I removed the as.management.as7 plugin, since it
>> had been effectively replaced with as71. I also, as per JBIDE-10344,
>> moved the interfaces for as7 management into their own plugin called
>> as.management.core.
>>
>> The only issue I can find so far is that any installation that still has
>> the old deprecated and removed plugin as.management.as7 in the plugins
>> folder will experience errors, tons of exceptions, during startup.
>> These errors are because the previous versions of jbtools will have the
>> as.management.as7 plugin, and it will still be referencing non-existent
>> interfaces that previously lived in as.core but now live in
>> as.management.core.
>>
>> Does anyone know for sure if performing an update against an update site
>> will properly remove deprecated plugins which have been removed from
>> features? Would it be better for me to re-instate as.management.as7 as
>> am EMPTY plugin, put it back into the feature, and thus any update
>> against an update site will receive an updated empty plugin, which can
>> be removed later?
>>
>> If an update will not remove deprecated plugins which are no longer part
>> of features, it seems that putting a stub plugin back into place is the
>> only way to solve this issue.
>>
>> Any advice?
>>
>> - Rob
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen