and defines al
> phases of the usual jar except that it does not bind any plugins by
> default, or maybe thinking more about it maybe one should not use any
> name but a simple list e.g.
>
>
> jar
>clean,custom,package,install (would default to
> lifecycle of pa
not use any
name but a simple list e.g.
jar
clean,custom,package,install (would default to
lifecycle of packaging if not given)
would define an (empty) lifecycle that has the phase
clean,custom,package,install only and now you know the order one can
bind plugins there...
Am 0
t will require a pom in the
> middle
> > leading to werid structures like root/services/x/pom.xml
> root/lib/x/pom.xml
> > so composition would be better there - but you're right, not a blocker to
> > build the final deliverables.
> >
> >
mposition would be better there - but you're right, not a blocker to
build the final deliverables.
Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anything you want tin pom
a blocker to
build the final deliverables.
>
> Main problem for me is that currently packaging == type == lifecycle,
> otherwise one could simply have an "empty" lifecycle + whatever
> packaging and simply bind anything you want tin pom.xml e.g.
>
>
>
> jar
>
Isn't it already possible to "extend" the lifecycle by simply putting
plugin + execution into root pom?
Main problem for me is that currently packaging == type == lifecycle,
otherwise one could simply have an "empty" lifecycle + whatever
packaging and simply bind anyt
Hi all,
Reviewing and trying to follow Martin's thread about JPMS I thought about
the old issue that our build pipelines (plugins chain) is very hard to
customize.
Guillaume added the priority case but the clean solution proposed
originally was to define custom lifecycles (to add frontend, docker
Hi,
It should be worked out of the box.
configuration for plugin wich add new packaging, in parent / super pom
should be defined in section:
build -> *pluginManagement*
and only in module when you can use custom packaging you add
plugin in build -> plugin
śr., 7 paź 2020 o
So far what I've done is change the parent POM to configure this additional
plugin in the none phase, and then remap the jar packaging type and include
it there.
This seems to work, but I'm wondering whether there is better approach.
On Wed, Oct 7, 2020 at 7:47 AM Alvaro Sanche
Hi,
I'm writing a plugin that intends to support custom packaging types.
The plugin's components.xml looks like:
org.apache.maven.lifecycle.mapping.LifecycleMapping
my-c
; form of import org.eclipse.aether.graph.Dependency and
> org.eclipse.aether.artifact.Artifact objects.
>
> Is there some way from these or related objects I can gather the
> information about the packaging of the dependency? That is, the type
> child element of the dependency element in the origi
On Fri, Sep 21, 2018 at 3:21 AM, wrote:
> a dependency has a type, but not really a packaging: a packaging is a recipe
> to build a project that will produce multiple artifacts, each with its own
> type
>
> see the comparison [1]
>
> and default artifact handlers [2] g
On Thu, Sep 20, 2018 at 10:34 PM, Lennart Jörelid
wrote:
> Hello Elliotte,
>
> I usually use the depends-maven-plugin, which collects information about
> dependencies within a property file.
> The data format within this property file (typically placed within
> target/classes/META-INF/maven/depend
a dependency has a type, but not really a packaging: a packaging is a recipe to
build a project that will produce multiple artifacts, each with its own type
see the comparison [1]
and default artifact handlers [2] gives you informations about default types.
The only misleading field IMHO is
ere some way from these or related objects I can gather the
> information about the packaging of the dependency? That is, the type
> child element of the dependency element in the original pom.xml file?
>
> I seem to be able to get the extension of the file, but that's not
> quite
With Eclipse Aether I can read a pom and gather information in the
form of import org.eclipse.aether.graph.Dependency and
org.eclipse.aether.artifact.Artifact objects.
Is there some way from these or related objects I can gather the
information about the packaging of the dependency? That is, the
in fact, this update is done for situation where the report documents plugins
not created with Maven Plugin Tools: perhaps the other build tool may change
the location of generated plugins.xml
IMHO, this has to be discussed with the issue reporter: I don't know if the
parameter is only a way to
I would like to see this as a readOnly parameter. Changing it value will
break things.
On Sat, 06 Jan 2018 01:50:51 +0100, wrote:
+@Parameter( defaultValue =
"${project.build.outputDirectory}/META-INF/maven/plugin.xml", required =
true )
+private File pluginXmlFile;
---
How about surrounding the packaging with spaces, there's enough room and
it looks friendlier to me.
On Fri, 22 Dec 2017 15:35:30 +0100, Hervé BOUTEMY
wrote:
as discussed on IRC, split information in 2 separate parts:
- project groupId + artifactId coordinates in header
- packagi
as discussed on IRC, split information in 2 separate parts:
- project groupId + artifactId coordinates in header
- packaging in footer (not part of coordinates)
to me, the result is now ok to merge (after squashing...)
no objection from anybody?
Regards,
Hervé
Le vendredi 22 décembre 2017, 11
Now MNG-6308 looks fine to me. If you agree you can merge it.
Robert
On Sun, 10 Dec 2017 20:46:38 +0100, Hervé BOUTEMY
wrote:
Le dimanche 10 décembre 2017, 19:26:53 CET Robert Scholte a écrit :
On Sun, 10 Dec 2017 18:38:55 +0100, Stephen Connolly
wrote:
> On Sun 10 Dec 2017 at 17:12, Ro
Le dimanche 10 décembre 2017, 19:26:53 CET Robert Scholte a écrit :
> On Sun, 10 Dec 2017 18:38:55 +0100, Stephen Connolly
>
> wrote:
> > On Sun 10 Dec 2017 at 17:12, Robert Scholte wrote:
> >> On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
> >>
> >>
> >> wrote:
> >> > Le dimanche 10 décemb
On Sun, 10 Dec 2017 18:38:55 +0100, Stephen Connolly
wrote:
On Sun 10 Dec 2017 at 17:12, Robert Scholte wrote:
On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
wrote:
> Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
>> I still think it is ugly to use the HR for th
On Sun 10 Dec 2017 at 17:12, Robert Scholte wrote:
> On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
> wrote:
>
> > Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
> >> I still think it is ugly to use the HR for this kind of info.
> >> If you *really* want this info, I'd pr
On Sun, 10 Dec 2017 17:46:10 +0100, Hervé BOUTEMY
wrote:
Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
I still think it is ugly to use the HR for this kind of info.
If you *really* want this info, I'd prefer a new line, offering more
space
for additional info.
yes, I
Le dimanche 10 décembre 2017, 11:06:32 CET Robert Scholte a écrit :
> I still think it is ugly to use the HR for this kind of info.
> If you *really* want this info, I'd prefer a new line, offering more space
> for additional info.
yes, I *really* want this info: the precise details on how to displ
On Sun 10 Dec 2017 at 10:06, Robert Scholte wrote:
> I still think it is ugly to use the HR for this kind of info.
I think the HR use with space *not [] is a beautiful solution
> If you *really* want this info, I'd prefer a new line, offering more space
> for additional info.
Ugh no... buil
I still think it is ugly to use the HR for this kind of info.
If you *really* want this info, I'd prefer a new line, offering more space
for additional info.
Other option is to leave it as it is. If developers want it, they can put
it in the name.
So -1 for me.
Robert
On Sun, 10 Dec 2017
is there a seconder for this enhancement?
CI: https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/
job/MNG-6308_display_packaging/
Jira issue: https://issues.apache.org/jira/browse/MNG-6308
Regards,
Hervé
-
ish way.
My current goal: generate a bom style pom with all reactor projects in
dptMngt section.
As people are lazy to write dptMngt section in theirs poms they
delegate
to
others with this pom.
So as I'm lazy too I don't want to write/maintain this pom neither so
I
prefer using a pl
;> Hi,
>>> Not sure how to do that in a non hackhish way.
>>> My current goal: generate a bom style pom with all reactor projects in
>>> dptMngt section.
>>> As people are lazy to write dptMngt section in theirs poms they delegate
>>> to
>>> o
;> to
>> others with this pom.
>> So as I'm lazy too I don't want to write/maintain this pom neither so I
>> prefer using a plugin for that :-)
>> So I create a new packaging type bom and enable it on a pom.
>> The plugin simply generate a pom.xml file w
x27;m lazy too I don't want to write/maintain this pom neither so I
prefer using a plugin for that :-)
So I create a new packaging type bom and enable it on a pom.
The plugin simply generate a pom.xml file with all content and the
calculated dptMngt section.
The only way I found to replace the c
n this pom neither so I
prefer using a plugin for that :-)
So I create a new packaging type bom and enable it on a pom.
The plugin simply generate a pom.xml file with all content and the
calculated dptMngt section.
The only way I found to replace the current pom is to use: project.setFile(
the new pom
Hi all,
thanks for the support, the message is clear.
I'll continue with the implementation.
Robert
Op Sat, 09 Jan 2016 18:04:40 +0100 schreef Robert Scholte
:
Hi,
I've created MDEPLOY-205: MavenProject with only attachments must have
packaging "pom"[1]
If I
and the package produces
> > > different classified wars).
> > >
> > > So IMHO abuse of profiles, not a reason to support attachments without
> a
> > > main artifact when packaging is 'war'.
> > > Instead I would suggest extracting the configura
> > detail: a war project which I need to build with different profiles to
> > include different
> > configurations. So I set up different filters and the package produces
> > different classified wars).
> >
> > So IMHO abuse of profiles, not a reason to sup
> configurations. So I set up different filters and the package produces
> different classified wars).
>
> So IMHO abuse of profiles, not a reason to support attachments without a
> main artifact when packaging is 'war'.
> Instead I would suggest extracting the configura
; configurations. So I set up different filters and the package produces
> different classified wars).
>
> So IMHO abuse of profiles, not a reason to support attachments without a
> main artifact when packaging is 'war'.
> Instead I would suggest extracting the confi
classified wars).
So IMHO abuse of profiles, not a reason to support attachments without a
main artifact when packaging is 'war'.
Instead I would suggest extracting the configuration or if one *really*
wants to include configuration: use overlays per environment.
thanks,
Robert
Scholte a écrit :
that's all handled by the ArtifactHandler, which knows how to translate
the packaging and type to a specific file extension.
So let me rephrase: in my opinion a non-pom MavenProject MUST have a
main
artifact.
Regarding the integration tests, to me they abuse the lifecycle
g one main
artifact (and not only attachements) seems reasonable to me
Regards,
Hervé
Le samedi 9 janvier 2016 19:34:37 Robert Scholte a écrit :
> that's all handled by the ArtifactHandler, which knows how to translate
> the packaging and type to a specific file extension.
> So let me rephr
debug the plugin?
In cases like this I am always debugging the code.
On Sat, Jan 9, 2016 at 7:34 PM, Robert Scholte
wrote:
that's all handled by the ArtifactHandler, which knows how to translate
the packaging and type to a specific file extension.
So let me rephrase: in my opinion a non-pom
Even if they are not real world ITs they are reasonable tests.
Did you debug the plugin?
In cases like this I am always debugging the code.
On Sat, Jan 9, 2016 at 7:34 PM, Robert Scholte wrote:
> that's all handled by the ArtifactHandler, which knows how to translate
> the packaging
+1 to introduce this policy which surely reduce the confusion of packaging
type during deploy:deploy-file
-D
On Sat, Jan 9, 2016 at 10:34 AM, Robert Scholte
wrote:
> that's all handled by the ArtifactHandler, which knows how to translate
> the packaging and type to a specific fil
that's all handled by the ArtifactHandler, which knows how to translate
the packaging and type to a specific file extension.
So let me rephrase: in my opinion a non-pom MavenProject MUST have a main
artifact.
Regarding the integration tests, to me they abuse the lifecycle for a
spe
what about packaging=bundle? it has jar extension
-D
On Sat, Jan 9, 2016 at 9:04 AM, Robert Scholte wrote:
> Hi,
>
> I've created MDEPLOY-205: MavenProject with only attachments must have
> packaging "pom"[1]
>
> If I apply such a change, tests written f
Hi,
I've created MDEPLOY-205: MavenProject with only attachments must have
packaging "pom"[1]
If I apply such a change, tests written for MDEPLOY-45 and MDEPLOY-78 fail.
[ERROR] The following builds failed:
[ERROR] * mdeploy-45-test\pom.xml
[ERROR] * no-main-artifact-1
Github user atanasenko closed the pull request at:
https://github.com/apache/maven/pull/43
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
Github user atanasenko closed the pull request at:
https://github.com/apache/maven-integration-testing/pull/11
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
Github user atanasenko closed the pull request at:
https://github.com/apache/maven-integration-testing/pull/12
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
GitHub user atanasenko opened a pull request:
https://github.com/apache/maven-integration-testing/pull/12
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping
mojo executions
You can merge this pull request into a Git repository by running:
$ git pull https
Github user atanasenko commented on the pull request:
https://github.com/apache/maven/pull/43#issuecomment-96817019
It looks like you applied only the pom file change of sisu version.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHu
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/43#issuecomment-96789423
Applied on d8ae13fd7b6be8a238a2b74f2b494668cd967c30. If it looks good then
close out this issue along with the IT PR.
---
If your project is set up for it, you can reply t
GitHub user atanasenko opened a pull request:
https://github.com/apache/maven/pull/43
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping
mojo executions
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
GitHub user atanasenko opened a pull request:
https://github.com/apache/maven-integration-testing/pull/11
MNG-5805: Custom packaging types: configuring DefaultLifecycleMapping
mojo executions
You can merge this pull request into a Git repository by running:
$ git pull https
y has 'goals' parameter in components.xml, and
> DefaultLifecyclePluginAnalyzer does not take those into account.
>
> I propose an enhancement, which adds support for setting configuration and
> dependencies as part of custom packaging type mojo executions.
>
> A usecase
ccount.
I propose an enhancement, which adds support for setting configuration and
dependencies as part of custom packaging type mojo executions.
A usecase is an ability to create a packaging type which mostly consists of
standard maven plugins but with a custom configuration.
Example: package phase
"dependencies" are linked at runtime and non-hpi dependencies are packaged
> in WEB-INF/lib
>
> Most of the other packaging types produce jar files and use the packaging
> to determine the lifecycle
>
> Having said all that, the *default* descriptor should be just a zip... But
ime and non-hpi dependencies are packaged
in WEB-INF/lib
Most of the other packaging types produce jar files and use the packaging
to determine the lifecycle
Having said all that, the *default* descriptor should be just a zip... But
if you override the default you can have a descriptor that produces
If I decide to try to prototype this
> > > out,
> > > >> where is a good place to lay down some code?
> > > >>
> > > >>
> > > >> Cheers,
> > > >> Paul
> > > >>
> > > >> On Thu, Dec 11, 2014 at 7:29
>
> > >>
> > >> Cheers,
> > >> Paul
> > >>
> > >> On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com > wrote:
> > >> >
> > >> > I think having an asse
On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >> >
> >> > I think having an assembly type with a default binding of
> assembly:single
> >> > to the packaging phase and a default descriptor bei
>
>> On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>> >
>> > I think having an assembly type with a default binding of assembly:single
>> > to the packaging phase and a default descriptor being the zip
n some code?
>
>
> Cheers,
> Paul
>
> On Thu, Dec 11, 2014 at 7:29 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> >
> > I think having an assembly type with a default binding of assembly:single
> > to the packaging phase and a def
t binding of assembly:single
> to the packaging phase and a default descriptor being the zip or zip and
> tar.gz descriptors would achieve what is required while simplifying
> escalating to more complex descriptors
>
> On Thursday, December 11, 2014, Timothy Astle
> wrote:
>
> > I
I think having an assembly type with a default binding of assembly:single
to the packaging phase and a default descriptor being the zip or zip and
tar.gz descriptors would achieve what is required while simplifying
escalating to more complex descriptors
On Thursday, December 11, 2014, Timothy
ostic bundling artifact. At the moment, we lean on
Subversion externals, which I really dislike doing.
In this type of case, I figured a ZIP packaging type would have
described the project and produced the expected output, while using
Maven. A big thing that I like about Maven is how you mode
Hmm, not sure I agree - I think its just fact that users would love to have
simpler way to create ZIPs/TARs
and the most logical/simple way (from a users point of view) to do this is a
packaging typ for these.
Domi
On 11.12.2014, at 09:27, Stephen Connolly
wrote:
> Well the real question
exploding the zip dependencies and copy tar.gz?
A better approach might be an "assembly" packaging with a default
assembly descriptor directory and if empty it falls back to zip and tar.gz
of target/classes with the resources plugin being in the default lifecycle
binding
That would make
Yes, but I don't think making a specific plugin just for adding zip
packaging is optimal. Hence the idea of having it in the assembly plugin.
Thinking of it though, one very likely wants to create both a zip and a tar
file. So maybe the packaging type should be something else, and then it
cr
Anders, like make a maven-zip-plugin project?
On Dec 11, 2014 1:50 AM, "Anders Hammar" wrote:
> I don't think that the zip package type should be part of Maven core, but
> we could provide some plugin which provides for it as a custom packaging
> type. Possibly this could
I don't think that the zip package type should be part of Maven core, but
we could provide some plugin which provides for it as a custom packaging
type. Possibly this could be part of the assembly plugin.
/Anders
On Thu, Dec 11, 2014 at 7:33 AM, Paul Benedict wrote:
> Well my exper
Well my experience in building a zip *as a dependency* feels like it's
hackish. For example, I create a "pom" packaging type and then configure
the assembly plugin for the "package" phase. Okay, but I say this is
hackish because it's not straight forward, and the zip
Probably because people just use the assembly plugin ?
Kristian
2014-12-11 6:38 GMT+01:00 Paul Benedict :
> Recently I needed to create zip artifacts for overlays into WAR. Maven
> doesn't have support for "zip" packaging type projects, but MNG-1683 wants
> to introd
But there is nothing stopping people from adding custom packaging types, right?
The real question is there enough demand to warrant folding it into Maven
itself versus making the people that need it define it themselves. We have
defined a number of custom packaging types for our own component
Recently I needed to create zip artifacts for overlays into WAR. Maven
doesn't have support for "zip" packaging type projects, but MNG-1683 wants
to introduce it.
I am curious why this issue has been ignored. Is it just a lack of time or
interest? Or is there a philosophical i
Hi all mates,
I faced today a strange issue(?) that I experienced with Maven 3.1.1 and
3.2.2: as per subject, org.apache.maven.artifact.resolver.ArtifactResolver
ignores packaging when resolving artifacts, I mean that if a request
com.acme:acme-commons:pom:1.7.0
the ArtifactResolver componnet
ote:
>>>
>>>> Hi
>>>>
>>>> Maybe I'm doing something wrong and maybe it's Maven bug.
>>>> Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x
>>>>
>>>> I have multi-module test project for my plugin:
>&g
ps://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
>>>
>>> There are two submodules: "app1" and "app2", both with custom "play"
>>> packaging. "app2" depe
gt; Failing with many Maven versions: 2.2.1, 3.0.x, 3.1.x
>>
>> I have multi-module test project for my plugin:
>> https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
>>
>> There are two submodules: "a
t/inter-app-dependency
>
> There are two submodules: "app1" and "app2", both with custom "play"
> packaging. "app2" depends on "app1".
> "play" packaging lifecycle is producing zip file (you can see "zip" in
> the logs).
&g
for my plugin:
>> https://maven-play-plugin.googlecode.com/svn/tags/test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
>>
>> There are two submodules: "app1" and "app2", both with custom "play"
>> packaging. "app2" dep
test-projects-1.0.0-beta6/packagings/default/inter-app-dependency
>
> There are two submodules: "app1" and "app2", both with custom "play"
> packaging. "app2" depends on "app1".
> "play" packaging lifecycle is producing zip
re are two submodules: "app1" and "app2", both with custom "play"
packaging. "app2" depends on "app1".
"play" packaging lifecycle is producing zip file (you can see "zip" in
the logs).
Everything starts working after installing &qu
On 12/07/2011, at 8:13 PM, Benson Margulies wrote:
> Brett,
>
> I'm not working on a problem -- well, to be exact, there was an NPE in
> the code in question, but that's fixed. I happened to see this code
> while working on 'aggregate' and I wondered if it was entirely
> satisfactory.
Cool - it
Brett,
I'm not working on a problem -- well, to be exact, there was an NPE in
the code in question, but that's fixed. I happened to see this code
while working on 'aggregate' and I wondered if it was entirely
satisfactory.
--benson
On Tue, Jul 12, 2011 at 3:03 AM, Brett Porter wrote:
>
> On 11
On 11/07/2011, at 9:04 PM, Benson Margulies wrote:
>>
>> Why is it doing this at all?
>
> Jörg,
>
> Honestly, I have no idea -- I just happened to spot it on the way by.
> And when I thought some more, I realized that my question is
> mis-stated. The issue here isn't classpath, it's more relat
On 11 July 2011 12:37, Jörg Schaible wrote:
> Stephen Connolly wrote:
>
>> http://mojo.codehaus.org/build-helper-maven-
> plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67
>>
>> Don't limit yourself to just one directory...
>
> Yeah, but this raises the question, if a JXR report over
Stephen Connolly wrote:
> http://mojo.codehaus.org/build-helper-maven-
plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67
>
> Don't limit yourself to just one directory...
Yeah, but this raises the question, if a JXR report over generated Java
sources is actually wanted.
> And the
http://mojo.codehaus.org/build-helper-maven-plugin/xref/org/codehaus/mojo/buildhelper/AddSourceMojo.html#67
Don't limit yourself to just one directory...
And then if this is not a Java based project, those directories might
be not holding .java files...
On 11 July 2011 12:04, Benson Margulies w
>
> Why is it doing this at all?
Jörg,
Honestly, I have no idea -- I just happened to spot it on the way by.
And when I thought some more, I realized that my question is
mis-stated. The issue here isn't classpath, it's more related to
yours: What's the configured java src directory, and is there
Hi Benson,
Benson Margulies wrote:
> In the jxr plugin, I see:
>
> if ( !"pom".equals( getProject().getPackaging().toLowerCase() ) )
> {
> l.addAll( sourceDirs );
> }
>
> This can't be good, can it? Isn't there some way to tell what are the
> classpath packagings?
W
In the jxr plugin, I see:
if ( !"pom".equals( getProject().getPackaging().toLowerCase() ) )
{
l.addAll( sourceDirs );
}
This can't be good, can it? Isn't there some way to tell what are the
classpath packagings?
There's a difference between the packaging type (car) and the file extension
(jar) so there's nothing to do actually.
That being said, there's already a 'car' type out there in Geronimo [1]. Are
you aware of this? If you want to add an official support in the ear pl
Pablo wrote:
The behaviour i want is the same as the maven-ejb-plugin: Defines an ejb
packaging type but the artifact gets installed in the repo as a .jar and
gets bundled in the ear as .jar too.
The relevant magic is called an artifact handler. See [0] and look for
the EJB case.
Benjamin
Hi,
I am trying to come out with a plugin to detect and process JEE
application clients.
I created a new packaging type called 'car' through
META-INF/plexus/components.xml
(http://maven-car-plugin.googlecode.com/svn/trunk/maven-car-plugin/src/main/resources/META-INF/plexus/comp
Hi,
I'm wondering whether it is possible to figure-out the filename extension of
the artifact created by a foobar packaging type.
When creating a life cycle under artifact handler role we define
(not necessarily however) the extension for the artifact. I want to
determine this extension gi
om-project mojo creates
>> archetype project with packaging maven-archetype, but that packaging seems
>> not to be supported by / valid for 3.0-alpha-5
>>
>
> Try running "mvn install" on your example project with Maven 2.x and you'll
> get
>
> [INFO
Stevo Slavić wrote:
It seems 3.0-alpha-5 is not compatible with current 2.0-alpha-4 version of
maven-archetype-plugin - archetype:create-from-project mojo creates
archetype project with packaging maven-archetype, but that packaging seems
not to be supported by / valid for 3.0-alpha-5
Try
1 - 100 of 272 matches
Mail list logo
