Hi Igor,
then it is just a simple project configurator implementation. The only
thing that is a little bit frustrating, that we talk about plugins bound
to the package phase, which is not interesting. Anyway, it is working,
and if I change the configuration of such plugin (e.g. a jar plugin
execution), then m2e will mark the project that it should be updated
(because the plugin has a configurator associated now). So far, its ok.
My question is how to store the classifier/location map to a project? I
think about to introduce a new method in IMavenProjectFacade to register
a mapping, and the implementation may store it via
IProject.setPersistentProperty(). And a getter method, which can be used
in WorkspaceStateWriter, and during java launch.
What do you think?
Regarding the IClassifierClasspathProvider, it can fall back to the map
registered in IMavenProjectFacade, if there is no concrete provider
registered. Maybe, it can be deprecated, but...
@Fred: BlankClassifierClasspathProvider is used to support the current
project. So if a class from test sources are invovled in the launch,
both test and main classes are populated to the classpath. So this is a
special case. In other cases only one location is mapped.
Is it ok then, to map one location for a classifier?
Best regards,
-- Vazul
2014-07-23 19:30 GMT+02:00 Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>:
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,
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
<mailto:fbricon@xxxxxxxxx>
<mailto:fbricon@xxxxxxxxx <mailto: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
AbstractClassifierClasspathPro__vider 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@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <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
BlankClassifierClasspathProvid____er does).
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:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>>>__:
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
_____________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx> <mailto: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>
<https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>>
<https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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>
<mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx> <mailto: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>
<https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>>
<https://dev.eclipse.org/____mailman/listinfo/m2e-dev
<https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
<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
<http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s>
<http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s
<http://www.youtube.com/watch?feature=player_detailpage&v=qw1R794sutQ#t=2765s>>
___________________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
<mailto: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>
<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>
<mailto: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>
<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 list
m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
<mailto: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>
--
"Tőled tudják, hogy testvérek vagyunk?"
http://www.youtube.com/watch?__feature=player_detailpage&v=__qw1R794sutQ#t=2765s
<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>
_______________________________________________
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
