September 2006 - jbosstools-dev - Jboss List Archives

[jbosside-dev] JBossIDE nightly build 200609271838-nightly results

by jbosside-build＠jboss.org

18 years, 2 months

1
0
0 / 0

[jbosside-dev] RE: About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)

by Koen Aers

So what exactly is the *right* way of bundling features Max? Is it a distribution without *any* dependency on plugins that reside in some other feature? If this is the case than I have to totally disagree. I don't want my user's to go through the pain of installing WTP only for the fact that I happen to use their XML editor plugin. > Because if user updates WTP 1.5 to WTP 1.5.1 it won't work > anymore since we have *specifc* version numbers in there. I am not exactly sure what you mean with this but if I understand well you want to provide forward compatibility between a specific release of your plugin and some future release of WTP? That is something that I don't want to do, in fact. The thing that is IMO needed is certifying that a particular release of your plugin works with a particular configuration of Eclipse/WTP/GEF/... And nothing more. If user's want to mix and match their environments and use configurations that I do not certify to work they are of course free to do so, but I will not support it. > The ide support for building plugins is not meant for building of > *distribution* of > other dependent features, but for building *deployable* > features/plugins into existing projects. All right, building using the IDE may not be fit for distributing the plugins/features. But the Eclipse PDE build is meant to this and this also breaks if I do not include the dependencies between <plugin> tags. So it seems to me that this is the way the Eclipse guys envisioned constructing features to be distributed... If not, it is a bug and the system should be changed to use some other mechanism (a la using Marshall's tasks). > > Can someone convince me with some real advantages? > > Because it breaks updatemanager, because noone else do it > this way, because we should not dictate specific versions > down to fix/micro number.....enough reason ? :) I am still not convinced as a matter of fact. - If no one else does it that way, how do these other guys do it then? All the Eclipse build mechanisms work in this way... Besides, this is really the same argument that the EMF guys use to convince you to use EMF, Max ;-) - How exactly does the update manager break? Normally the update manager should only download plugins from the site that are not yet present in the installation or if the installed version is lower than the needed version. - I do not understand your statement of 'dictating specific versions'. These specific versions are simply not specified in the <plugin> tags so that should pose no problem. Or do I miss something? > -----Original Message----- > From: Max Andersen > Sent: woensdag 27 september 2006 16:08 > To: Koen Aers; Marshall Culpepper; jbosside-dev(a)lists.jboss.org > Cc: Tom Baeyens > Subject: Re: About feature.xml and bundling plugins (WAS: > jBPM Designer feature.xml needs to be updated) > > > > - Neither the Eclipse IDE build (Export->Deployable > Features) nor the > > Eclipse PDE build (with the myriad of customTargets.xml, > > mainTargets.xml, etc files) support apparently building a > feature and > > bundling additional plugins where you don't specify the > plugins that > > you want to have bundled between <plugin> tags in your feature.xml > > - Why exactly is it then that our 'old/current' way of > bundling things > > is so 'wrong'? > > > > > The only real valuable reason I see (for now) is Robs comment: 'I'm > > just happy manual updating will go away'. But then I lose > the ability > > to build from the Eclipse IDE... Moreover, I always thought > that the > > feature.xml *has* to specify all plugins that the feature bundles, > > there is nothing 'evil' about that as I understand it. > Additionally, > > doing this process 'automagically' through an ant task can indeed > > solve a lot of manual work, but then the information has become > > implicit and hence undocumented. I may be way late with all my > > ramblings and thoughts, but I am not so sure anymore if > this is the way to go. > > The ide support for building plugins is not meant for building of > *distribution* of > other dependent features, but for building *deployable* > features/plugins into existing projects. > > > Can someone convince me with some real advantages? > > Because it breaks updatemanager, because noone else do it > this way, because we should not dictate specific versions > down to fix/micro number.....enough reason ? :) > > > -- > -- > Max Rydahl Andersen > callto://max.rydahl.andersen > > Hibernate > max(a)hibernate.org > http://hibernate.org > > JBoss a division of Red Hat > max.andersen(a)jboss.com >

18 years, 2 months

2
1
0 / 0

[jbosside-dev] About feature.xml and bundling plugins (WAS: jBPM Designer feature.xml needs to be updated)

by Koen Aers

> > just to be clear: > > Our old/current way of bundling things are *wrong* in context > of integrating with the rest of the eclipse ecosystem. you > should only have <plugin> for plugins that is actually part > of the plugin everything else is <import> of either plugin's > or feature's. > > Ok while investing some time in the issue of the bundling and the jBPM feature.xml, I have been figuring out how to use Marshall's ant task and uncovering which use cases are covered and which are not. While doing this, I could not understand the very reason anymore of why we are doing this (may be because I missed the meeting/discussion on this, or else because I am plain stupid of course). So I read the email thread once again and have the following thoughts about it. - The approach with Marshall's ant tasks (bundleDependencies and calculateFeatureDependencies) only works when building the feature headlessly. If you want to build the feature by using the Export->Deployable Features from the Eclipse IDE the approach will not work. - Neither the Eclipse IDE build (Export->Deployable Features) nor the Eclipse PDE build (with the myriad of customTargets.xml, mainTargets.xml, etc files) support apparently building a feature and bundling additional plugins where you don't specify the plugins that you want to have bundled between <plugin> tags in your feature.xml - Why exactly is it then that our 'old/current' way of bundling things is so 'wrong'? The only real valuable reason I see (for now) is Robs comment: 'I'm just happy manual updating will go away'. But then I lose the ability to build from the Eclipse IDE... Moreover, I always thought that the feature.xml *has* to specify all plugins that the feature bundles, there is nothing 'evil' about that as I understand it. Additionally, doing this process 'automagically' through an ant task can indeed solve a lot of manual work, but then the information has become implicit and hence undocumented. I may be way late with all my ramblings and thoughts, but I am not so sure anymore if this is the way to go. Can someone convince me with some real advantages? Regards, Koen

18 years, 2 months

2
1
0 / 0

[jbosside-dev] JBossIDE nightly build 200609262314-nightly results

by jbosside-build＠jboss.org

18 years, 2 months

1
0
0 / 0

[jbosside-dev] JBossIDE integration build 200609261352-integration results

by jbosside-build＠jboss.org

18 years, 2 months

1
0
0 / 0

[jbosside-dev] WTP 1.5.1

by Marshall Culpepper

Hey guys.. Apparently there are a ton of Server API/UI fixes in WTP 1.5.1 that Rob is counting on to fix some bugs... should we hold off until Beta3 to upgrade the driver or go ahead and update it now? -- Marshall Culpepper marshall.culpepper(a)jboss.com JBossIDE Team Lead JBoss, a division of Red Hat

18 years, 2 months

2
1
0 / 0

[jbosside-dev] jBPM Designer feature.xml

by Marshall Culpepper

Hey Koen.. I saw the feature.xml for jBPM GD is still listing it's dependency plugins as <plugin> instead of <requires><import/>. The new build process is failing on jBPM packaging because the feature hasn't been updated -- could you do this ASAP? -- Marshall Culpepper marshall.culpepper(a)jboss.com JBossIDE Team Lead JBoss, a division of Red Hat

18 years, 2 months

1
0
0 / 0

[jbosside-dev] Issues list is up and running..

by Marshall Culpepper

Hey guys.. The jbosside-issues list (http://lists.jboss.org) is now connected to our JIRA so any events that happen will be posted there. I test updated a few unassigned tasks just to make sure and it looks like everything is ok. If you're not already subscribed and you're a committer for JBossIDE now would be a good time to do so =). -- Marshall Culpepper marshall.culpepper(a)jboss.com JBossIDE Team Lead JBoss, a division of Red Hat

18 years, 2 months

2
2
0 / 0

[jbosside-dev] JBossIDE nightly build 200609251907-nightly results

by jbosside-build＠jboss.org

18 years, 2 months

1
0
0 / 0

[jbosside-dev] Call for tags...

by Marshall Culpepper

Hey guys... I need CVS/Subversion tags for JBossIDE 2.0.0.Beta2 -- Marshall Culpepper marshall.culpepper(a)jboss.com JBossIDE Team Lead JBoss, a division of Red Hat

18 years, 2 months

4
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev September 2006