[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [atf-dev] XULRunner / ATF Update site
|
Just kidding ... well, about the second part. Just FYI, in the future,
don't forget you can RSVP to a meeting, and
suggest some issues be raised and request that a work item such as this
be
put in the plan and see who,
if anyone would volunteer to work on it.
My plan was to attend the call, but the other conflicting call overflowed
so was just bad luck ;(
Many people are on "vacation" for the Holiday in the States, so, while
they joined the call, they are not otherwise
working this week, so you may have to wait till next week for the
notes/minutes of the meeting ...
Yeah - thanksgiving is a showstopper ;)
But, I believe it was Philippe who said, this post raised some good
points, and he'd give some
thought to improving things (I think before the next ATF milestone ....
but, I never heard that specifically
committed to). And, that he would (eventually) respond her, when he
could.
ok - cool.
Bob was going to type up the minutes, and send notes/reminders for our
meeting ATF Planning meeting
next week ... maybe you can make that one?
I'll try ;)
/max
Thanks,
"Max Rydahl Andersen" <max.andersen@xxxxxxxxxx>
Sent by: atf-dev-bounces@xxxxxxxxxxx
11/21/2007 05:17 AM
Please respond to
AJAX Toolkit Framework discussion <atf-dev@xxxxxxxxxxx>
To
"AJAX Toolkit Framework discussion" <atf-dev@xxxxxxxxxxx>
cc
jbosstools-dev@xxxxxxxxxxxxxxx
Subject
Re: [atf-dev] XULRunner / ATF Update site
Hi,
I would have raised this issue on the call yesterday but unfortunately I
could not make it because of another conflicting call.
Any chance that we could get some feedback/info on how you see others
should be using the XULRunner in an updatesite to be
as compatible as possible with ATF ?
/max
Hey everyone..
Recently I was looking over ATF's update site format to get a clue for
how dependency on Mozilla's XPCOM and XULRunner plugins was handled. I
found that the main ATF feature itself does depend on org.mozilla.xpcom,
but not any of the XULRunner features/plugins. I also ran into another
interesting problem. XULRunner has been bundled as a seperate feature
for each platform implementation, and the plugins themselves live at a
different URL than the features that I found.
The 3 platform-dependent XULRunner plugins live at the following URL:
-
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/
And the 3 platform-dependent XULRunner features live at the following
URL:
- http://ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/features/
But the plugins listed at the corresponding "plugins" dir are outdated!
- http://ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/plugins/
I have a few questions since this was rather confusing..
1) Why are the URLs for feature JARs and plugins so radically different?
Shouldn't the features / plugins dirs be in sync with each other?
2) Why is XULRunner packaged as 3 seperate features? This becomes hell
for dependency management purposes. It was easier for me to just write
one simple feature and put platform/OS conditions on each XULRunner
plugin. You can find my feature.xml here:
-
http://anonsvn.jboss.org/repos/jbosstools/trunk/vpe/features/org.jboss.tools.xulrunner.feature/feature.xml
3) Why isn't ATF depending on XULRunner feature/plugins like it is with
XPCOM? With the feature linked above we were able to have our feature
depend on it, and use external plugin/feature jar linking (ala the
current ATF update site) to have Eclipse auto-check XULRunner when the
user presses "Select Required"
Just hoping to get some clarity on how ATF depends on XULRunner and
how/if we can reuse that knowledge for our project =).
Thanks!
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max@xxxxxxxxxxxxx
http://hibernate.org
JBoss a division of Red Hat
max.andersen@xxxxxxxxx
