Re: [atf-dev] XULRunner / ATF Update site

[David M Williams <david_williams@xxxxxxxxxx>]

Well, other people on the call did raise
it ... so we on the call got all the feedback/info we needed. 

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. 

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 ... 

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. 

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? 

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
_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev