Re: [cross-project-issues-dev] A future without source features?

2023-01-20 Thread Fred Bricon 

PDE Source Lookup (https://marketplace.eclipse.org/content/pde-source-lookup),
can automatically (lazily) discover plugin sources when missing.
it's fast, you can request to download all sources of a given Plugin
classpath container if you want (for offline use), all sources are cached
locally.


Fred Bricon

On Thu, Jan 19, 2023 at 4:24 PM Mickael Istria  wrote:

>
>
> On Thu, Jan 19, 2023 at 4:20 PM Ed Willink  wrote:
>
>> Is this serious or have I totally misunderstood?
>>
>
> Both.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


-- 
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A future without source features?

2023-01-19 Thread Mickael Istria 
On Thu, Jan 19, 2023 at 4:20 PM Ed Willink  wrote:

> Is this serious or have I totally misunderstood?
>

Both.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A future without source features?

2023-01-19 Thread Christian Dietrich 
I have understood: dont use source features, simply package them to the 
repo and tooling will do the rest


Am 19.01.23 um 16:20 schrieb Ed Willink:

Hi

Is this serious or have I totally misunderstood?

The ability to step through code with the debugger is one of the more 
important features of the Eclipse IDE.


If there are no source features, Eclipse IMHO ceases to be an IDE.

The current Tycho support makes source features very easy so why change?

Requiring an Internet connection to fetch from an external repository 
is not helpful, particularly when flying or when the Internet is 
flaky. I typically install from the platform SDK and project SDK ZIPs 
that for most projects have everything that I need. Please do not 
break a very traditional use case.


    Regards

        Ed Willink

On 16/01/2023 21:02, Mickael Istria wrote:

Hi all,

I'd like to raise to general awareness a technical proposal for 
Platform and others, that I believe is worth progressively going 
mainstream as it's a noticeable simplification to multiple processes, 
and that is very likely to be achievable in a short timeframe.

Basically, the idea is to get rid of source features.
Indeed, source features are not so important artifacts per se, what 
really matters is making source bundles available at build-time (to 
include them in p2 repositories or products) and at dev-time (to make 
them available in the IDE).
But nowadays, none of those do require source features: Tycho now has 
a cool "includeAllSources" flag on the tycho-p2-repository-plugin 
https://tycho.eclipseprojects.io/doc/latest/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllSources 
that allows to (drumroll) include all sources available from the 
reactor or the target-platform for each bundle of the resulting p2 
repository; and PDE already has capability to find locally available 
source bundles in the .target or the installation path and will soon 
have ability to resolve more source bundles from target-platform on 
demand: https://github.com/eclipse-pde/eclipse.pde/pull/425. 
Moreover, the m2e intergration with PDE makes that source bundles 
also become available locally when the artifact originates from a 
Maven repository.
All that make that instead of managing source feature artifact, we 
have workflows to make source features available to the user 
basically with just 1 flag at build time. On Platform, this would 
allow to avoid lots of "touch" commits when an external version of a 
dependency changes; we can stop listing transitive deps in 
feature.xml (p2 resolves them) but still have their source bundles in 
p2 repo (Tycho adds them).


Of course, things are rarely perfect on 1st shot; but the more people 
try to make it perfect, the more it is likely to become so. To get 
there, anyone interested please consider trying those new 
capabilities and report issues. In the best case, you may be able to 
get rid of source features and some build customization; in the worst 
case you'll report issue.


Cheers,
--
Mickael Istria
Eclipse IDE  developer, for Red 
Hat Developers 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Christian Dietrich (Diplom-Informatiker (BA))
Softwareentwickler / -Architekt
Committer and Co-Lead for Eclipse Xtext

Tel.: +49 (0) 711 / 34 21 91-0
Fax.: +49 (0) 711 / 34 21 91-29
Mobil: +49 (0) 151 / 173969 17
Mail: christian.dietr...@itemis.de
XING: https://www.xing.com/profile/Christian_Dietrich8
Web: http://www.itemis.de
Skype: christiandietrich1982
ICQ: 125801794

itemis AG
Niederlassung Süd
Industriestraße 6
70565 Stuttgart

Rechtlicher Hinweis:
Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft: Lünen
Vorstand: Jens Wagener (Vors.), Dr. Stephan Eberle, Abdelghani El Kacimi,
Wolfgang Neuhaus, Franz-Josef Schuermann
Aufsichtsrat: Michael Neuhaus (Vors.), Harald Goertz, Stephan Grollmann


--
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle, Wolfgang 
Neuhaus, Franz-Josef Schuermann
Aufsichtsrat/Supervisory Board: Michael 
Neuhaus (Vors./chairman), Harald Goertz, Eric Swehla
Sitz der 
Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen (Germany)

Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A future without source features?

2023-01-19 Thread Ed Willink 

Hi

Is this serious or have I totally misunderstood?

The ability to step through code with the debugger is one of the more 
important features of the Eclipse IDE.


If there are no source features, Eclipse IMHO ceases to be an IDE.

The current Tycho support makes source features very easy so why change?

Requiring an Internet connection to fetch from an external repository is 
not helpful, particularly when flying or when the Internet is flaky. I 
typically install from the platform SDK and project SDK ZIPs that for 
most projects have everything that I need. Please do not break a very 
traditional use case.


    Regards

        Ed Willink

On 16/01/2023 21:02, Mickael Istria wrote:

Hi all,

I'd like to raise to general awareness a technical proposal for 
Platform and others, that I believe is worth progressively going 
mainstream as it's a noticeable simplification to multiple processes, 
and that is very likely to be achievable in a short timeframe.

Basically, the idea is to get rid of source features.
Indeed, source features are not so important artifacts per se, what 
really matters is making source bundles available at build-time (to 
include them in p2 repositories or products) and at dev-time (to make 
them available in the IDE).
But nowadays, none of those do require source features: Tycho now has 
a cool "includeAllSources" flag on the tycho-p2-repository-plugin 
https://tycho.eclipseprojects.io/doc/latest/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllSources 
that allows to (drumroll) include all sources available from the 
reactor or the target-platform for each bundle of the resulting p2 
repository; and PDE already has capability to find locally available 
source bundles in the .target or the installation path and will soon 
have ability to resolve more source bundles from target-platform on 
demand: https://github.com/eclipse-pde/eclipse.pde/pull/425. Moreover, 
the m2e intergration with PDE makes that source bundles also become 
available locally when the artifact originates from a Maven repository.
All that make that instead of managing source feature artifact, we 
have workflows to make source features available to the user basically 
with just 1 flag at build time. On Platform, this would allow to avoid 
lots of "touch" commits when an external version of a dependency 
changes; we can stop listing transitive deps in feature.xml (p2 
resolves them) but still have their source bundles in p2 repo (Tycho 
adds them).


Of course, things are rarely perfect on 1st shot; but the more people 
try to make it perfect, the more it is likely to become so. To get 
there, anyone interested please consider trying those new capabilities 
and report issues. In the best case, you may be able to get rid of 
source features and some build customization; in the worst case you'll 
report issue.


Cheers,
--
Mickael Istria
Eclipse IDE  developer, for Red 
Hat Developers 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev