RE: [dsdp-mtj-dev] Initial contributions on MTJ reboot

["Paula Gustavo-WGP010" <wgp010@xxxxxxxxxxxx>]

hi craig,

i agree with you the it is much better to have an MTJ release that includes the same eclipseme features. let us work with omry to see how we can make that happen

:)
gep
  

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of Craig Setera
Sent: sexta-feira, 7 de março de 2008 15:23
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Initial contributions on MTJ reboot

If you drop the Antenna support you are dropping the preprocessing feature... That is a choice you can make, but be aware of that.  My hope was that we would be able to get a release of MTJ out the door that was functionally equivalent to the next EclipseME... While I understand the concerns with legal approvals, by having two different feature sets, it is going to make it harder to move EclipseME users over to MTJ.

On Mar 7, 2008, at 12:13 PM, Paula Gustavo-WGP010 wrote:

> comments below
>
> :)
> gep
>
> -----Original Message-----
> From: dsdp-mtj-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx
> ] On Behalf Of Craig Setera
> Sent: quarta-feira, 5 de março de 2008 22:54
> To: Mobile Tools for The Java Platform mailing list
> Subject: Re: [dsdp-mtj-dev] Initial contributions on MTJ reboot
>
> Comments below...
>
> Paula Gustavo-WGP010 wrote:
>>
>> hi mtj,
>>
>> mtj was official rebooted last week and the committers have being 
>> added to the project :D.
>>
>> we are still working on update the website and the wiki with a new 
>> proposed planning. during eclipscon we will have an specific MTJ BOF 
>> to get feedback on the proposed planning from the community 
>> (_http://www.eclipsecon.org/2008/?page=sub/&id=506_
>> <http://www.eclipsecon.org/2008/?page=sub/&id=506>). if you are 
>> attending the conference, your opinion will be very important during 
>> the BOF discussions.
>>
>> now we need to talk about how to go on with the project.
>> based on the initial proposed plan that we sent to list on january, 
>> the first step will be to contribute eclipseme contribution to mtj.
>> we
>> talk with janet and we are ok to use parallel ip process on mtj.
>> eclipseme was already used on mtj, but we need to re-submit the new 
>> version of it.
>>
>> there are a couple of points that we need to address to contribute 
>> eclipseme
>> 1 - which version should we take?
>> 2 - who has the copyright of eclipseme code?
>> 3 - which external packs are used inside of it? which license they 
>> have and who hold the copyright?
>>
>> about item 1:
>> craig,
>> do you think we can go with version 1.7.7 and then apply the updated 
>> on it? i remember that you mentioned that you are working on a new 
>> version of it, but do you think it is possible that we just apply 
>> your updates on top of 1.7.7?
>>
> I think I should probably do a 1.7.8 release and get those changes in 
> that are sitting on EclipseME trunk. There are enough worthwhile 
> changes in there to get it in. Those changes are all mine, so I don't 
> know how much they would affect legal approval. Can someone give me a 
> specific "due date" and I can work to get 1.7.8 by that date? I can 
> attempt to get it together this weekend...
>
> [gep]: it would be nice if we can have it in around 2 weeks. after 
> that we will need approximately 1 week to do the refactoring into 
> eclipse coding standard and then we can submit the CQs.
>
>>
>> about item 2:
>> i looked at the code and it seems to me that there are only two 
>> copyright owners:
>> - Kevin Hunter (signing solution)
>> - Craig Setera (rest of the code)
>> craig, can you confirm that?
>>
> We went through a long discussion about this during the initial MTJ 
> project code. I can likely dig out all of those old emails, but I'm 
> wondering if we can get this information from Eclipse legal and apply 
> deltas to the last release that was cleared by legal? I've been very 
> careful since the MTJ project was started to track all changes against 
> Sourceforge bugs and any changes from others would be documented in 
> those bug reports and referred to by the change log in EclipseME. 
> Kevin and I are definitely the primary contributors.
>
> [gep]: i found the initial eclipseme contribution questionnaire. so i 
> think we are ok with that.
>
>>
>> about item 3:
>> i did an initial analysis of the code and below is a list of the 
>> packages, owners and licenses that i found
>> - antenna (Omry Yadan): EPL / LGPL
>> - Truezip (Christian Schlichtherle); Apache
>> - ObjectWeb ASM - bytecode manipulation (INRIA, France Telecom): open 
>> source?
>> - Jetty - HTTP Server (mortbay.org) - Apache (already used on MTJ)
>>
>> craig,
>> do you anticipate any possible problems with any of those packages?
>> i'm not sure if we can use antenna
>> are all of them really used? it seems to the ObjectWeb ASM is used on 
>> eclipseme preverifier impl that you mention that is not being used. i 
>> also could not find any reference in the code to the truezip 
>> component.
>>
> As you guessed, ASM is currently used primarily for the built-in 
> preverifier which *is* still in use at the moment. My goal has been to 
> remove that and replace it with Proguard. I also have tooling code on 
> trunk to generate "empty" skeleton API jars that uses ASM to do the 
> generation. In theory, that could be removed or rewritten, but I 
> intend to provide usable API jars in EclipseME 1.7.8 based on this 
> code. Longer term the project will need the ability to generate 
> skeleton API jars that can be used for preverification and emulators 
> that don't otherwise provide some of these libraries (microemulator, 
> mpowerplayer, me4se)
>
> Truezip is buried in the JAR builder to improve performance of 
> incremental builds directly to a deployable JAR file. It is definitely 
> very tied in.
>
> In terms of Antenna, EclipseME only uses the EPL portion of the 
> library.
> I'm sure that if we ask, Omry would consider producing a build for MTJ 
> that only includes the EPL licensed preprocessing code. Without that, 
> we would need to drop the preprocessor support.
>
> [gep]: i saw that we are already ok with most of those. about antenna, 
> i will talk with omry about it. maybe we can drop the antenna support 
> on the initial contribution. once the discussion with omry go on, we 
> can add it back. are you ok with that?
>
>
> Hope that helps,
> Craig
>
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
> _______________________________________________
> dsdp-mtj-dev mailing list
> dsdp-mtj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev