| Re: [m2e-dev] Classifiers and workspace resolution during maven launch |
If the new extension depends on the plugins, then associate it with
plugins. PluginExecutionFilter and corresponding xml format used in
lifecycle mapping file is probably a good way to implement this.
--
Regards,
Igor
On 2014-07-23, 19:04, László Váradi wrote:
Hi Igor, Fred,<mailto:fbricon@xxxxxxxxx>>:
Sorry for the late answer...
So if it accepted, I'll create an issue in bugzilla and try to create a
patch.
Before doing so, I have one question:
@Igor said that this new extension point should be registered for
specific packaging types. It is necessary? It depends on the plugins, I
think, not the packaging. An extension may handle a specific plugin.
E.g. an extension can handle the jar plugin, another the war plugin,
another one should be responsible for the ear plugin. And I can imagine
that a project with ejb packaging has a jar execution with a classifier...
If we introduce this new extension, than it is not necessary to move the
workspace state properties file creation.
Best regards,
-- Vazul
2014-07-21 13:57 GMT+02:00 Fred Bricon <fbricon@xxxxxxxxx
Sorry, I'm in the middle of non-coding activities these days (on
PTO) that eat most of my brain cycles.
Overall, yeah I think a new extension point will have to be added,
while maintaining the existing iclasspathclassifier. I'm not
familiar with WorkspaceStateWriter, If the new class can completely
replace the old one, then we can think about deprecating it in 1.6
and removing it in m2e 2.0 (no ETA on that).
Not sure we can change AbstractClassifierClasspathProvider hierarchy
to inherit from the new class from core. Composition will probably
be preferable.
On Sun, Jul 20, 2014 at 9:34 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxxBlankClassifierClasspathProvid__er does).<mailto:igor@xxxxxxxxxxxxxx>> wrote:
I really wish Fred would comment here, but from my somewhat
uneducated
point of view classified dependency resolution during java app/test
launch should be the same as when launching maven build. In both
cases
classified dependencies should be resolved to a filesystem
location (or
locations).
Here is what I would do
Introduce new extension point that takes workspace project and
returns
artifactKey->location(s) map. The extensions will be registered for
specific packaging types. The default implementation will
implement the
same logic as WorkspaceStateWriter.
The new extension will need to be defined in m2e.core because it
will be
used in both in m2e.jdt and m2e.launch.
Deprecated existing IClassifierClasspathProvider extension point but
still support it.
If an artifact is resolved to multiple locations, as I
understand is the
case for some wtp-specific cases, such artifact should not be
written to
workspacestate.properties file. This is actually a missing
feature in
Maven core, but to support it properly would need some major
changes. I
don't think it's worth it, or at least this should be handled as a
separate enhancement request.
I don't mind moving workspacestate.properties generation to
per-maven
launch. It will likely be little faster overall, but I don't
think the
difference will be all that much. I believe content of all
workspacestate.properties files should be exactly the same for
the same
workspace.
--
Regards,
Igor
On 2014-07-18, 11:23, László Váradi wrote:
Hi Igor,
I just thinking about it again.
Yes, I agree, it would be a little bit confusing to have two
extension
points to something similar. But what if
MavenRuntimeLaunchSupport
generates a temporary properties file for the actual launch?
It should
use then the already existing extension point to gather the
list of
referenced workspace resolvable dependencies, and pass this
file instead
of the workspaceState.properties file. It would work only if
the launch
is about a workspace artifact, so it won't work (I think)
for launches
initiated from pom.xml files outside of a workspace project
(I mean,
pom.xml not related to a workspace project). And another
problem is the
resolving of plugins in workspace.
Another issue is that the classifierClasspathProvider
extension point is
defined in m2e.jdt plugin, not in m2e.core, which contains the
WorkspaceStateWriter. And it is created with a different
view in mind:
to support the classpath generation from Maven Dependencies
classpath
container for a normal java class launch.
Maybe it would be better to solve this issue from another
direction, and
give an extension point to get the list of classifiers and
output
locations for a project, and use this information during
java launch as
well, because it can support maven launch at the same time.
Or have
both, and use this as fallback, if there is no
classifierClasspathProvider.
My problem with the classifierClasspathProvider is that i
have to create
separate extension for different classifiers. In our case,
when there
are a few classifiers generated with jar plugin, it would be
enough to
have one extension which can analyze jar plugin executions,
so if
somebody defines a new execution with a new classifier, it
could work
without having to create a new eclipse plugin.
The advantage of classifierClaspathProvider is that it can
register
multiple locations for one classifier (as<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>:
So I think, both extensions are required...
However, if you see EjbClientClasspathProvider, the main
logic can be
used to generate entries into workspace state file. Or the
same for
WarClassesClassifierProvider. Both check some plugin
configuration for
the decision, but when a launch is about to execute and for
a dependent
project, and not at project import/update time.
My suggestion is just to put this logic somewhere where the
workspace
state properties file is generated, to support maven launch,
too.
Best regards,
-- Vazul
2014-07-17 15:04 GMT+02:00 Igor Fedorenko
<igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>___________________________________________________ <mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
I am okay with this idea but I am not sure how the new
proposed
extension point will align with existing
classifierClasspathProviders.
@Fred what do you think?
--
Regards,
Igor
On 2014-07-17, 13:54, László Váradi wrote:
Hi Igor, hi all
I just wonder if m2e would support this (resolve
"classified"
workspace
dependencies during maven launch) with a new
extension point
definition.
An extension point may got IMavenProjectFacade, and
would return
a list
of classifiers and locations, and
WorkspaceStateWriter could use
this
list to generate the workspace state properties
file. The special
"tests" classifier could be handled also by such a
class.
In our case, the project has multiple jar plugin
executions, with
different classifiers. The different executions
just differs from
different include and exclude patterns.
So we could create our extension point to handle
this configuration.
Maybe somebody could write an extension point for
ejb plugin, which
would support the generateClient attribute, to
setup the ejb-client
classifier for that project, etc...
If this is acceptable, then I would be happy to
provide a patch.
Best regards,
-- Vazul
https://dev.eclipse.org/____mailman/listinfo/m2e-dev
To change your delivery options, retrieve your
password, or
unsubscribe from this list, visit
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
___________________________________________________ <mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>https://dev.eclipse.org/____mailman/listinfo/m2e-dev
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>>
--
"Tőled tudják, hogy testvérek vagyunk?"
<http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s>
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
_________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/__mailman/listinfo/m2e-dev
<https://dev.eclipse.org/mailman/listinfo/m2e-dev>
--"Have you tried turning it off and on again" - The IT Crowd
_______________________________________________
m2e-dev mailing listm2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/m2e-dev
--
"Tőled tudják, hogy testvérek vagyunk?"
http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-dev