Re: IvyDE status (Was: VOTE Retire IvyDE)

2016-12-11 Thread Gintautas Grigelionis
A short report on status (and more detailed answers to Nicholas questions):

   - the doc builds correctly once I clone ant-xooki repository on Github
   into doc/xooki;
   - the style clone on Github is empty; I did "wget -np -nd -r
   https://svn.apache.org/repos/asf/ant/site/ivyde/sources/style/
   "
   following developer doc, but I cannot find xmlverbatim.css and
   background.png in there (both files are referred to by style.css and
   print-style.css);
   - the Subversion-specific part of packaging is "svn export" which has an
   equivalent in Git: "git archive"; fairly straightforward to replace once
   the details of the distribution process with Git are clear;
   - setting up Eclipse PDE is more tricky nowadays because some components
   (notably WTP and GEF) are only released as update sites, which complicates
   a fully automated setup.

I have a question, too: perhaps the entire ivyde site repo could be
converted to Git?

Gintas


Re: IvyDE status (Was: VOTE Retire IvyDE)

2016-12-08 Thread Gintautas Grigelionis
AFAICS, Subversion is invoked in one of the targets connected to packaging
of a release, and I'm looking into an equivalent for Git.
What is more interesting is getting all Eclipse components. Current process
depends on finding a "good" mirror, and I'm tempted to investigate a
possibility to use updatesite resolver instead...

The point about using Java 8 is, you need at least Eclipse Mars (or the
other way around), period. And then there's all the GEF 4+ migration...

Gintas

2016-12-08 10:45 GMT+01:00 Nicolas Lalevée :

> I am forking the thread to not pollute the vote.
>
> > Le 7 déc. 2016 à 19:56, Gintautas Grigelionis 
> a écrit :
> >
> > I decided to take a quick look at the build process and it's not broken
> per
> > se, rather it's hardcoded to Eclipse SDK 3.7.1 foe Win32.
>
> You confirm the doc is being correctly build ? If that effectively the
> case, it is good to know, thank you for looking into it.
> But one thing is broken for sure: the Ant targets to build IvyDE for the
> release, because they still assert that the sources are being hosted in
> subversion.
>
> > I would like to
> > make the process to adapt to the build platform. Any suggestions for a
> > reasonable Eclipse baseline? Should we target Java 8, that would be 4.5
> (or
> > maybe even 4.5.2).
>
> Here is what is currently supported:
> http://ant.apache.org/ivy/ivyde/history/trunk/compatibility.html <
> http://ant.apache.org/ivy/ivyde/history/trunk/compatibility.html>
> It certainly can be reviewed.
>
> As a general rule I would make IvyDE support the same version of the JVM
> as Ivy and Eclipse does. A thing to note is that some IvyDE users are
> installing it in their IBM RAD editor, so it would be nice to continue
> supporting if it doesn’t require much effort.
>
> Nicolas
>
>


IvyDE status (Was: VOTE Retire IvyDE)

2016-12-08 Thread Nicolas Lalevée
I am forking the thread to not pollute the vote.

> Le 7 déc. 2016 à 19:56, Gintautas Grigelionis  a 
> écrit :
> 
> I decided to take a quick look at the build process and it's not broken per
> se, rather it's hardcoded to Eclipse SDK 3.7.1 foe Win32.

You confirm the doc is being correctly build ? If that effectively the case, it 
is good to know, thank you for looking into it.
But one thing is broken for sure: the Ant targets to build IvyDE for the 
release, because they still assert that the sources are being hosted in 
subversion.

> I would like to
> make the process to adapt to the build platform. Any suggestions for a
> reasonable Eclipse baseline? Should we target Java 8, that would be 4.5 (or
> maybe even 4.5.2).

Here is what is currently supported:
http://ant.apache.org/ivy/ivyde/history/trunk/compatibility.html 

It certainly can be reviewed.

As a general rule I would make IvyDE support the same version of the JVM as Ivy 
and Eclipse does. A thing to note is that some IvyDE users are installing it in 
their IBM RAD editor, so it would be nice to continue supporting if it doesn’t 
require much effort.

Nicolas