[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [modeling-pmc] Epsilon GMT component
|
Rich,
I also think this is a good opportunity to create a new CVS module that is properly within the modeling project's CVS structure where all the other projects reside. So likely we'd want a org.eclipse.gmt parent with a module for each project/component in GMT that's being reviewed and migrated...
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
![Inactive hide details for Richard Gronback <richard.gronback@xxxxxxxxxxx>]()
Richard Gronback <richard.gronback@xxxxxxxxxxx>
Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: modeling-pmc-bounces@xxxxxxxxxxx
06/23/2008 10:43 AM
Please respond to
PMC members mailing list <modeling-pmc@xxxxxxxxxxx> |
|
|
Excellent, thanks for the update.
See inserted comments below...
Best,
Rich
On 6/23/08 6:57 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:
> Dear EMO, Modeling PMC,
>
> We are in the process of making the Epsilon GMT component compatible
> with the Eclipse IP process and we could use some advice on the actions
> we need to take. To my understanding we should do the following:
>
> 1) File CQs in the IPZilla for any 3^rd party jars we are using
>
> We are currently using jdom.jar which has been approved for other
> projects (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1587). We also
> use version 3.1b of the ANTLR runtime jar (version 3.0 has been approved
> for other projects e.g.
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1359)
Right, so you'll just need to submit piggyback CQs through the portal.
> We¹ve removed the simmetrics jar we were using as it licensed under GPL
> which is incompatible with EPL
>
Great.
> 2) File a CQ for the pre-Eclipse code (similarly to
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1460)
>
> 3) Change the namespace from org.epsilon.* to org.eclipse.*
>
> Do we need to set the complete path of Epsilon under Eclipse as the
> namespace? In this case it would need to be org.eclipse.gmt.epsilon.*.
> However, if GMT components are to be relocated soon, this would have to
> change again. If we could set the namespace to just
> org.eclipse.epsilon.* it would be more resistant to future relocations.
> Is that OK?
>
I think org.eclipse.epsilon.* is fine.
> 4) Set version of plugins to <1 as it is a component of an Incubation
> project
>
> 5) Add (Incucation) to the name of the plugins/features
>
And download zips/jars.
> 6) Set up an IP Log page under the Epsilon website (e.g. such as
> http://www.eclipse.org/stp/development/ip_log.php)
>
You may want to leverage the query approach used by GMF (and now most of
modeling, afaik)
http://www.eclipse.org/modeling/gmf/project-info/ipquery.php That is, until
the official method is available:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220977
> I also have a question about EPL-incompatible libraries. For example, in
> Epsilon (and I believe in other modeling components too) we need to
> provide support for MOF 1.4 models which is realized by MDR (and which
> appears to be incompatible with EPL). We would also like to provide
> support for fuzzy string matching using Simmetrics (which as mentioned
> above is GPL). As we cannot host those plugins on Eclipse, I was
> wondering if we could host them elsewhere (e.g. on Sourceforge) and
> provide a link from the Epsilon GMT site to them.
>
This is a complicated issue, so copying Janet for counsel. :)
> I¹d be grateful if you could confirm, complement or comment on the above
> at your earliest convenience. I suspect that any information you provide
> would also be useful for other GMT components that are in the same process.
>
> Best regards,
> Dimitrios Kolovos
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
