1:52 a.m.
Hey Max..
Snjezana is reporting that the update site I gave her worked OK for
installing/updating, but I was unable to reproduce her results in Linux
or Mac. I went ahead and added the update site to all the relevant
features in trunk as well as the jbostools-2.0.x branch (see my commit
logs for JBIDE-1499), and after testing locally everything seems to be
working fine.
Should I go ahead and re-tag 2.0.1.GA / rebuild / reupload to
sourceforge? There are about 200 people that managed to download the
2.0.1.GA that's there now, so I can post a message on the blog and on
our forum so they're aware of what's going on (and why we hadn't
announced yet)
The other option would be to keep the binaries that are there, and do a
quick 2.0.2.GA with the new updates etc, but I think this probably
doesn't merit a new release...
--
Marshall Culpepper
JBoss Developer Studio, JBoss Tools
marshall(a)jboss.org
10:47 a.m.
Snjezana is reporting that the update site I gave her worked OK for
installing/updating, but I was unable to reproduce her results in Linux
or Mac. I went ahead and added the update site to all the relevant
features in trunk as well as the jbostools-2.0.x branch (see my commit
logs for JBIDE-1499), and after testing locally everything seems to be
working fine.
ok - the problem with this is that JBDS users will then also update from this updatesite
and we don't necessarily want that to happen automatically because not all version of
jbosstools
is QA'ed in context of JBDS ;(
Any idea why it works fine on one OS but not on others?
Should I go ahead and re-tag 2.0.1.GA / rebuild / reupload to
sourceforge? There are about 200 people that managed to download the
2.0.1.GA that's there now, so I can post a message on the blog and on
our forum so they're aware of what's going on (and why we hadn't
announced yet)
Do i understand it correctly when I say that the current updatesite works fine on
Windows,
but not on linux/mac ?
The other option would be to keep the binaries that are there, and do
a
quick 2.0.2.GA with the new updates etc, but I think this probably
doesn't merit a new release...
Well, it does since its redefine how the versions are updated/resolved.
-max
12:50 p.m.
Max Rydahl Andersen wrote:
> Snjezana is reporting that the update site I gave her worked OK
for
> installing/updating, but I was unable to reproduce her results in Linux
> or Mac. I went ahead and added the update site to all the relevant
> features in trunk as well as the jbostools-2.0.x branch (see my commit
> logs for JBIDE-1499), and after testing locally everything seems to be
> working fine.
>
ok - the problem with this is that JBDS users will then also update from this updatesite
and we don't necessarily want that to happen automatically because not all version of
jbosstools
is QA'ed in context of JBDS ;(
Any idea why it works fine on one OS but not on others?
I haven't tried it on Mac, but the difference can be only in XULRunner.
I propose creating a xulrunner feature and putting it on SVN. This
feature could contain xulrunner plugins for all supported OSes and the
xpcom plugin.
Eclipse would load a corresponding plugin based on "Platform Filter" in
the manifest file.
In this way, we would have one archive for all the OSes and wouldn't
depend on the ATF/Mozilla plugins.
> Should I go ahead and re-tag 2.0.1.GA / rebuild / reupload to
> sourceforge? There are about 200 people that managed to download the
> 2.0.1.GA that's there now, so I can post a message on the blog and on
> our forum so they're aware of what's going on (and why we hadn't
> announced yet)
>
Do i understand it correctly when I say that the current updatesite works fine on
Windows,
but not on linux/mac ?
It works on Linux as well.
Snjeza
1:22 p.m.
I haven't tried it on Mac, but the difference can be only in
XULRunner.
I propose creating a xulrunner feature and putting it on SVN. This
feature could contain xulrunner plugins for all supported OSes and the
xpcom plugin.
Eclipse would load a corresponding plugin based on "Platform Filter" in
the manifest file.
In this way, we would have one archive for all the OSes and wouldn't
depend on the ATF/Mozilla plugins.
I thought that was what we had today (our own feature that depends on specific plugins
where ATF
also fetches their dependencies)
We would like to be compatible with ATF, would that still be possible with having a
different set
of binaries?
-max
1:43 p.m.
Max Rydahl Andersen wrote:
> I haven't tried it on Mac, but the difference can be only in
XULRunner.
> I propose creating a xulrunner feature and putting it on SVN. This
> feature could contain xulrunner plugins for all supported OSes and the
> xpcom plugin.
> Eclipse would load a corresponding plugin based on "Platform Filter" in
> the manifest file.
> In this way, we would have one archive for all the OSes and wouldn't
> depend on the ATF/Mozilla plugins.
>
I thought that was what we had today (our own feature that depends on specific plugins
where ATF
also fetches their dependencies)
We would like to be compatible with ATF, would that still be possible with having a
different set
of binaries?
-max
ATF creates its own binaries in the same way (see the ATF Web Tools
Package). We don't have to change ATF/Mozilla plugins. We would only
change the feature and host it on the JBoss site.
Snjeza
1:26 p.m.
On Mon, 2008-03-17 at 18:50 +0100, Snjezana Peco wrote:
I haven't tried it on Mac, but the difference can be only in
XULRunner.
I propose creating a xulrunner feature and putting it on SVN. This
feature could contain xulrunner plugins for all supported OSes and the
xpcom plugin.
Eclipse would load a corresponding plugin based on "Platform Filter" in
the manifest file.
In this way, we would have one archive for all the OSes and wouldn't
depend on the ATF/Mozilla plugins.
We already have a XULRunner feature, that does precisely this.. see:
http://fisheye.jboss.com/browse/JBossTools/trunk/vpe/features/org.jboss.t...
Bundling all of XULRunner's platform-specific plugins into one bundle is
a Bad Idea(TM) as each platform weighs in around 15+ MB, effectively
increasing our binary size by 30MB.
Marshall Culpepper
JBoss Developer Studio, JBoss Tools
marshall(a)jboss.org
6641
days inactive
6641
days old
jbosstools-dev@lists.jboss.org
5 comments
3 participants
participants (3)
-
Marshall Culpepper -
Max Rydahl Andersen -
Snjezana Peco