You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Joachim Durchholz <jo...@durchholz.org> on 2013/03/02 21:32:04 UTC
Unpacking jars into target/classes
Hi all,
I have two jars from an external source and need to merge their contents
into the target/classes tree until the process-classes phase.
I'm not sure what plugin(s) can be used to achieve this effect.
Directory structure:
- external (directory tree that holds the externally-provided files)
- libs
- cubes.jar (class files)
- cubes-resources.jar (nonclass files)
- license etc. (other data, irrelevant to task at hand)
(yeah I know the structure sucks, can't do anything about it)
- target (maven scratchpad)
- classes (files for main artifact jar are collected here I think)
I need the files inside libs/cubes.jar and libs/cubes-resource.jar
unpacked and placed inside target/classes, preserving the in-jar
directory structure.
I want this to run in the process-classes, latest, because that's the
last pertinent phase that m2e will run.
What's the best (least-hassle) plugin that will do this?
Regards,
Jo
P.S.: Please resist the temptation to tell me that I want the wrong
thing. I need help with solving a problem, I don't need a lecture.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Thank you very much, the effort is truly appreciated.
I didn't consider system scope. Not sure whether that was because I
heard advice against using it or whether I simply overlooked it unter
the wealth of approaches to try.
We have finally decided to try Gradle despite the amount of work
involved, so unfortunately I can't apply that advice right now.
However, if we find that Gradle isn't working for us and come back to
Maven, this is the first thing I'll try.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Laird Nelson <lj...@gmail.com>.
On Sat, Mar 2, 2013 at 12:32 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> I have two jars from an external source and need to merge their contents
> into the target/classes tree until the process-classes phase.
> I'm not sure what plugin(s) can be used to achieve this effect.
>
Offhand I would say you can use the maven-dependency-plugin's unpack goal
(documented here:
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html).
It is perfectly legal to bind the unpack goal to the (say) process-classes
phase twice, with different executions.
So you could do something like this (I'm typing from memory; sure to make
syntax mistakes; hope you get the idea):
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>Unpack the first jar into ${project.build.outputDirectory}</id>
<phase>process-classes</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<!-- here is where the magic happens -->
</configuration>
</execution>
<execution>
<id>Unpack the second jar into ${project.build.outputDirectory}</id>
<phase>process-classes</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<!-- here is where more magic happens -->
</configuration>
</execution>
</executions>
</plugin>
I do something very much like this in my JPA pseudo-archetype (
https://github.com/ljnelson/jpa-archetype/blob/master/pom.xml).
In your case, where you cannot or will not install the artifacts into your
local Maven repository/cache--a totally legitimate state of affairs, I
know; anyone who has worked in a large company has faced this--you would
make sure to declare a dependency in <scope>system</scope>:
<dependency>
<groupId>whatever</groupId>
<artifactId>first-jar-file</artifactId>
<scope>system</scope>
<systemPath>${hopefullySomePropertyHereToMakeYourBuildReproducible}/path/to/first-jar-file.jar</systemPath>
</dependency>
This would be the first dependency unpacked in the stanza I showed above.
I hope this helps you out.
Best,
Laird
--
http://about.me/lairdnelson
RE: Unpacking jars into target/classes
Posted by Martin Gainty <mg...@hotmail.com>.
Joachim- >
> On 7 March 2013 22:27, Joachim Durchholz <jo...@durchholz.org> wrote:
> [del]
> > That's not really what I want.
> > I want a declarative specification so the tool can decide what build steps
> > to run. MG>in other words you want to build out a new lifecycle.xml
> > I want full scripting only for the individual build steps. This probably
> > means an obligation to specify the declarative metadata so the tool can set
> > up its build plan. MG>in other words new lifecycle.xml Plus this probably also means that people will need a way
> > to test whether their metadata are correct, since otherwise people will get
> > subtle errors into the build plans. xml-maven-pluginhttp://mojo.codehaus.org/xml-maven-plugin/validation.html
> >
> > I also want Eclipse integration, so build configuration doesn't need to be
> > specified redundantly.
MG>we should concentrate on getting the mechanics of 1)enforcing the xml is valid with xml-maven-pluginhttp://mojo.codehaus.org/xml-maven-plugin/validation.html 2)Build a CustomMojo to implement altered lifecycle.xml http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html these steps should be completed before any attempt at refactoring as eclipse plugin
>
> If you find such a tool, I'd be interested to hear about it.
> I dont believe such a thing exists.
>
> Which means you are going to have to write it and support it.
>
> You would be much better off taking something that is "close enough"
> and joining in the effort with others to make it better. Whether that
> is Maven or Gradle, or some other thing.
>
MG>Martin
Re: Unpacking jars into target/classes
Posted by Barrie Treloar <ba...@gmail.com>.
On 7 March 2013 22:27, Joachim Durchholz <jo...@durchholz.org> wrote:
[del]
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a way
> to test whether their metadata are correct, since otherwise people will get
> subtle errors into the build plans.
>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
If you find such a tool, I'd be interested to hear about it.
I dont believe such a thing exists.
Which means you are going to have to write it and support it.
You would be much better off taking something that is "close enough"
and joining in the effort with others to make it better. Whether that
is Maven or Gradle, or some other thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Oops
Posted by Joachim Durchholz <jo...@durchholz.org>.
That shouldn't have gone to the list.
Apologies.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Hi Brian,
Let me express a big Thank You; this was a much-needed breath of fresh
air, and I 100% agree with every single sentence in your posting.
This isn't going to change much about the technical issues, but you did
a whole lot to restore my respect for the community that's building and
maintaing Maven.
I wish you all the succes you need.
For what it may be worth :-)
I'll keep out of the (hopefully) ensuing discussion because that might
distract some people.
Should anybody address me directly I'll stay available for answers.
I'll try to stay as neutral as possible in that case, not taking sides
because I don't currently consider myself a part of the user community;
if you want, I can run my answers by you to keep the flamage down.
Regards,
Jo
Am 20.03.2013 15:08, schrieb Brian Fox:
> I haven't had time lately to follow a lot of the user list threads,
> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 19.03.2013 23:40, schrieb Stephen Connolly:
> I don't know what kind of message you got, because it seems that you are
> intent on mis-interpreting everything I write... I wonder what you will
> jump on in this reply!
On nothing at all.
No reasons to.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday, 19 March 2013, Joachim Durchholz wrote:
> Am 19.03.2013 22:20, schrieb Stephen Connolly:
>
>> On Tuesday, 19 March 2013, Joachim Durchholz wrote:
>>
>> Am 19.03.2013 12:13, schrieb Stephen Connolly:
>>>
>>> Jo,
>>>>
>>>> Just for you, I have taken the 30 minutes out of my life and written a
>>>> Maven Plugin that will solve your issues with those pesky non-maven
>>>> dependencies.
>>>>
>>>> https://github.com/stephenc/**non-maven-jar-maven-plugin<https://github.com/stephenc/non-maven-jar-maven-plugin>
>>>>
>>>>
>>> Sorry, but that bold text is a piece of both impudence and arrogance.
>>>
>>> I don't think we have anything to discuss with each other anymore.
>>>
>>>
>>> Pity, you are missing out on the solution you seek.
>>
>
> The solution I seek does not lie with Maven.
> Not anymore anyway; this was the last straw.
>
> I need to put that disclaimer on the project because I am on the Maven PMC
>> and therefore, even though the project is hosted on my GitHub account as
>> opposed to the ASF or the mojo project at codehaus it is necessary to let
>> people who stumble upon the project be aware that it is *not the
>> recommended solution*.
>>
>
> Obviously you think I'm a fool if you think I can't read the subtext in
> the message.
Genuinely, no.
You are entitled to your opinion, but my stated reason of protecting the Mr
A Randomuser from stumbling upon the technique was the *only* reason for
the disclaimer.
> And don't you worry, with that attempt to justify yourself for the
> injustifiable you lost the last shred of respect you held in my eyes.
Well I am not out to gain/lose your respect. I am out to make the commons
better for everyone.
In fact that last phrase sums up "the maven way"
The guiding principle of the maven way is to make life easier for those
that come after.
* Standardised folder layout: makes life easier for those that come after
as it is one less thing to figure out.
* Standardised build life cycle: one less thing again.
* publishing built artifacts to a central repository: make life easier,
anyone around for the madness of 3rd party dependencies before central will
agree on that one
* encapsulate repeated build tasks as plugins: makes life easier, no
reinventing the wheel
Everything about the maven way is about making life easier for those that
come after.
The recommended solution to the problem of 3rd party non-maven jars is to
push them to a maven repository that benefits everyone who comes after.
They just need to declare the dependency and move on.
Alternative "solutions" such as the file:/// repository hack only work for
the project being built and can even not work fully for those projects.
They force everyone to add hacks on top of the hack to get their job done.
The non-maven-jar plugin solution that I implemented can be used with
internal projects to push 3rd party dependencies to an internal repository.
It won't work for pushing to central due to the validation requirements of
pushing to central (requires source.jar and javadoc.jar) so while not the
screaming ugly hack that others use, it has great potential to make life
harder for those that follow. If one does "mvn deploy" with this plugin =>
life is better for those that follow as the dependencies are available
outside the build reactor. If one does "mvn install" with this plugin =>
life is not better for others, but is better for you as the dependencies
are available outside the reactor but only on your machine.
Without doing "mvn deploy" then anyone needing to use your project will
need to checkout your project and build it to get those dependencies, now
chase that tree when you are wanting to use a library that depends on a
projects that depends on a project that depends on your project that
depends on those non-maven jar files... They will be forced to chase and
find the source code for each in turn, hope they have the correct revision
that works, and build... Oops dependency not found, oh another build from
source... Reminds me of all those ANT builds before maven central.
A commons only works if everyone has the principle "I will leave it tidier
than I found it". Good citizens follow that principle, bad citizens don't.
You have already indicated that you don't want to be a citizen of the maven
ecosystem so what should it matter whether you would be a good or bad
citizen of the maven ecosystem when you are not interested in such
citizenship.
I never said "good person" or "bad person" instead "citizen of the maven
ecosystem".
You have said you don't want to create a jira to help document
improvements.., that is not somebody wanting to leave things tidier than
you found it
You have against deploying to a maven repository... Again not making things
tidier.
It is an observable based on your actions that you are not interested in
leaving things tidier, that is not a good citizen of the maven ecosystem in
my book... That is not a value judgement on you as a person, just an
observation of your interaction with the community.
> Just continue as you wish, you have nothing to lose.
>
> You should really add this disclaimer:
> BY PROMOTING "THE MAVEN WAY" YOU AGREE THAT YOU'RE UNWILLING AND/OR UNABLE
> TO UNDERSTAND THE REQUIREMENTS PEOPLE OUTSIDE YOUR SPHERE OF EXPERIENCE
> MIGHT HAVE.
> Irks you?
No
> Doesn't do justice to you?
I fully accept that people outside my sphere of experience have things to
teach me, I've been developing software professionally for over 20 years on
everything from embedded systems through to front-end applications to
computational modelling to telecoms to working on cloud computing
platforms. 95% of the time I find people are working in a sphere I have
good overlap with, but I am always on the look out for signs of others who
have relevant teachings for me
> Applies a yardstick you're not willing to accept as relevant?
Applies a yardstick against which I feel you fall short yourself.
> Fine. Then you know what kind of message I just got.
I don't know what kind of message you got, because it seems that you are
intent on mis-interpreting everything I write... I wonder what you will
jump on in this reply!
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Sent from my phone
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 19.03.2013 22:20, schrieb Stephen Connolly:
> On Tuesday, 19 March 2013, Joachim Durchholz wrote:
>
>> Am 19.03.2013 12:13, schrieb Stephen Connolly:
>>
>>> Jo,
>>>
>>> Just for you, I have taken the 30 minutes out of my life and written a
>>> Maven Plugin that will solve your issues with those pesky non-maven
>>> dependencies.
>>>
>>> https://github.com/stephenc/non-maven-jar-maven-plugin
>>>
>>
>> Sorry, but that bold text is a piece of both impudence and arrogance.
>>
>> I don't think we have anything to discuss with each other anymore.
>>
>>
> Pity, you are missing out on the solution you seek.
The solution I seek does not lie with Maven.
Not anymore anyway; this was the last straw.
> I need to put that disclaimer on the project because I am on the Maven PMC
> and therefore, even though the project is hosted on my GitHub account as
> opposed to the ASF or the mojo project at codehaus it is necessary to let
> people who stumble upon the project be aware that it is *not the
> recommended solution*.
Obviously you think I'm a fool if you think I can't read the subtext in
the message.
And don't you worry, with that attempt to justify yourself for the
injustifiable you lost the last shred of respect you held in my eyes.
Just continue as you wish, you have nothing to lose.
You should really add this disclaimer:
BY PROMOTING "THE MAVEN WAY" YOU AGREE THAT YOU'RE UNWILLING AND/OR
UNABLE TO UNDERSTAND THE REQUIREMENTS PEOPLE OUTSIDE YOUR SPHERE OF
EXPERIENCE MIGHT HAVE.
Irks you? Doesn't do justice to you? Applies a yardstick you're not
willing to accept as relevant?
Fine. Then you know what kind of message I just got.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On Tuesday, 19 March 2013, Joachim Durchholz wrote:
> Am 19.03.2013 12:13, schrieb Stephen Connolly:
>
>> Jo,
>>
>> Just for you, I have taken the 30 minutes out of my life and written a
>> Maven Plugin that will solve your issues with those pesky non-maven
>> dependencies.
>>
>> https://github.com/stephenc/**non-maven-jar-maven-plugin<https://github.com/stephenc/non-maven-jar-maven-plugin>
>>
>
> Sorry, but that bold text is a piece of both impudence and arrogance.
>
> I don't think we have anything to discuss with each other anymore.
>
>
Pity, you are missing out on the solution you seek.
I need to put that disclaimer on the project because I am on the Maven PMC
and therefore, even though the project is hosted on my GitHub account as
opposed to the ASF or the mojo project at codehaus it is necessary to let
people who stumble upon the project be aware that it is *not the
recommended solution*. I have a responsibility both as a committer on the
maven project and as a member of the maven project management committee,
that responsibility ethically requires that I encourage the ways of using
maven that benefit the ecosystem of maven users.
There are some small legitimate use cases for the plugin, hence why I wrote
it and published it on central... But there will be a temptation from the
Mr Random user who spots this login and says "oh look that's by stephenc
and he's on the PMC, so using this must be on the Maven way"... And no that
is not a theory, I've had that happen before with some file:/// based
repository hacks that I employed a couple of years ago... Thankfully
java.net is no longer a code hosting environment, and the source code with
those hacks is long long buried, but it triggered a raft of problems from
people abusing the hack and not understanding the limits of the hack.
This plugin is a more stable hack, but it is still a hack, so it needs a
warning. This is not the first time you have jumped on such a warning and
interpreted it as an insult directed at you. I assure you that is not the
case.
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Sent from my phone
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
Stephen,
I guess they don't have the expression about "biting the hand that feeds
you" where ever he comes from.
It was very kind of you to develop the plug-in for him.
A simple "Thank you" would have been a better response.
Ron
On 19/03/2013 4:57 PM, Joachim Durchholz wrote:
> Am 19.03.2013 12:13, schrieb Stephen Connolly:
>> Jo,
>>
>> Just for you, I have taken the 30 minutes out of my life and written a
>> Maven Plugin that will solve your issues with those pesky non-maven
>> dependencies.
>>
>> https://github.com/stephenc/non-maven-jar-maven-plugin
>
> Sorry, but that bold text is a piece of both impudence and arrogance.
>
> I don't think we have anything to discuss with each other anymore.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 19.03.2013 12:13, schrieb Stephen Connolly:
> Jo,
>
> Just for you, I have taken the 30 minutes out of my life and written a
> Maven Plugin that will solve your issues with those pesky non-maven
> dependencies.
>
> https://github.com/stephenc/non-maven-jar-maven-plugin
Sorry, but that bold text is a piece of both impudence and arrogance.
I don't think we have anything to discuss with each other anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Brian Fox <br...@infinity.nu>.
I haven't had time lately to follow a lot of the user list threads,
but this one got my attention so I read the whole thing last night.
Without having any background on Joachim's previous threads, and
judging everything only based on this one, I was kind of
surprised...not in a good way. If this was my first foray into the
community, I probably wouldn't stay long since it seems quite
passive-aggressively hostile.
What I see is Joachim asking a fair question with constraints that I
personally find overly restrictive but then I don't know all the back
story that produced those constraints. I don't know why our response
needed to go beyond a simple statement like "take a look at
dependency, assembly, shade or truezip plugins since they have the
ability to unpack stuff". Instead it reads like a bunch of preaching
and people convincing him that it's the wrong way. If someone is
receptive to alternate suggestions fine, but this felt forced and then
there was a pig-pile effect of people jumping in.
For what it's worth, my very first plugin (the copy-unpack plugin
which later became the dependency plugin) started with a very similar
use case where I needed to unpack some stuff. I recall having
discussions on IRC about this but they weren't evangelistic, rather
"that's a new use case, you might need to write or modify a plugin,
let us know if you need pointers along the way." That's the community
we should have here, not one that looks like an immune system
attacking a foreign body.
On Wed, Mar 20, 2013 at 2:22 AM, Baptiste MATHUS <ml...@batmat.net> wrote:
> +1 on everything, Manfred.
> And for the record, in case anyone is wondering if that mailing list if
> often like that, please read some other threads...
> I never saw that kind of thing here.
> Le 19 mars 2013 22:54, "Manfred Moser" <ma...@mosabuam.com> a écrit :
>
>> > Am 19.03.2013 14:02, schrieb Stephen Connolly:
>> >> Wayne,
>> >>
>> >> Please open an issue (
>> >> https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull
>> >> requests welcome
>> >
>> > Just for the record: This confirms that you did that in full consent
>> > with both the community and your true inner beliefs.
>> >
>> > I had assumed such behaviour wouldn't be found acceptable in a community
>> > of professionals.
>> > I guess one of these two assumptions was wrong.
>> >
>> > You lost me weeks ago, but you just managed to make me regret every
>> > single minute I have ever spent trying to help you and Maven with
>> > feedback.
>>
>> I am speechless to be honest. Stephen invested some of his valuable time
>> to provide a fix for your problem and this is all you can come up with as
>> a thank you.
>>
>> Can you please do all of us a favor and unsubscribe from the list. I have
>> not seen anything positive come out of your input so far but a lot of
>> trolling and accusations.
>>
>> I for one will stop reading your emails.
>>
>> manfred
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Baptiste MATHUS <ml...@batmat.net>.
+1 on everything, Manfred.
And for the record, in case anyone is wondering if that mailing list if
often like that, please read some other threads...
I never saw that kind of thing here.
Le 19 mars 2013 22:54, "Manfred Moser" <ma...@mosabuam.com> a écrit :
> > Am 19.03.2013 14:02, schrieb Stephen Connolly:
> >> Wayne,
> >>
> >> Please open an issue (
> >> https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull
> >> requests welcome
> >
> > Just for the record: This confirms that you did that in full consent
> > with both the community and your true inner beliefs.
> >
> > I had assumed such behaviour wouldn't be found acceptable in a community
> > of professionals.
> > I guess one of these two assumptions was wrong.
> >
> > You lost me weeks ago, but you just managed to make me regret every
> > single minute I have ever spent trying to help you and Maven with
> > feedback.
>
> I am speechless to be honest. Stephen invested some of his valuable time
> to provide a fix for your problem and this is all you can come up with as
> a thank you.
>
> Can you please do all of us a favor and unsubscribe from the list. I have
> not seen anything positive come out of your input so far but a lot of
> trolling and accusations.
>
> I for one will stop reading your emails.
>
> manfred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Manfred Moser <ma...@mosabuam.com>.
> Am 19.03.2013 14:02, schrieb Stephen Connolly:
>> Wayne,
>>
>> Please open an issue (
>> https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull
>> requests welcome
>
> Just for the record: This confirms that you did that in full consent
> with both the community and your true inner beliefs.
>
> I had assumed such behaviour wouldn't be found acceptable in a community
> of professionals.
> I guess one of these two assumptions was wrong.
>
> You lost me weeks ago, but you just managed to make me regret every
> single minute I have ever spent trying to help you and Maven with
> feedback.
I am speechless to be honest. Stephen invested some of his valuable time
to provide a fix for your problem and this is all you can come up with as
a thank you.
Can you please do all of us a favor and unsubscribe from the list. I have
not seen anything positive come out of your input so far but a lot of
trolling and accusations.
I for one will stop reading your emails.
manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 19.03.2013 14:02, schrieb Stephen Connolly:
> Wayne,
>
> Please open an issue (
> https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull
> requests welcome
Just for the record: This confirms that you did that in full consent
with both the community and your true inner beliefs.
I had assumed such behaviour wouldn't be found acceptable in a community
of professionals.
I guess one of these two assumptions was wrong.
You lost me weeks ago, but you just managed to make me regret every
single minute I have ever spent trying to help you and Maven with feedback.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
Wayne,
Please open an issue (
https://github.com/stephenc/non-maven-jar-maven-plugin/issues). Pull
requests welcome
-Stephen
On 19 March 2013 12:59, Wayne Fay <wa...@gmail.com> wrote:
> > Just for you, I have taken the 30 minutes out of my life and written a
> > Maven Plugin that will solve your issues with those pesky non-maven
> > dependencies.
> >
> > https://github.com/stephenc/non-maven-jar-maven-plugin
>
> Most importantly, does the plugin output this text each time it runs
> "BY USING THIS PLUGIN YOU ACKNOWLEDGE THAT YOU ARE A BAD CITIZEN OF
> THE MAVEN ECOSYSTEM."?
>
> If not, I consider that a defect. ;-)
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Wayne Fay <wa...@gmail.com>.
> Just for you, I have taken the 30 minutes out of my life and written a
> Maven Plugin that will solve your issues with those pesky non-maven
> dependencies.
>
> https://github.com/stephenc/non-maven-jar-maven-plugin
Most importantly, does the plugin output this text each time it runs
"BY USING THIS PLUGIN YOU ACKNOWLEDGE THAT YOU ARE A BAD CITIZEN OF
THE MAVEN ECOSYSTEM."?
If not, I consider that a defect. ;-)
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Mark Derricutt <ma...@talios.com>.
Stephen Connolly wrote:
> Just for you, I have taken the 30 minutes out of my life and written a
> Maven Plugin that will solve your issues with those pesky non-maven
> dependencies.
>
> https://github.com/stephenc/non-maven-jar-maven-plugin
>
> You will need to wait a couple of hours for the sync to central before you
> can use that plugin.
>
Stephen - thank you for this plugin! I was actually struck with a
similar issue last night writing up a sample project to demonstrate
maven to someone elses non-maven project, and started down the file://
repo route and gave up in disgust at myself after having it "not quite
work" with multi-module builds.
This is a simple plugin, but elegantly solves a -temporary- transitional
issue.
Big props to you.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On 18 March 2013 22:52, Stephen Connolly <st...@gmail.com>wrote:
>
>
>
> On 18 March 2013 21:48, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>> Am 18.03.2013 12:45, schrieb Stephen Connolly:
>>
>> I would not base your opinion on this one thread.
>>>
>>> Joachim got off on the wrong foot by mistaking us trying to guide him
>>> towards a path (where he won't fight maven all the way) for us being
>>> evangelical and spouting religious dogma...
>>>
>>
>> Just for the record: I heartily disagree with that view of what happened
>> there.
>> In fact I have reason to believe that such a path doesn't even exist, and
>> in more situations than any Maven proponent would like to admit.
>> Of course, Maven proponents would heartily disagree with that view, and
>> in fact that part of the debate never reached a conclusion (nor will it
>> ever, I think).
>
>
> Well I think there is a path, but let's not re-open that whole thing right
> now.
>
> Perhaps when I revamp the docs you might consider reading them and then
> respond because I believe at that point you might agree that I had a valid
> point and that there is a path... just a path that you don't want to go
> down because your experiences have coloured how you evaluate the set of
> trade-offs that need to be made.
>
>
>>
>>
>> > Some of us in this list may
>>
>>> have egged on the troll vs troll style of this interaction, but the past
>>> is
>>> a foreign country that we cannot visit, personally I think it should be
>>> left behind, fault on both sides, therefore both sides gave some learning
>>> to do.
>>>
>>
>> I can agree with that.
>>
>>
>> I am currently working on trying to find a way to revamp the main maven
>>> site to make it easier for people to get up to speed and grok the reasons
>>> for maven picking the sides it picks as well as grok *where* maven says
>>> "not my problem" (anything after a deployment environment agnostic
>>> artifact
>>> has been delivered into the maven repository is not maven's problem BTW,
>>> use other tools: Chef/Puppet/ANT/Gradle/Buildr/**BASH/etc to turn that
>>> into
>>> an artifact configured for the specific environment it will be deployed
>>> into and put it in that environment)
>>>
>>
>> Good plan.
>>
>> I'd also add a paragraph that Maven is not a toolbox, with the tools to
>> be mixed and matched as a desired workflow mandates. Instead, you're
>> supposed to study the workflows available, select the one that best fits
>> your requirements, and stick with that no matter what. Of course you can
>> configure the workflows, but the extent to which that is possible is
>> strictly controlled.
>>
>
> I think you really should wait for me to revamp the docs before making
> that kind of proposition.
>
> Maven has one primary lifecycle and considers its core responsibility to
> be delivering artifacts that are target agnostic into the maven repository.
> What you can do in that lifecycle is very mix and match and a lot more
> flexible than you would suspect, but after the end of that lifecycle you
> should not be using Maven.
>
> Handling the mix and match most likely will involve writing either
> extensions (unlikely) or plugins (most likely) which will need to be pushed
> to a Maven repository...
>
> If you don't have an internal Maven repository manager to host such
> things, or if you cannot push those plugins/extensions to central, then you
> might not realize how flexible Maven is in this respect
>
>
>>
>> I consider that approach to be a core mistake in Maven's, but I can agree
>> to disagree about that one and move on, in the knowledge that little could
>> be done about it even if it's true so there's little to be gained in
>> discussing that.
>
>
>> What we probably can agree on is that (a) the workflows are implicit in
>> what's available in the plugins and what isn't, which makes it hard to get
>> an overview of the available workflows and select the right one;
>
>
> There is 1 primary lifecycle: initialize -> ... -> compile -> ... -> test
> -> ... -> package -> ... -> verify -> install -> deploy
>
> There are different packagings: jar/war/ear/etc
>
> I am guessing that you are referring to these as workflows.
>
> Defining custom packaging is actually quite trivial, just an XML file in a
> .jar that you add as a build extension (or include in a maven plugin). You
> can do quite a lot with that.
>
> The Maven project can only document our packagings and their lifecycles:
> pom/jar/war/ear/rar/ejb-jar
>
> We cannot be responsible for documenting other people's lifecycles. For
> example (and I am pointing now at a personal project) the
> jszip-maven-plugin defines its own lifecycle:
> https://github.com/jszip/jszip-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xmlThe documentation of that lifecycle is not the responsibility of the Maven
> project (or the ASF unless/until I seek to move that project into the ASF,
> but that is a separate story).
>
> I agree that it can be hard to decide what packaging type to pick for your
> use case when there are multiple similar ones, e.g. webjars is solving a
> similar problem to jszip so if you are packaging up javascript "modules"
> for consumption by Maven projects which should you choose? That is a hard
> problem.
>
> But if you are building a .jar file then you really just have three
> choices:
> 1. <packaging>jar</packaging> (if you don't give a rats arse about
> OSGi);
> 2. <packaging>bundle</packaging> (if you need OSGi)
> 3. your own custom lifecycle if one of the above does not fit your needs.
>
> But of course the problem that kicked this whole thread off has a simple
> solution, one that I mentioned quite some time ago, but I think you
> ignored. Namely making proxy modules for each of the 3rd party jars that
> you have to consume. They are just a pom.xml in a directory and they attach
> the jar you are getting from the file system into the reactor in place of
> the jar produced by jar:jar... they look a little something like this:
>
> <?xml version="1.0" encoding="utf-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> <modelVersion>4.0.0</modelVersion>
>
> <groupId>com.foo.bar</groupId>
> <artifactId>manchu</artifactId>
> <version>1-SNAPSHOT</version>
> <packaging>jar</packaging>
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.7</version>
> <executions>
> <execution>
> <id>attach-artifacts</id>
> <phase>package</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <target>
> <copy file="foobar.jar"
> tofile="${project.build.directory}/${project.build.finalName}.jar"
> overwrite="true"/>
> </target>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
> </project>
>
>
> You have one of those for each non maven artifact and you just ensure that
> the correct dependencies are listed and that these pom files are referenced
> in the root aggregator pom and presto-chango there is your build. AFAIR I
> even suggested this when you first came to the list. It's a little hacky...
> you could do better with a custom lifecycle and your own plugin, but mostly
> around removing some boilerplate and simplification of the pom... but that
> would require pushing the maven plugin to a MRM (or central) and off we go
> again!
>
Jo,
Just for you, I have taken the 30 minutes out of my life and written a
Maven Plugin that will solve your issues with those pesky non-maven
dependencies.
https://github.com/stephenc/non-maven-jar-maven-plugin
You will need to wait a couple of hours for the sync to central before you
can use that plugin.
But it is designed for your exact use-case (adapted to the Maven way of
course ;-) )
-Stephen
>
>
>> and (b) the problem is massively worsened if plugin descriptions are
>> vague or incomplete, and that this has in fact grown to be a real problem.
>>
>
> Well docs are a problem, and then the slew of poorly written plugins (99%
> of the org.apache.maven.plugins and org.codehaus.mojo plugins are not in
> this category) with no documentation that don't follow the Maven principles
> (and instead just blindly rely on defaults) which make it harder to deviate
> from some aspects of the Maven way when it is needed.
>
>
>> Which is why I wholeheartedly agree that Maven could profit from better
>> docs. Even if I disagree about what it should do ;-)
>>
>> Regards,
>> Jo
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On 18 March 2013 21:48, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 18.03.2013 12:45, schrieb Stephen Connolly:
>
> I would not base your opinion on this one thread.
>>
>> Joachim got off on the wrong foot by mistaking us trying to guide him
>> towards a path (where he won't fight maven all the way) for us being
>> evangelical and spouting religious dogma...
>>
>
> Just for the record: I heartily disagree with that view of what happened
> there.
> In fact I have reason to believe that such a path doesn't even exist, and
> in more situations than any Maven proponent would like to admit.
> Of course, Maven proponents would heartily disagree with that view, and in
> fact that part of the debate never reached a conclusion (nor will it ever,
> I think).
Well I think there is a path, but let's not re-open that whole thing right
now.
Perhaps when I revamp the docs you might consider reading them and then
respond because I believe at that point you might agree that I had a valid
point and that there is a path... just a path that you don't want to go
down because your experiences have coloured how you evaluate the set of
trade-offs that need to be made.
>
>
> > Some of us in this list may
>
>> have egged on the troll vs troll style of this interaction, but the past
>> is
>> a foreign country that we cannot visit, personally I think it should be
>> left behind, fault on both sides, therefore both sides gave some learning
>> to do.
>>
>
> I can agree with that.
>
>
> I am currently working on trying to find a way to revamp the main maven
>> site to make it easier for people to get up to speed and grok the reasons
>> for maven picking the sides it picks as well as grok *where* maven says
>> "not my problem" (anything after a deployment environment agnostic
>> artifact
>> has been delivered into the maven repository is not maven's problem BTW,
>> use other tools: Chef/Puppet/ANT/Gradle/Buildr/**BASH/etc to turn that
>> into
>> an artifact configured for the specific environment it will be deployed
>> into and put it in that environment)
>>
>
> Good plan.
>
> I'd also add a paragraph that Maven is not a toolbox, with the tools to be
> mixed and matched as a desired workflow mandates. Instead, you're supposed
> to study the workflows available, select the one that best fits your
> requirements, and stick with that no matter what. Of course you can
> configure the workflows, but the extent to which that is possible is
> strictly controlled.
>
I think you really should wait for me to revamp the docs before making that
kind of proposition.
Maven has one primary lifecycle and considers its core responsibility to be
delivering artifacts that are target agnostic into the maven repository.
What you can do in that lifecycle is very mix and match and a lot more
flexible than you would suspect, but after the end of that lifecycle you
should not be using Maven.
Handling the mix and match most likely will involve writing either
extensions (unlikely) or plugins (most likely) which will need to be pushed
to a Maven repository...
If you don't have an internal Maven repository manager to host such things,
or if you cannot push those plugins/extensions to central, then you might
not realize how flexible Maven is in this respect
>
> I consider that approach to be a core mistake in Maven's, but I can agree
> to disagree about that one and move on, in the knowledge that little could
> be done about it even if it's true so there's little to be gained in
> discussing that.
> What we probably can agree on is that (a) the workflows are implicit in
> what's available in the plugins and what isn't, which makes it hard to get
> an overview of the available workflows and select the right one;
There is 1 primary lifecycle: initialize -> ... -> compile -> ... -> test
-> ... -> package -> ... -> verify -> install -> deploy
There are different packagings: jar/war/ear/etc
I am guessing that you are referring to these as workflows.
Defining custom packaging is actually quite trivial, just an XML file in a
.jar that you add as a build extension (or include in a maven plugin). You
can do quite a lot with that.
The Maven project can only document our packagings and their lifecycles:
pom/jar/war/ear/rar/ejb-jar
We cannot be responsible for documenting other people's lifecycles. For
example (and I am pointing now at a personal project) the
jszip-maven-plugin defines its own lifecycle:
https://github.com/jszip/jszip-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xmlThe
documentation of that lifecycle is not the responsibility of the Maven
project (or the ASF unless/until I seek to move that project into the ASF,
but that is a separate story).
I agree that it can be hard to decide what packaging type to pick for your
use case when there are multiple similar ones, e.g. webjars is solving a
similar problem to jszip so if you are packaging up javascript "modules"
for consumption by Maven projects which should you choose? That is a hard
problem.
But if you are building a .jar file then you really just have three
choices:
1. <packaging>jar</packaging> (if you don't give a rats arse about OSGi);
2. <packaging>bundle</packaging> (if you need OSGi)
3. your own custom lifecycle if one of the above does not fit your needs.
But of course the problem that kicked this whole thread off has a simple
solution, one that I mentioned quite some time ago, but I think you
ignored. Namely making proxy modules for each of the 3rd party jars that
you have to consume. They are just a pom.xml in a directory and they attach
the jar you are getting from the file system into the reactor in place of
the jar produced by jar:jar... they look a little something like this:
<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo.bar</groupId>
<artifactId>manchu</artifactId>
<version>1-SNAPSHOT</version>
<packaging>jar</packaging>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<copy file="foobar.jar"
tofile="${project.build.directory}/${project.build.finalName}.jar"
overwrite="true"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
You have one of those for each non maven artifact and you just ensure that
the correct dependencies are listed and that these pom files are referenced
in the root aggregator pom and presto-chango there is your build. AFAIR I
even suggested this when you first came to the list. It's a little hacky...
you could do better with a custom lifecycle and your own plugin, but mostly
around removing some boilerplate and simplification of the pom... but that
would require pushing the maven plugin to a MRM (or central) and off we go
again!
> and (b) the problem is massively worsened if plugin descriptions are vague
> or incomplete, and that this has in fact grown to be a real problem.
>
Well docs are a problem, and then the slew of poorly written plugins (99%
of the org.apache.maven.plugins and org.codehaus.mojo plugins are not in
this category) with no documentation that don't follow the Maven principles
(and instead just blindly rely on defaults) which make it harder to deviate
from some aspects of the Maven way when it is needed.
> Which is why I wholeheartedly agree that Maven could profit from better
> docs. Even if I disagree about what it should do ;-)
>
> Regards,
> Jo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 18.03.2013 12:45, schrieb Stephen Connolly:
> I would not base your opinion on this one thread.
>
> Joachim got off on the wrong foot by mistaking us trying to guide him
> towards a path (where he won't fight maven all the way) for us being
> evangelical and spouting religious dogma...
Just for the record: I heartily disagree with that view of what happened
there.
In fact I have reason to believe that such a path doesn't even exist,
and in more situations than any Maven proponent would like to admit.
Of course, Maven proponents would heartily disagree with that view, and
in fact that part of the debate never reached a conclusion (nor will it
ever, I think).
> Some of us in this list may
> have egged on the troll vs troll style of this interaction, but the past is
> a foreign country that we cannot visit, personally I think it should be
> left behind, fault on both sides, therefore both sides gave some learning
> to do.
I can agree with that.
> I am currently working on trying to find a way to revamp the main maven
> site to make it easier for people to get up to speed and grok the reasons
> for maven picking the sides it picks as well as grok *where* maven says
> "not my problem" (anything after a deployment environment agnostic artifact
> has been delivered into the maven repository is not maven's problem BTW,
> use other tools: Chef/Puppet/ANT/Gradle/Buildr/BASH/etc to turn that into
> an artifact configured for the specific environment it will be deployed
> into and put it in that environment)
Good plan.
I'd also add a paragraph that Maven is not a toolbox, with the tools to
be mixed and matched as a desired workflow mandates. Instead, you're
supposed to study the workflows available, select the one that best fits
your requirements, and stick with that no matter what. Of course you can
configure the workflows, but the extent to which that is possible is
strictly controlled.
I consider that approach to be a core mistake in Maven's, but I can
agree to disagree about that one and move on, in the knowledge that
little could be done about it even if it's true so there's little to be
gained in discussing that.
What we probably can agree on is that (a) the workflows are implicit in
what's available in the plugins and what isn't, which makes it hard to
get an overview of the available workflows and select the right one; and
(b) the problem is massively worsened if plugin descriptions are vague
or incomplete, and that this has in fact grown to be a real problem.
Which is why I wholeheartedly agree that Maven could profit from better
docs. Even if I disagree about what it should do ;-)
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
I would not base your opinion on this one thread.
Joachim got off on the wrong foot by mistaking us trying to guide him
towards a path (where he won't fight maven all the way) for us being
evangelical and spouting religious dogma... Some of us in this list may
have egged on the troll vs troll style of this interaction, but the past is
a foreign country that we cannot visit, personally I think it should be
left behind, fault on both sides, therefore both sides gave some learning
to do.
The reality of Maven is it is an/the *opinionated* build tool. If you don't
like its opinions, don't use it.
Many find its opinions non-offensive, and are happy to put up with the ways
of working those opinions mandate.
Those if us here for a long time find its opinions the "dogs bollix" and
think they are the best way (usually as a result of lots of experience with
other ways which guided us back to the way maven directs... But others can
and do have other experiences that lead them away from maven's direction so
I am not saying that the maven way is "best", rather that I think it is the
way I think is best)
Some other people really don't like some of maven's core principles (I am
not one of those people, I suggest asking them for their reasons, I refuse
to speculate further than "they may not understand fully the reasons for
maven picking specific sides of some trade-offs" but I could be wrong, I am
biased in agreeing with the maven side of those trade-offs) these people
either fight maven all the way (ahem kohsuke my esteemed
colleague/friend shows symptoms if being such a fighter) or give up and run
away
I am currently working on trying to find a way to revamp the main maven
site to make it easier for people to get up to speed and grok the reasons
for maven picking the sides it picks as well as grok *where* maven says
"not my problem" (anything after a deployment environment agnostic artifact
has been delivered into the maven repository is not maven's problem BTW,
use other tools: Chef/Puppet/ANT/Gradle/Buildr/BASH/etc to turn that into
an artifact configured for the specific environment it will be deployed
into and put it in that environment)
-Stephen
On Monday, 18 March 2013, Kevin Krumwiede wrote:
> "Leave it" seems to be the option most often chosen. Having just
> joined this mailing list, I'm beginning to suspect why.
>
> On 3/17/13, Joachim Durchholz <jo@durchholz.org <javascript:;>> wrote:
> > Am 18.03.2013 07:43, schrieb Anders Hammar:
> >> Joachim, you're way out of line here! Please do a background check on my
> >> contribution to this project before you insult me!
> >
> > Anders, your contributions to Maven were never part of this discussion.
> >
> > Except if you base your demands on how your contributions are so much
> > more than mine.
> >
> > Which would be an invalid argument. Maven, like all the other FOSS
> > projects, is published on a "take it or leave it" basis. In fact the
> > "leave it" option has been on the table for quite a while.
> > If find it strange that if I give information on a "take it or leave it"
> > basis, you guys find that offensive and not enough due diligence.
> >
> > Listen that Youtube link again, please...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org<javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
--
Sent from my phone
Re: Unpacking jars into target/classes
Posted by Kevin Krumwiede <kj...@gmail.com>.
"Leave it" seems to be the option most often chosen. Having just
joined this mailing list, I'm beginning to suspect why.
On 3/17/13, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 18.03.2013 07:43, schrieb Anders Hammar:
>> Joachim, you're way out of line here! Please do a background check on my
>> contribution to this project before you insult me!
>
> Anders, your contributions to Maven were never part of this discussion.
>
> Except if you base your demands on how your contributions are so much
> more than mine.
>
> Which would be an invalid argument. Maven, like all the other FOSS
> projects, is published on a "take it or leave it" basis. In fact the
> "leave it" option has been on the table for quite a while.
> If find it strange that if I give information on a "take it or leave it"
> basis, you guys find that offensive and not enough due diligence.
>
> Listen that Youtube link again, please...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 18.03.2013 07:43, schrieb Anders Hammar:
> Joachim, you're way out of line here! Please do a background check on my
> contribution to this project before you insult me!
Anders, your contributions to Maven were never part of this discussion.
Except if you base your demands on how your contributions are so much
more than mine.
Which would be an invalid argument. Maven, like all the other FOSS
projects, is published on a "take it or leave it" basis. In fact the
"leave it" option has been on the table for quite a while.
If find it strange that if I give information on a "take it or leave it"
basis, you guys find that offensive and not enough due diligence.
Listen that Youtube link again, please...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Anders Hammar <an...@hammar.net>.
Joachim, you're way out of line here! Please do a background check on my
contribution to this project before you insult me!
On Mon, Mar 18, 2013 at 7:04 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 17.03.2013 18:22, schrieb Jeff MAURY:
>
>> Impress to see that you're claiming you personal priorities prevent you to
>> open a ticket on JIRA but allow you to write a mail including external
>> links !!!!
>>
>
> The same question could go to Anders...
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 17.03.2013 18:22, schrieb Jeff MAURY:
> Impress to see that you're claiming you personal priorities prevent you to
> open a ticket on JIRA but allow you to write a mail including external
> links !!!!
The same question could go to Anders...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Jeff MAURY <je...@jeffmaury.com>.
Impress to see that you're claiming you personal priorities prevent you to
open a ticket on JIRA but allow you to write a mail including external
links !!!!
Stay focused
Jeff
On Sun, Mar 17, 2013 at 5:30 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 16.03.2013 11:54, schrieb Anders Hammar:
>
> Jira would be an option, but unfortunately, my time is limited and I'll
>>> leave that to people who are already registered and know how to split up
>>> a
>>> report into meaningful, addressable chunks and file them under the right
>>> section.
>>>
>>
>> I'm sorry Joachim, but I find that statement very offensive! Do you think
>> that other people's time is less valuable and that we don't have limited
>> time?
>>
>
> You forgot the other part of the statement: People who have more
> experience with the Maven Jira would have to spend less of their time.
>
> Also, there's personal priorities. In fact you're just now trying to
> dictate my priorities by indicating that not adding a report to Jira is
> offensive to you.
>
> If you feel offended by that, you should probably readjust something.
>
>
> > A lot of people here has put in time answering your questions,
>
> Not to mention the abuse, evangelization, useless distractions, &cetera.
>
> So you're also trying a guilt trip on me...
>
>
> > but
>
>> you can't find some time to help improve the docs with the info that you
>> think is missing?
>>
>
> Actually, there's also lack of interest.
> However, explaining the details behind that would indeed be offensive and
> (FAR more importantly) just reiterate well-known issues so I wouldn't help
> anybody with that.
> That's why I deleted that paragraph from my message.
>
>
> > It will help the next person (which could have been you
>
>> if someone before you had done this).
>>
>
> Sorry, not buying that.
>
>
> To me open source software is about everyone helping out.
>>
>
> Sure. Go over to SymPy and help out there, that's a project that I have
> contributed to.
> Not your interest? How dare you!!!
> ;-P
>
>
> > The very least I
>
>> expect is for people to file tickets about bugs and improvements they
>> find.
>> No one can do everything, but everyone can do something!
>>
>
> Let me say it with Anastacia:
> https://www.youtube.com/watch?**v=rsryGFw_H4M<https://www.youtube.com/watch?v=rsryGFw_H4M>
>
> Somehow this list seems to be harboring a lot of people who like to tell
> me what to think, what to be grateful for, what the best structure for my
> project should be, and whom to acknowledge as ethically and technically
> superior.
> If find that... funny. Sort of.
> And patronizing.
>
> Regards,
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Re: Unpacking jars into target/classes
Posted by Barrie Treloar <ba...@gmail.com>.
On 18 March 2013 03:00, Joachim Durchholz <jo...@durchholz.org> wrote:
>> you can't find some time to help improve the docs with the info that you
>> think is missing?
>
>
> Actually, there's also lack of interest.
You've already said you are stuck with Maven.
Which means it is in your best interest to get Maven working correctly.
You can't have it both ways. You can't bitch and moan and then do
nothing to help fix the problem.
Well you can. But that just earns you troll status and you get ignored.
You can choose which option you want.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 16.03.2013 11:54, schrieb Anders Hammar:
>> Jira would be an option, but unfortunately, my time is limited and I'll
>> leave that to people who are already registered and know how to split up a
>> report into meaningful, addressable chunks and file them under the right
>> section.
>
> I'm sorry Joachim, but I find that statement very offensive! Do you think
> that other people's time is less valuable and that we don't have limited
> time?
You forgot the other part of the statement: People who have more
experience with the Maven Jira would have to spend less of their time.
Also, there's personal priorities. In fact you're just now trying to
dictate my priorities by indicating that not adding a report to Jira is
offensive to you.
If you feel offended by that, you should probably readjust something.
> A lot of people here has put in time answering your questions,
Not to mention the abuse, evangelization, useless distractions, &cetera.
So you're also trying a guilt trip on me...
> but
> you can't find some time to help improve the docs with the info that you
> think is missing?
Actually, there's also lack of interest.
However, explaining the details behind that would indeed be offensive
and (FAR more importantly) just reiterate well-known issues so I
wouldn't help anybody with that.
That's why I deleted that paragraph from my message.
> It will help the next person (which could have been you
> if someone before you had done this).
Sorry, not buying that.
> To me open source software is about everyone helping out.
Sure. Go over to SymPy and help out there, that's a project that I have
contributed to.
Not your interest? How dare you!!!
;-P
> The very least I
> expect is for people to file tickets about bugs and improvements they find.
> No one can do everything, but everyone can do something!
Let me say it with Anastacia:
https://www.youtube.com/watch?v=rsryGFw_H4M
Somehow this list seems to be harboring a lot of people who like to tell
me what to think, what to be grateful for, what the best structure for
my project should be, and whom to acknowledge as ethically and
technically superior.
If find that... funny. Sort of.
And patronizing.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Baptiste MATHUS <ml...@batmat.net>.
+1000, Anders.
I was previously about to answer in the same style, but then refrained
myself...
The dark side of the story with OSS...
Cheers
Le 16 mars 2013 12:07, "Anders Hammar" <an...@hammar.net> a écrit :
> > Jira would be an option, but unfortunately, my time is limited and I'll
> > leave that to people who are already registered and know how to split up
> a
> > report into meaningful, addressable chunks and file them under the right
> > section.
> >
>
> I'm sorry Joachim, but I find that statement very offensive! Do you think
> that other people's time is less valuable and that we don't have limited
> time? A lot of people here has put in time answering your questions, but
> you can't find some time to help improve the docs with the info that you
> think is missing? It will help the next person (which could have been you
> if someone before you had done this).
> To me open source software is about everyone helping out. The very least I
> expect is for people to file tickets about bugs and improvements they find.
> No one can do everything, but everyone can do something!
>
> /Anders
>
>
> >
> > Regards,
> > Jo
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Unpacking jars into target/classes
Posted by Anders Hammar <an...@hammar.net>.
> Jira would be an option, but unfortunately, my time is limited and I'll
> leave that to people who are already registered and know how to split up a
> report into meaningful, addressable chunks and file them under the right
> section.
>
I'm sorry Joachim, but I find that statement very offensive! Do you think
that other people's time is less valuable and that we don't have limited
time? A lot of people here has put in time answering your questions, but
you can't find some time to help improve the docs with the info that you
think is missing? It will help the next person (which could have been you
if someone before you had done this).
To me open source software is about everyone helping out. The very least I
expect is for people to file tickets about bugs and improvements they find.
No one can do everything, but everyone can do something!
/Anders
>
> Regards,
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 15.03.2013 02:16, schrieb Barrie Treloar:
> On 7 March 2013 23:24, Joachim Durchholz <jo...@durchholz.org> wrote:
>> It's never a bad idea to improve the docs, but the real problem is the
>> plugin docs. Many options are "documented" along the lines of "frob: frobs
>> the build", which isn't very helpful. Few if any plugins clearly document
>> the use cases they are built for, or (almost more importantly) the use cases
>> that will not work. Of course, lifting the restrictions would be even more
>> helpful than documenting them :-)
>
> Have you considered enhancing the documentation?
I'd need the information that's not in the documentation to do that.
What I can do is point out where the documentation is missing.
In fact I have done so, multiple times, and I have a vague impression
that people have been listening to that.
Jira would be an option, but unfortunately, my time is limited and I'll
leave that to people who are already registered and know how to split up
a report into meaningful, addressable chunks and file them under the
right section.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 15/03/2013 3:48 AM, Anders Hammar wrote:
> Well, actually I think that people being new to a tool could be the
> best contributors. Those being experts (at least engineers) very often
> forget to explain some of the basics, which rookies really need
> explained. So if you don't understand, figure it out (ask questions
> etc) and then look at the text/docs again and add what's missing. If
> you don't do it, who will?
>
I don't mind contributing by editing stuff or writing wildly inaccurate
impressions about what something does but I will only do it in
conjunction with the author or someone who is working on the code and
will correct my errors and provide explanations where the function is
obscure or the arguments have mysterious names or are missing.
I am not going to reverse engineer something.
I simply do not have the time to read code in a chunk of software that,
for me, is only a tool.
I am also usually passing through.
Once I get it working for me, I may never return to the project.
We use hundreds of open source libraries and utilities.
Ron
> So, file those improvement tickets with patches (could be as simple as
> stating the additional text in the ticket, it doesn't have to be a
> patch file). Anyone can contribute!
>
> /Anders
>
>
> On Fri, Mar 15, 2013 at 2:44 AM, Ron Wheeler
> <rwheeler@artifact-software.com
> <ma...@artifact-software.com>> wrote:
>
> How do you write documentation for something that you have never
> used and have no idea what the options are?
>
> I have worked on documentation for some projects but I can only go
> so far without the active involvement of the author.
> The biggest thing that I can bring is my ignorance which makes me
> read what is there and ask good questions about WTF does it mean
> and what needs to be said so that someone who did not write it can
> use it.
> It does require access to someone who can answer those questions.
>
>
> Ron
>
>
> On 14/03/2013 9:16 PM, Barrie Treloar wrote:
>
> On 7 March 2013 23:24, Joachim Durchholz <jo@durchholz.org
> <ma...@durchholz.org>> wrote:
>
> It's never a bad idea to improve the docs, but the real
> problem is the
> plugin docs. Many options are "documented" along the lines
> of "frob: frobs
> the build", which isn't very helpful. Few if any plugins
> clearly document
> the use cases they are built for, or (almost more
> importantly) the use cases
> that will not work. Of course, lifting the restrictions
> would be even more
> helpful than documenting them :-)
>
> Have you considered enhancing the documentation?
>
> If you are stuck with the tool you might as well help yourself
> in the
> future when you get frustrated, a side benefit is that this
> also helps
> others.
>
> You are also welcome to file jira's with patches and unit tests to
> remove those restrictions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: Unpacking jars into target/classes
Posted by Anders Hammar <an...@hammar.net>.
Well, actually I think that people being new to a tool could be the best
contributors. Those being experts (at least engineers) very often forget to
explain some of the basics, which rookies really need explained. So if you
don't understand, figure it out (ask questions etc) and then look at the
text/docs again and add what's missing. If you don't do it, who will?
So, file those improvement tickets with patches (could be as simple as
stating the additional text in the ticket, it doesn't have to be a patch
file). Anyone can contribute!
/Anders
On Fri, Mar 15, 2013 at 2:44 AM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:
> How do you write documentation for something that you have never used and
> have no idea what the options are?
>
> I have worked on documentation for some projects but I can only go so far
> without the active involvement of the author.
> The biggest thing that I can bring is my ignorance which makes me read
> what is there and ask good questions about WTF does it mean and what needs
> to be said so that someone who did not write it can use it.
> It does require access to someone who can answer those questions.
>
>
> Ron
>
>
> On 14/03/2013 9:16 PM, Barrie Treloar wrote:
>
>> On 7 March 2013 23:24, Joachim Durchholz <jo...@durchholz.org> wrote:
>>
>>> It's never a bad idea to improve the docs, but the real problem is the
>>> plugin docs. Many options are "documented" along the lines of "frob:
>>> frobs
>>> the build", which isn't very helpful. Few if any plugins clearly document
>>> the use cases they are built for, or (almost more importantly) the use
>>> cases
>>> that will not work. Of course, lifting the restrictions would be even
>>> more
>>> helpful than documenting them :-)
>>>
>> Have you considered enhancing the documentation?
>>
>> If you are stuck with the tool you might as well help yourself in the
>> future when you get frustrated, a side benefit is that this also helps
>> others.
>>
>> You are also welcome to file jira's with patches and unit tests to
>> remove those restrictions.
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Thu, Mar 14, 2013 at 09:44:14PM -0400, Ron Wheeler wrote:
> How do you write documentation for something that you have never used
> and have no idea what the options are?
Exactly!
You grumble a bit, pull down the source, and start reading. This is
horrible and exhausting and often underappreciated, but it's the only
thing that works, it the author won't share his thoughts.
> I have worked on documentation for some projects but I can only go so
> far without the active involvement of the author.
> The biggest thing that I can bring is my ignorance which makes me read
> what is there and ask good questions about WTF does it mean and what
> needs to be said so that someone who did not write it can use it.
> It does require access to someone who can answer those questions.
Hear, hear. I'm sure that a large part of technical writing is spent
interviewing (not to mention identifying, finding, chasing and
hounding) the people who know that which must be written down.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
There's an app for that: your browser
Re: Unpacking jars into target/classes
Posted by Barrie Treloar <ba...@gmail.com>.
On 15 March 2013 12:14, Ron Wheeler <rw...@artifact-software.com> wrote:
> How do you write documentation for something that you have never used and
> have no idea what the options are?
>
> I have worked on documentation for some projects but I can only go so far
> without the active involvement of the author.
> The biggest thing that I can bring is my ignorance which makes me read what
> is there and ask good questions about WTF does it mean and what needs to be
> said so that someone who did not write it can use it.
> It does require access to someone who can answer those questions.
The same way I started.
Google, User List archives - a lot of the information is already
present, its just not in the documentation.
You can then download the source code and read it to reverse engineer
the problem.
You can attempt to find other projects using that plugin and the
option you think is the one you want and study what they are doing.
Eventually, if you are persistent, and you have solved your particular
problem it would make sense to write up your findings and get them
included in the documentation.
That way you benefit the next time you forget how to do something (I
know I have) and so does everyone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
How do you write documentation for something that you have never used
and have no idea what the options are?
I have worked on documentation for some projects but I can only go so
far without the active involvement of the author.
The biggest thing that I can bring is my ignorance which makes me read
what is there and ask good questions about WTF does it mean and what
needs to be said so that someone who did not write it can use it.
It does require access to someone who can answer those questions.
Ron
On 14/03/2013 9:16 PM, Barrie Treloar wrote:
> On 7 March 2013 23:24, Joachim Durchholz <jo...@durchholz.org> wrote:
>> It's never a bad idea to improve the docs, but the real problem is the
>> plugin docs. Many options are "documented" along the lines of "frob: frobs
>> the build", which isn't very helpful. Few if any plugins clearly document
>> the use cases they are built for, or (almost more importantly) the use cases
>> that will not work. Of course, lifting the restrictions would be even more
>> helpful than documenting them :-)
> Have you considered enhancing the documentation?
>
> If you are stuck with the tool you might as well help yourself in the
> future when you get frustrated, a side benefit is that this also helps
> others.
>
> You are also welcome to file jira's with patches and unit tests to
> remove those restrictions.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Barrie Treloar <ba...@gmail.com>.
On 7 March 2013 23:24, Joachim Durchholz <jo...@durchholz.org> wrote:
> It's never a bad idea to improve the docs, but the real problem is the
> plugin docs. Many options are "documented" along the lines of "frob: frobs
> the build", which isn't very helpful. Few if any plugins clearly document
> the use cases they are built for, or (almost more importantly) the use cases
> that will not work. Of course, lifting the restrictions would be even more
> helpful than documenting them :-)
Have you considered enhancing the documentation?
If you are stuck with the tool you might as well help yourself in the
future when you get frustrated, a side benefit is that this also helps
others.
You are also welcome to file jira's with patches and unit tests to
remove those restrictions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Just some feedback...
Am 07.03.2013 13:22, schrieb Stephen Connolly:
> Maven wants the java source code in ${basedir}/src/main/java... you want it
> somewhere else... you know what, Maven is OK with that
I'm actually okay with that source structure, though I don't like the
split between .../java/... and .../resources/..., it's ripping apart
stuff that will live side-by-side in the jar.
But... meh, I can adapt and I can see the reasons why one would want to
keep the directories apart, It's ultimately a judgement call.
> Maven wants to build the dependency tree before it finalizes a build plan
> that will include plugin executions that require resolving the dependency
> tree in order to ensure that the transitive dependency tree does not
> reorder the build-plan...
Which is a good thing in my book (and why I'm aghast when I see people
building plugins during normal build).
> you don't want to use a maven repository manager
> or run a separate script to install the 3rd party dependencies into the
> local repository cache... that one is a deal breaker for Maven... the
> question is I have for you is: can you live with Maven's restrictions? This
> is something that Maven will not compromise on... the ball is in your court.
Well, I have to compromise on that if Maven won't budge, right?
Dropping Maven will ultimately be what I'm forced into, but I can't
switch right now.
> I am trying to come up with a better user facing documentation for the core
> of Maven itself...
It's never a bad idea to improve the docs, but the real problem is the
plugin docs. Many options are "documented" along the lines of "frob:
frobs the build", which isn't very helpful. Few if any plugins clearly
document the use cases they are built for, or (almost more importantly)
the use cases that will not work. Of course, lifting the restrictions
would be even more helpful than documenting them :-)
> my aim being to let people know that Maven is
> OPINIONATED, that it's ok to disagree on some of those opinions, but that
> some things are core opinions and if you disagree with those core opinions,
> please don't use Maven.
These opinions need to be spelled out if people are to make an informed
decision whether Maven is for them. The problem is that it's hard to
spell everything out since it's so easy to have implied assumptions even
without being aware of them. Plus, it's hard to spell everything out
without getting lost in detail.
Also, such opinions need to be presented in a fashion that shows where
there's room for reasonable disagreement. If opinions are presented as
"that's the only reasonable alternative", people will assume that all
the doubts they might harbor will eventually dissolve.
Maven is less prone to that problem than, say, Hibernate. Gavin has been
promoting a single transactional model as the only reasonable one, which
is okay for those programs that happen to live well with it but simply
can't be made to work for all situations. It's a nasty kind of
misrepresentation because it's to easy to fall to it, both for the
author and for the reader.
Just listing that as a point to consider when laying out the arguments.
>> That's not really what I want.
>> I want a declarative specification so the tool can decide what build steps
>> to run.
>> I want full scripting only for the individual build steps. This probably
>> means an obligation to specify the declarative metadata so the tool can set
>> up its build plan. Plus this probably also means that people will need a
>> way to test whether their metadata are correct, since otherwise people will
>> get subtle errors into the build plans.
>
> You don't want Maven... if you are not prepared to compromise on the above,
Ah, I was just on a tangent how an ideal build system should be done,
IMNSHO.
I'm very aware that Maven isn't it :-)
> then (and please don't take this the wrong way) stop using Maven.
No offense taken. I'm already on my way out, it's just that switching
build tools in general is a high-effort high-risk endeavour.
> Do you want a pony too? ;-)
In pink, preferrably ;-)
>> I'm not sure whether Gradle fits the bill. Given the complexities
>> involved, there's a high risk that it won't.
>> There's also that advice for any tool is invariably biased, so I also risk
>> acting on inappropriate advice. I've been bitten by this time after time,
>> Maven is just the last
>
> Based on your wants stated above, my view is Gradle is what you want...
Maybe. I'm not sure whether it's really managing build ordering
constraints well enough to be worth it.
> might not be what anyone else working on your project wants, may not even
> be what you need, but you have your core principals and they clash with
> Maven's core principals, for the sake of the children (the source code)
> perhaps you and Maven should get a divorce
I hear ya.
As with every divorce, things are easier said than done.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On 7 March 2013 11:57, Joachim Durchholz <jo...@durchholz.org> wrote:
> Warning: Just philosophy here.
> I AM trying to restrict myself to things I haven't said before. Some
> amount of repetition is inevitable, and this kind of discussion is nearing
> the point of diminishing returns, so I'm trying to cut down on this kind of
> discussion.
>
> Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
>
> I'm having a hard time understanding why you keep being unwilling to use
>> Maven conventions but keep using it at the same time.
>>
>
> Hello? Because it has been advertised to me as "THE build tool that will
> solve my problems"? And maybe because switching build tool in mid-flight is
> a daunting task?
>
> I'm here because I'm locked in, not because I think Maven is great.
>
>
> Maven is the opinionated build tool. Using its conventions is almost
>> compulsory. Maven is all about conventions and making build standard
>> across
>> projects.
>>
>
> Problem with Maven is that its conventions are too restrictive. Maven
> works well as long as you are 100% inside its mental model of how a build
> should be set up; the problem is that as soon as you (need to) work outside
> that box, Maven will break down, horribly.
>
Maven is *the* opinionated build tool.
Like any relationship, you must have give and take... both sides need
flexibility... but at some point there will be a deal breaker...
I like to let the dishes soak in the burn your hands hot soapy water for 5
minutes to let the surfactants do their stuff... she likes to start washing
them straight away... meh! I can compromise and put up with slightly less
clean dishes... so what if I have a PhD in physical chemistry and *know*
that my way is the correct way to wash dishes... or maybe we buy a
dishwashing machine and let it do the dishes for us.
On the other hand, previously I didn't like kissing an ashtray, she didn't
want to give up smoking... that was something I tried to compromise on, but
you know what, turns out that smoking is a deal breaker, so that
relationship ended (lucky for me and my wife eh!)
This is not a "Maven" issue. This is a relationship issue.
To bring this back to Maven...
Maven wants the java source code in ${basedir}/src/main/java... you want it
somewhere else... you know what, Maven is OK with that
Maven wants to build the dependency tree before it finalizes a build plan
that will include plugin executions that require resolving the dependency
tree in order to ensure that the transitive dependency tree does not
reorder the build-plan... you don't want to use a maven repository manager
or run a separate script to install the 3rd party dependencies into the
local repository cache... that one is a deal breaker for Maven... the
question is I have for you is: can you live with Maven's restrictions? This
is something that Maven will not compromise on... the ball is in your court.
> Overly terse documentation makes it worse because that makes it hard to
> decide whether the reason for some problem is because some option wasn't
> properly set, or whether the plugin simply can't do what one wants. That's
> making for a lot of frustrating dead-end exploration.
I am trying to come up with a better user facing documentation for the core
of Maven itself... my aim being to let people know that Maven is
OPINIONATED, that it's ok to disagree on some of those opinions, but that
some things are core opinions and if you disagree with those core opinions,
please don't use Maven.
>
>
> If you want full scripting features and design the build the exact way you
>> want,
>>
>
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a
> way to test whether their metadata are correct, since otherwise people will
> get subtle errors into the build plans.
>
You don't want Maven... if you are not prepared to compromise on the above,
then (and please don't take this the wrong way) stop using Maven.
>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
> This is usually done via a plugin that configures Eclipse projects,
> restricting further what can and what cannot work as build script (or
> requires another layer of metadata so the plugin knows what to do; m2e's
> lifecycle mapping complications are a good example how complicated this
> problem is.)
> (Substitute the IDE of your choice for Eclipse if you want.)
Do you want a pony too? ;-)
>
>
> > then have a look at gradle. Or ant+ivy might make you happy.
>
> I'm not sure whether Gradle fits the bill. Given the complexities
> involved, there's a high risk that it won't.
> There's also that advice for any tool is invariably biased, so I also risk
> acting on inappropriate advice. I've been bitten by this time after time,
> Maven is just the last
Based on your wants stated above, my view is Gradle is what you want...
might not be what anyone else working on your project wants, may not even
be what you need, but you have your core principals and they clash with
Maven's core principals, for the sake of the children (the source code)
perhaps you and Maven should get a divorce
-Stephen
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 08.03.2013 14:05, schrieb Baptiste MATHUS:
>> If there's no way to get it to work (and that's the answer I got from
>> Baptiste), then it's not me who's doing it wrong.
>
> Where did I write "there's no way to get it to work"?
Sorry for the misrepresentation - it was the conclusion I arrived at
after reading the information from your post, and in fact not what you
actually wrote.
> Initially I actually just gave you a hint of the path I would look at. You
> then transformed this thread into a troll...
I made a passing remark that I find a redundant store in a Maven jar is
silly.
It was others who turned that into the usual "you're doing it wrong - no
I don't" tug-of-war.
And no, I'm not trolling. Please look the definition up - I am NOT doing
it to gain attention, I'd be all too happy if none of this quarelling
had ever been happening. Problem is, I can't simply let allegations of
ineptitude stand, I have a professional rep to protect.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Jeff MAURY <je...@jeffmaury.com>.
Maybe you could have a look at the truezip maven plugin:
http://mojo.codehaus.org/truezip/truezip-maven-plugin/
Regards
Jeff
On Fri, Mar 8, 2013 at 2:05 PM, Baptiste MATHUS <ml...@batmat.net> wrote:
> Le 8 mars 2013 08:29, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
> >
> > Am 08.03.2013 04:48, schrieb Ron Wheeler:
> >
> >> I am not sure what you expect us to say.
> >
> >
> > Simply stick with the question at hand and don't waste everybody's time
> with evangelizing and philosophy.
> >
> >
> >> By your own experience, your approach doesn't work; you won't try to do
> >> it the right way;
> >
> >
> > If there's no way to get it to work (and that's the answer I got from
> Baptiste), then it's not me who's doing it wrong.
>
> Where did I write "there's no way to get it to work"?
>
> Initially I actually just gave you a hint of the path I would look at. You
> then transformed this thread into a troll...
>
> -- Baptiste
>
--
Jeff MAURY
"Legacy code" often differs from its suggested alternative by actually
working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Re: Unpacking jars into target/classes
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 8 mars 2013 08:29, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
> Am 08.03.2013 04:48, schrieb Ron Wheeler:
>
>> I am not sure what you expect us to say.
>
>
> Simply stick with the question at hand and don't waste everybody's time
with evangelizing and philosophy.
>
>
>> By your own experience, your approach doesn't work; you won't try to do
>> it the right way;
>
>
> If there's no way to get it to work (and that's the answer I got from
Baptiste), then it's not me who's doing it wrong.
Where did I write "there's no way to get it to work"?
Initially I actually just gave you a hint of the path I would look at. You
then transformed this thread into a troll...
-- Baptiste
Re: Unpacking jars into target/classes
Posted by "Lyons, Roy" <Ro...@cmegroup.com>.
I have always referred to it as the "local dot m2 cache". people know
exactly what I am talking about when I say that...
Thanks,
Roy Lyons
On 3/8/13 8:16 AM, "Ron Wheeler" <rw...@artifact-software.com> wrote:
>On 08/03/2013 9:07 AM, Doug Douglass wrote:
>> On Fri, Mar 8, 2013 at 12:28 AM, Joachim Durchholz <jo...@durchholz.org>
>>wrote:
>>>
>>> Matthew mentioned install-file, but I already explained why a Maven
>>>repo
>>> is not an option.
>>>
>>>
>> Just a point of clarification, install-file installs artifacts into a
>> machines local repository cache, and in no way requires an MRM. I think
>> Matthew was suggesting to use install-file specifically because you are
>>not
>> using an MRM.
>>
>> Unfortunately, the local repository cache is often referred to simply
>>as a
>> repository and this frequently causes confusion. Perhaps we (the maven
>> community) should refer to the local repository cache by a different
>>name
>> e.g. artifact cache.
>>
>> Cheers
>>
>workstation cache?
>
>--
>Ron Wheeler
>President
>Artifact Software Inc
>email: rwheeler@artifact-software.com
>skype: ronaldmwheeler
>phone: 866-970-2435, ext 102
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 08/03/2013 9:07 AM, Doug Douglass wrote:
> On Fri, Mar 8, 2013 at 12:28 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
>>
>> Matthew mentioned install-file, but I already explained why a Maven repo
>> is not an option.
>>
>>
> Just a point of clarification, install-file installs artifacts into a
> machines local repository cache, and in no way requires an MRM. I think
> Matthew was suggesting to use install-file specifically because you are not
> using an MRM.
>
> Unfortunately, the local repository cache is often referred to simply as a
> repository and this frequently causes confusion. Perhaps we (the maven
> community) should refer to the local repository cache by a different name
> e.g. artifact cache.
>
> Cheers
>
workstation cache?
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Doug Douglass <do...@gmail.com>.
On Fri, Mar 8, 2013 at 12:28 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
>
>
> Matthew mentioned install-file, but I already explained why a Maven repo
> is not an option.
>
>
Just a point of clarification, install-file installs artifacts into a
machines local repository cache, and in no way requires an MRM. I think
Matthew was suggesting to use install-file specifically because you are not
using an MRM.
Unfortunately, the local repository cache is often referred to simply as a
repository and this frequently causes confusion. Perhaps we (the maven
community) should refer to the local repository cache by a different name
e.g. artifact cache.
Cheers
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 08.03.2013 04:48, schrieb Ron Wheeler:
> I am not sure what you expect us to say.
Simply stick with the question at hand and don't waste everybody's time
with evangelizing and philosophy.
> By your own experience, your approach doesn't work; you won't try to do
> it the right way;
If there's no way to get it to work (and that's the answer I got from
Baptiste), then it's not me who's doing it wrong.
Matthew mentioned install-file, but I already explained why a Maven repo
is not an option.
> you call people names who are trying to help you.
You may think you're trying to help, but repeating advice that can't be
followed isn't.
> You may not have noticed but no one in the forum is jumping in to take
> your side.
Self-selected group.
Plus, many people shy controversy.
Plus, nothing new for the regulars.
I'd get the same kind of (non-)reaction in a Fortran group, for the same
reasons, so that observation doesn't prove a thing.
And I think that's enough of off-topic discussion for this thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 07/03/2013 6:53 PM, Stephen Connolly wrote:
> On Thursday, 7 March 2013, Joachim Durchholz wrote:
>
>> Am 07.03.2013 22:41, schrieb Stephen Connolly:
>>
>>> Crazy and stupid are not insults in this context...
>>>
>> So if I call Ron a clown, and when he's considering that an insult, I
>> explain to him that that's a very respectable thing to be?
I have a pretty thick skin and I would be somewhat comforted by the fact
that my Maven setup works smooth as silk.
We are only trying to help you and I have written a lot of text trying
to give you confidence that it can work for you by giving examples of
the kinds of projects that we build under Maven.
Stephen has given you the very best advice in great detail.
I am not sure what you expect us to say.
By your own experience, your approach doesn't work; you won't try to do
it the right way; you call people names who are trying to help you.
You may not have noticed but no one in the forum is jumping in to take
your side.
Ron
>
> People can take offence at the strangest of things.
>
> The biggest fallacy is the "do onto others as you would have them do onto
> you" mentality... It makes a lot of assumptions of others... And we all
> know when we assume we make an ass of u and me.
>
> If people want to take offence at something others say without malice, that
> us life, we try to learn from it and adapt our internal models... But
> sometimes it just doesn't fit.
>
>
>> I think you are taking this thread far too personally
>> On the other hand, I don't think you're in a position to decide that.
>
> You are entitled to your opinion as much as I am entitled to mine. Agree to
> differ and let's move on.
>
>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 7 March 2013, Joachim Durchholz wrote:
> Am 07.03.2013 22:41, schrieb Stephen Connolly:
>
>> Crazy and stupid are not insults in this context...
>>
>
> So if I call Ron a clown, and when he's considering that an insult, I
> explain to him that that's a very respectable thing to be?
People can take offence at the strangest of things.
The biggest fallacy is the "do onto others as you would have them do onto
you" mentality... It makes a lot of assumptions of others... And we all
know when we assume we make an ass of u and me.
If people want to take offence at something others say without malice, that
us life, we try to learn from it and adapt our internal models... But
sometimes it just doesn't fit.
>
> I think you are taking this thread far too personally
>>
>
> On the other hand, I don't think you're in a position to decide that.
You are entitled to your opinion as much as I am entitled to mine. Agree to
differ and let's move on.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 22:41, schrieb Stephen Connolly:
> Crazy and stupid are not insults in this context...
So if I call Ron a clown, and when he's considering that an insult, I
explain to him that that's a very respectable thing to be?
> I think you are taking this thread far too personally
On the other hand, I don't think you're in a position to decide that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
Well if the thing that one is doing is neither crazy nor stupid => others
will need to do it => should be turned into a plugin
If the thing one is doing is crazy but not stupid => others may want to do
it => should be turned into a plugin
If the thing one is doing is not crazy but is stupid => others will want
to do it => should be turned into a plugin
If the thing one is doing is both crazy and stupid => nobody else will have
a need to do it => waste of time turning it into a plugin => use antrun or
equivalent
Crazy and stupid are not insults in this context...
Eg. Crazy can actually be the smart thing... An ex-coworker of mine is
working for a company where they write MySQL database tables raw without
using MySQL at all... How else can they take the routing info from a
network switch and capture it all... That is crazy... You wouldn't want to
do that without good reason... They have good reason
Eg. Stupid can actually be the pragmatic thing... I know people who deploy
into production by pushing to the DR instance and then they "pull the power
cord" on the live nodes... That's stupid... But it gives them confidence if
their HA
The type of things that I was referring to we're the ones where you tell an
ex-coworker what you do and they say "that's crazy" or "that's stupid" and
then you get to say "you'd think so, ordinarily you'd be right, *but* in
this very specific instance..."
I think you are taking this thread far too personally
-Stephen
On Thursday, 7 March 2013, Joachim Durchholz wrote:
> So no apology and you feel entirely justified.
> With the argument that you're not talking to me but to posteriority. Now
> it seems that your perceptions of future readers are more important than
> anything I have to say; I'll keep that in mind.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
So no apology and you feel entirely justified.
With the argument that you're not talking to me but to posteriority. Now
it seems that your perceptions of future readers are more important than
anything I have to say; I'll keep that in mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 7 March 2013, Joachim Durchholz wrote:
> Am 07.03.2013 13:55, schrieb Stephen Connolly:
>
>> BUT if you are doing something that is crazy and stupid
>>
>
> Yeah okay, I stopped reading at that allegation.
Think of it as
"BUT if one is doing..."
Keep in mind that the mailing list is a public archive, so sometimes we say
things with a wording designed to benefit future readers, one should not
take them quite so personally. 95% of the time "you" actually should be
read as "one" and then it makes more sense... But as it sounds more like
something a sovereign might say when addressing their subjects, we use the
informal "you"
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am not one of the experts, I am only a user of the software trying to
tell you how we use it and trying to assure you that it works.
I was just trying to point out to you in a light-hearted way that you
are getting the highest level of expertise available.
Everyone is being polite and respectful
You are getting advice and not abuse.
The fact that you do not like the advice and consider it abusive that
you keep getting told that your approach is fraught with problems, does
not make it abuse..
Ron
On 07/03/2013 4:24 PM, Joachim Durchholz wrote:
> Am 07.03.2013 19:53, schrieb Ron Wheeler:
>> The trick is not to stop reading it but to stop doing it.
>
> Nope. The trick is to ignore abuse.
>
>> You are getting advice from one of principle architects and authors of
>> Maven.
>
> No advice, just evangelizing and allegations that I'm an idiot.
>
>> What would you consider to be "expert advice" that you should follow?
>> Bear in mind that God is busy this week appointing a Pope!
>
> So you're considering yourself Popes of the Church of Maven?
> And you're taking that as an excuse to insult intelligent people, and
> to place yourself above them?
>
> There is little polite I can say about that kind of stance.
> And it's really, really, really best to leave it at that. This post
> required several rewrites, with gritted teeth, just to keep it barely
> civil.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 19:53, schrieb Ron Wheeler:
> The trick is not to stop reading it but to stop doing it.
Nope. The trick is to ignore abuse.
> You are getting advice from one of principle architects and authors of
> Maven.
No advice, just evangelizing and allegations that I'm an idiot.
> What would you consider to be "expert advice" that you should follow?
> Bear in mind that God is busy this week appointing a Pope!
So you're considering yourself Popes of the Church of Maven?
And you're taking that as an excuse to insult intelligent people, and to
place yourself above them?
There is little polite I can say about that kind of stance.
And it's really, really, really best to leave it at that. This post
required several rewrites, with gritted teeth, just to keep it barely civil.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
The trick is not to stop reading it but to stop doing it.
You are getting advice from one of principle architects and authors of
Maven.
What would you consider to be "expert advice" that you should follow?
Bear in mind that God is busy this week appointing a Pope!
Ron
On 07/03/2013 1:48 PM, Joachim Durchholz wrote:
> Am 07.03.2013 13:55, schrieb Stephen Connolly:
>> BUT if you are doing something that is crazy and stupid
>
> Yeah okay, I stopped reading at that allegation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 13:55, schrieb Stephen Connolly:
> BUT if you are doing something that is crazy and stupid
Yeah okay, I stopped reading at that allegation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Stephen Connolly <st...@gmail.com>.
On 7 March 2013 12:34, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 07.03.2013 13:05, schrieb Andreas Gudian:
>
> That's not really what I want.
>>> I want a declarative specification so the tool can decide what build
>>> steps
>>> to run.
>>> I want full scripting only for the individual build steps. This probably
>>> means an obligation to specify the declarative metadata so the tool can
>>> set
>>> up its build plan. Plus this probably also means that people will need a
>>> way to test whether their metadata are correct, since otherwise people
>>> will
>>> get subtle errors into the build plan.
>>>
>>
>> Then the ant-plugin should help you. Eclipse might have a harder time in
>> that case, though.
>>
>
> I've been considering the ant plugin, but that's excactly the catch I've
> been worrying about.
>
> The other reason is that Maven literature have generally been listing Ant
> as a kind of cop-out that should be avoided.
> But maybe I've been taking that advice more seriously than it was ever
> intended, so I'll probably try that.
>
The Maven philosophy is to avoid writing one-time code as much as possible.
So using antrun or the groovy plugins to run some 'specific to this build
only' step is frowned upon for the reason that it is most likely something
that could be reused in other projects if just made a little more generic
and then everyone wins.
When you write a "this project only" step, you are forcing anyone looking
at the build at a later point in time to figure out what the hell that is
doing. A properly documented plugin execution (yes yes when the hell have
we ever seen one of them... that's the difference between philosophy and
actually doing stuff) would just mean that I look at the plugin
documentation and hey! I know what thats doing.
BUT if you are doing something that is crazy and stupid and just has to be
this way for this one and only project, then antrun or the ant plugin or
the groovy plugin, they are all just fine and dandy and perfect for your
requirements.... if it turns out later that with some minor tweaks it could
be turned into a plugin that is generally useful to other projects... then
the frowns and looks of disapproval will reappear ;-)
>
> Regards,
> Jo
>
> ------------------------------**------------------------------**---------
>
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 13:05, schrieb Andreas Gudian:
>> That's not really what I want.
>> I want a declarative specification so the tool can decide what build steps
>> to run.
>> I want full scripting only for the individual build steps. This probably
>> means an obligation to specify the declarative metadata so the tool can set
>> up its build plan. Plus this probably also means that people will need a
>> way to test whether their metadata are correct, since otherwise people will
>> get subtle errors into the build plan.
>
> Then the ant-plugin should help you. Eclipse might have a harder time in
> that case, though.
I've been considering the ant plugin, but that's excactly the catch I've
been worrying about.
The other reason is that Maven literature have generally been listing
Ant as a kind of cop-out that should be avoided.
But maybe I've been taking that advice more seriously than it was ever
intended, so I'll probably try that.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Andreas Gudian <an...@gmail.com>.
Am Donnerstag, 7. März 2013 schrieb Joachim Durchholz :
> Warning: Just philosophy here.
> I AM trying to restrict myself to things I haven't said before. Some
> amount of repetition is inevitable, and this kind of discussion is nearing
> the point of diminishing returns, so I'm trying to cut down on this kind of
> discussion.
>
> Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
>
>> I'm having a hard time understanding why you keep being unwilling to use
>> Maven conventions but keep using it at the same time.
>>
>
> Hello? Because it has been advertised to me as "THE build tool that will
> solve my problems"? And maybe because switching build tool in mid-flight is
> a daunting task?
>
> I'm here because I'm locked in, not because I think Maven is great.
>
> Maven is the opinionated build tool. Using its conventions is almost
>> compulsory. Maven is all about conventions and making build standard
>> across
>> projects.
>>
>
> Problem with Maven is that its conventions are too restrictive. Maven
> works well as long as you are 100% inside its mental model of how a build
> should be set up; the problem is that as soon as you (need to) work outside
> that box, Maven will break down, horribly.
> Overly terse documentation makes it worse because that makes it hard to
> decide whether the reason for some problem is because some option wasn't
> properly set, or whether the plugin simply can't do what one wants. That's
> making for a lot of frustrating dead-end exploration.
>
> If you want full scripting features and design the build the exact way you
>> want,
>>
>
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a
> way to test whether their metadata are correct, since otherwise people will
> get subtle errors into the build plan.
Then the ant-plugin should help you. Eclipse might have a harder time in
that case, though.
>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
> This is usually done via a plugin that configures Eclipse projects,
> restricting further what can and what cannot work as build script (or
> requires another layer of metadata so the plugin knows what to do; m2e's
> lifecycle mapping complications are a good example how complicated this
> problem is.)
> (Substitute the IDE of your choice for Eclipse if you want.)
>
> > then have a look at gradle. Or ant+ivy might make you happy.
>
> I'm not sure whether Gradle fits the bill. Given the complexities
> involved, there's a high risk that it won't.
> There's also that advice for any tool is invariably biased, so I also risk
> acting on inappropriate advice. I've been bitten by this time after time,
> Maven is just the last
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Warning: Just philosophy here.
I AM trying to restrict myself to things I haven't said before. Some
amount of repetition is inevitable, and this kind of discussion is
nearing the point of diminishing returns, so I'm trying to cut down on
this kind of discussion.
Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
> I'm having a hard time understanding why you keep being unwilling to use
> Maven conventions but keep using it at the same time.
Hello? Because it has been advertised to me as "THE build tool that will
solve my problems"? And maybe because switching build tool in mid-flight
is a daunting task?
I'm here because I'm locked in, not because I think Maven is great.
> Maven is the opinionated build tool. Using its conventions is almost
> compulsory. Maven is all about conventions and making build standard across
> projects.
Problem with Maven is that its conventions are too restrictive. Maven
works well as long as you are 100% inside its mental model of how a
build should be set up; the problem is that as soon as you (need to)
work outside that box, Maven will break down, horribly.
Overly terse documentation makes it worse because that makes it hard to
decide whether the reason for some problem is because some option wasn't
properly set, or whether the plugin simply can't do what one wants.
That's making for a lot of frustrating dead-end exploration.
> If you want full scripting features and design the build the exact way you
> want,
That's not really what I want.
I want a declarative specification so the tool can decide what build
steps to run.
I want full scripting only for the individual build steps. This probably
means an obligation to specify the declarative metadata so the tool can
set up its build plan. Plus this probably also means that people will
need a way to test whether their metadata are correct, since otherwise
people will get subtle errors into the build plans.
I also want Eclipse integration, so build configuration doesn't need to
be specified redundantly.
This is usually done via a plugin that configures Eclipse projects,
restricting further what can and what cannot work as build script (or
requires another layer of metadata so the plugin knows what to do; m2e's
lifecycle mapping complications are a good example how complicated this
problem is.)
(Substitute the IDE of your choice for Eclipse if you want.)
> then have a look at gradle. Or ant+ivy might make you happy.
I'm not sure whether Gradle fits the bill. Given the complexities
involved, there's a high risk that it won't.
There's also that advice for any tool is invariably biased, so I also
risk acting on inappropriate advice. I've been bitten by this time after
time, Maven is just the last
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Baptiste MATHUS <ml...@batmat.net>.
Le 7 mars 2013 10:02, "Jörg Schaible" <Jo...@scalaris.com> a
écrit :
>
> Hi,
>
> Joachim Durchholz wrote:
>
> > Am 07.03.2013 05:51, schrieb Matthew Adams:
> >> Quick jist:
> >> 1. Use maven-install-plugin's
> >> install-file<http://maven.apache.org/plugins/maven-install-
> plugin/install-file-mojo.html>goal
> >> to make maven artifacts out of the jars you intend to unpack, and do
> >> it in any phase prior to process-classes (or do this first in the
> >> process-classes phase).
> >
> > The overall organisational project structure does not allow any central
> > servers beyond the SCM.
> > It would also be silly to redundantly store a perfectly stable jar in a
> > Maven repo just to make Maven happy.
>
> But that's the point: Maven is all about conventions. It will not help
you a
> lot in other regards - on purpose. If you don't want to follow this
> conventions, it is probably no the right tool for your job.
+1.
I'm having a hard time understanding why you keep being unwilling to use
Maven conventions but keep using it at the same time.
Maven is the opinionated build tool. Using its conventions is almost
compulsory. Maven is all about conventions and making build standard across
projects.
If you want full scripting features and design the build the exact way you
want, then have a look at gradle. Or ant+ivy might make you happy.
Cheers
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 12:53, schrieb Anders Hammar:
> You forgot:
> - You need a repo manager
>
> :-)
> Sorry, couldn't stop myself,
Yeah, talk about waste of time :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Anders Hammar <an...@hammar.net>.
You forgot:
- You need a repo manager
:-)
Sorry, couldn't stop myself,
/Anders
On Thu, Mar 7, 2013 at 12:46 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 07.03.2013 12:07, schrieb Jörg Schaible:
>
>> Personally, I'll
>> simply stop to look at your questions, because you waste my time and IMHO
>> you waste yours, too.
>>
>
> I couldn't agree more to the waste-of-time observation.
> Though in our case, I guess it's been your answer with its lengthy
> philosophical content that started the waste of time.
>
> I suggest avoiding philosophy if that's not your interest, and simply
> sticking with answering questions at the factual level:
> - No, this plugin is not for the use case you describe;
> - yes, this option is the right one;
> - oh, that's not the plugin you need but try that option instead;
> - maybe you can vary your use case in this-and-that way?
> This kind of answer would be very much appreciated.
>
> Regards,
> Jo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 12:07, schrieb Jörg Schaible:
> Personally, I'll
> simply stop to look at your questions, because you waste my time and IMHO
> you waste yours, too.
I couldn't agree more to the waste-of-time observation.
Though in our case, I guess it's been your answer with its lengthy
philosophical content that started the waste of time.
I suggest avoiding philosophy if that's not your interest, and simply
sticking with answering questions at the factual level:
- No, this plugin is not for the use case you describe;
- yes, this option is the right one;
- oh, that's not the plugin you need but try that option instead;
- maybe you can vary your use case in this-and-that way?
This kind of answer would be very much appreciated.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi Jo,
Joachim Durchholz wrote:
> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>> Hi,
>>
>> Joachim Durchholz wrote:
>>
>>> Am 07.03.2013 05:51, schrieb Matthew Adams:
>>>> Quick jist:
>>>> 1. Use maven-install-plugin's
>>>> install-file<http://maven.apache.org/plugins/maven-install-
>> plugin/install-file-mojo.html>goal
>>>> to make maven artifacts out of the jars you intend to unpack, and do
>>>> it in any phase prior to process-classes (or do this first in the
>>>> process-classes phase).
>>>
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>>
>> But that's the point: Maven is all about conventions. It will not help
>> you a lot in other regards - on purpose.
>
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and Maven
> does indeed have domains (dependency management, builds, build stability).
>
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
>
> > If you don't want to follow this
>> conventions, it is probably no the right tool for your job.
>
> I claim that Maven's stance of essentially requiring a repository
> manager needlessly complicates the build infrastructure.
>
> Regards,
> Jo
>
> P.S.: Not that discussing Maven's philosophy helps my original problem
> in any way... essentially you're saying "Maven can't do that and that's
> okay", and I say "if Maven can't do that by design, then the design of
> Maven is broken".
> You consider my position baseless because, from your perspective, I want
> the undesirable; I consider your position baseless because you're
> putting some very abstract theory about what's desirable ahead of very
> concrete and practical needs, and I consider theory useless if it
> doesn't cover all bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.
You're free to have a different opinion, but don't expect Maven to change or
to get a lot of help from the community then. A tool is designed for a
special purpose and either you accept that or you get yourself into trouble.
Maven was never meant as golden bullet for all cases. Personally, I'll
simply stop to look at your questions, because you waste my time and IMHO
you waste yours, too. And this is nothing personal nor do I want to start a
flame war, it's just experience of using Maven for a lot of years.
Best whishes,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Ron Wheeler <rw...@artifact-software.com>.
Tens of thousands of developers use Maven every day.
They like the way that it works now and don't want it to change.
They build all kinds of projects - big ones, little ones, ones with lots
of third party dependencies and lots with just a few.
We have an LMS that we built with Maven - it has over 80 projects that
make up the artifacts required to provide all the functionality.
It leverages Spring, Hibernate, MySQL, JasperReports, CXF and Axis, JSF
and a few more outside technologies.
We have our virtual meeting registration portal takeawebinar.com that is
smaller with a similar set of technologies.
Our ADTransform only has 7 projects with JCR as its persistence
architecture but it includes the manual which is written using DITA and
assembled using a Maven plug-in that controls the Open-DITA tool kit.
I am also using Maven to assemble the study report that I am doing about
how to modernize the delivery of training to police management and
technical staff which is also being done in DITA.
Lots of people use Eclipse.
We use Eclipse/STS from Springsource since it gives us everything that
we need in one download.
I am currently using the latest Eclipse Juno M2 with the Springsource
Tool Kit added because there was a serious bug the the last Eclipse
release with XML and DITA is all XML. Springsource will only release a
new version when Eclipse releases the patched release this month.
I am the only one affected by this at Artifact.
We NEVER EVER use Maven from the command line.
Maven sits quietly in the background doing our builds without any fuss
or bother just by right-clicking on the POM and selecting the correct
option off the Run As menu
For a new person to modify a project, they only have to use Eclipse to
checkout the project, modify the code they want to changes, click on the
pom to build it, and run the tests and then synchronize to update their
changes in the SCM.
They do not need any other projects other than the one that they are
working on. No interproject dependencies are resolved within the Eclipse
workspace.
If they need to fix a module and a dependent library, they need to build
the dependent library first and at least "install" it.
Maven is not a deployment tool and we will probably use an installer
(izPack looks good) with Ant to build installers for the supported
architectures and configurations for ADTransform.
The other portals are hosted by us so we just copy the jars and wars
when we need to make a change.
Embarrassingly low tech!!! We only release new versions very
infrequently and bugs usually involve a single war file so it is not top
of mind at this point.
We have Nexus and in our 3rd party library repo, we have 8 artifacts
that are not available in Maven Central for various reasons(licensing,
unreleased versions, not mavenized, etc.).
We had to download them and manually install them in the repo.
We do not offer any artifacts from our repo to the public.
We have tried to explain Maven best practices and I believe that I
offered to show you how we use Eclipse.
The other people in this thread are the best Maven experts around . I am
just a keen user of Maven.
Maven is like a very large ocean liner and it will change direction very
slowly.
Paddling your canoe out in front and yelling "Turn, turn turn." at the
top of your lungs will only get you run over.
We are all on board and are yelling that you need to buy the ticket and
get on board where you will be warm and dry with a nice view or that you
should find another place to paddle.
Sitting where you are, is not going to make you happy and the good ship
Maven with it thousands of passengers is not going to turn in time to
save you.
Ron
On 07/03/2013 5:37 AM, Joachim Durchholz wrote:
> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>> Hi,
>>
>> Joachim Durchholz wrote:
>>
>>> Am 07.03.2013 05:51, schrieb Matthew Adams:
>>>> Quick jist:
>>>> 1. Use maven-install-plugin's
>>>> install-file<http://maven.apache.org/plugins/maven-install-
>> plugin/install-file-mojo.html>goal
>>>> to make maven artifacts out of the jars you intend to unpack, and do
>>>> it in any phase prior to process-classes (or do this first in the
>>>> process-classes phase).
>>>
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>>
>> But that's the point: Maven is all about conventions. It will not
>> help you a
>> lot in other regards - on purpose.
>
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and
> Maven does indeed have domains (dependency management, builds, build
> stability).
>
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
>
> > If you don't want to follow this
>> conventions, it is probably no the right tool for your job.
>
> I claim that Maven's stance of essentially requiring a repository
> manager needlessly complicates the build infrastructure.
>
> Regards,
> Jo
>
> P.S.: Not that discussing Maven's philosophy helps my original problem
> in any way... essentially you're saying "Maven can't do that and
> that's okay", and I say "if Maven can't do that by design, then the
> design of Maven is broken".
> You consider my position baseless because, from your perspective, I
> want the undesirable; I consider your position baseless because you're
> putting some very abstract theory about what's desirable ahead of very
> concrete and practical needs, and I consider theory useless if it
> doesn't cover all bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
(Sorry, more philosphy ahead, just trying to explain my situation to Adrien)
Am 07.03.2013 12:16, schrieb Adrien Rivard:
>> I claim that Maven's stance of essentially requiring a repository manager
>> needlessly complicates the build infrastructure.
>>
> It may complicate the build infrastrucure but it simplify and homogenize a
> lots all the builds of all your project.
To date, I have been using Maven in one environment with a MRM and one
without.
The MRM-based development got more complicated. I do see the advantages
that an MRM can offer, but these have been irrelevant for our situation.
> Which is what Maven is all about.
I get that.
Trouble is that at the current project sizes, homogenization isn't
giving me much of an advantage. I have inhomogenous jar imports, I have
inhomogenous deployment scenarios, and there's nothing I can do about
either side.
> If you don't want to use a repository manager, just don't use Maven, Maven
> is not flexible by design.
Understood, and a conclusion I have reached quite a while ago.
Unfortunately, changing the build tool is never an easy option.
So for now, I'm stuck with Maven, whether it's the right tool for the
job or not, and I'll have to somehow make it work whatever the problems.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Adrien Rivard <ad...@gmail.com>.
On Thu, Mar 7, 2013 at 11:37 AM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>
> Hi,
>>
>> Joachim Durchholz wrote:
>>
>> Am 07.03.2013 05:51, schrieb Matthew Adams:
>>>
>>>> Quick jist:
>>>> 1. Use maven-install-plugin's
>>>> install-file<http://maven.**apache.org/plugins/maven-**install-<http://maven.apache.org/plugins/maven-install->
>>>>
>>> plugin/install-file-mojo.html>**goal
>>
>>> to make maven artifacts out of the jars you intend to unpack, and do
>>>> it in any phase prior to process-classes (or do this first in the
>>>> process-classes phase).
>>>>
>>>
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>>>
>>
>> But that's the point: Maven is all about conventions. It will not help
>> you a
>> lot in other regards - on purpose.
>>
>
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and Maven
> does indeed have domains (dependency management, builds, build stability).
>
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
>
>
> > If you don't want to follow this
>
>> conventions, it is probably no the right tool for your job.
>>
>
> I claim that Maven's stance of essentially requiring a repository manager
> needlessly complicates the build infrastructure.
>
>
It may complicate the build infrastrucure but it simplify and homogenize a
lots all the builds of all your project. Which is what Maven is all about.
If you don't want to use a repository manager, just don't use Maven, Maven
is not flexible by design. If you want to use it outside its main design,
you will have a too complex build. This will be better achieved with a
tools that support scripting in its design.
That said, it is still useful to have a repopsitory manager even with
others build tools like gradle/ant+ivy.
Regards,
> Jo
>
> P.S.: Not that discussing Maven's philosophy helps my original problem in
> any way... essentially you're saying "Maven can't do that and that's okay",
> and I say "if Maven can't do that by design, then the design of Maven is
> broken".
> You consider my position baseless because, from your perspective, I want
> the undesirable; I consider your position baseless because you're putting
> some very abstract theory about what's desirable ahead of very concrete and
> practical needs, and I consider theory useless if it doesn't cover all
> bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Adrien Rivard
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 10:00, schrieb Jörg Schaible:
> Hi,
>
> Joachim Durchholz wrote:
>
>> Am 07.03.2013 05:51, schrieb Matthew Adams:
>>> Quick jist:
>>> 1. Use maven-install-plugin's
>>> install-file<http://maven.apache.org/plugins/maven-install-
> plugin/install-file-mojo.html>goal
>>> to make maven artifacts out of the jars you intend to unpack, and do
>>> it in any phase prior to process-classes (or do this first in the
>>> process-classes phase).
>>
>> The overall organisational project structure does not allow any central
>> servers beyond the SCM.
>> It would also be silly to redundantly store a perfectly stable jar in a
>> Maven repo just to make Maven happy.
>
> But that's the point: Maven is all about conventions. It will not help you a
> lot in other regards - on purpose.
So if a tool doesn't what it should, that's just on purpose? Come on.
Oh, and conventions are useless unless applied to some domain, and Maven
does indeed have domains (dependency management, builds, build stability).
Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
> If you don't want to follow this
> conventions, it is probably no the right tool for your job.
I claim that Maven's stance of essentially requiring a repository
manager needlessly complicates the build infrastructure.
Regards,
Jo
P.S.: Not that discussing Maven's philosophy helps my original problem
in any way... essentially you're saying "Maven can't do that and that's
okay", and I say "if Maven can't do that by design, then the design of
Maven is broken".
You consider my position baseless because, from your perspective, I want
the undesirable; I consider your position baseless because you're
putting some very abstract theory about what's desirable ahead of very
concrete and practical needs, and I consider theory useless if it
doesn't cover all bases.
Given that situation, I don't think it's going to be very fruitful to
discuss Maven's philosophy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Jörg Schaible <Jo...@scalaris.com>.
Hi,
Joachim Durchholz wrote:
> Am 07.03.2013 05:51, schrieb Matthew Adams:
>> Quick jist:
>> 1. Use maven-install-plugin's
>> install-file<http://maven.apache.org/plugins/maven-install-
plugin/install-file-mojo.html>goal
>> to make maven artifacts out of the jars you intend to unpack, and do
>> it in any phase prior to process-classes (or do this first in the
>> process-classes phase).
>
> The overall organisational project structure does not allow any central
> servers beyond the SCM.
> It would also be silly to redundantly store a perfectly stable jar in a
> Maven repo just to make Maven happy.
But that's the point: Maven is all about conventions. It will not help you a
lot in other regards - on purpose. If you don't want to follow this
conventions, it is probably no the right tool for your job.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Am 07.03.2013 05:51, schrieb Matthew Adams:
> Quick jist:
> 1. Use maven-install-plugin's
> install-file<http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html>goal
> to make maven artifacts out of the jars you intend to unpack, and do
> it in any phase prior to process-classes (or do this first in the
> process-classes phase).
The overall organisational project structure does not allow any central
servers beyond the SCM.
It would also be silly to redundantly store a perfectly stable jar in a
Maven repo just to make Maven happy.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Matthew Adams <ma...@matthewadams.me>.
Quick jist:
1. Use maven-install-plugin's
install-file<http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html>goal
to make maven artifacts out of the jars you intend to unpack, and do
it in any phase prior to process-classes (or do this first in the
process-classes phase).
2. Use maven-dependency-plugin's unpack
goal<http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html>to
extract those artifacts to ${project.build.outputDirectory} in the
process-classes phase after the above phase.
I think that'll do it for you.
On Sat, Mar 2, 2013 at 2:32 PM, Joachim Durchholz <jo...@durchholz.org> wrote:
> Hi all,
>
> I have two jars from an external source and need to merge their contents
> into the target/classes tree until the process-classes phase.
> I'm not sure what plugin(s) can be used to achieve this effect.
>
> Directory structure:
> - external (directory tree that holds the externally-provided files)
> - libs
> - cubes.jar (class files)
> - cubes-resources.jar (nonclass files)
> - license etc. (other data, irrelevant to task at hand)
> (yeah I know the structure sucks, can't do anything about it)
> - target (maven scratchpad)
> - classes (files for main artifact jar are collected here I think)
>
> I need the files inside libs/cubes.jar and libs/cubes-resource.jar
> unpacked and placed inside target/classes, preserving the in-jar directory
> structure.
>
> I want this to run in the process-classes, latest, because that's the last
> pertinent phase that m2e will run.
>
> What's the best (least-hassle) plugin that will do this?
>
> Regards,
> Jo
>
> P.S.: Please resist the temptation to tell me that I want the wrong thing.
> I need help with solving a problem, I don't need a lecture.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
mailto:matthew@matthewadams.me <ma...@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
Re: Unpacking jars into target/classes
Posted by Joachim Durchholz <jo...@durchholz.org>.
Thanks, somehow I overlooked the truezip plugin.
It should do the trick.
Regards,
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Tim Kettler <ti...@udo.edu>.
Am 02.03.2013 21:32, schrieb Joachim Durchholz:
> Hi all,
>
> I have two jars from an external source and need to merge their contents
> into the target/classes tree until the process-classes phase.
> I'm not sure what plugin(s) can be used to achieve this effect.
As wholeheartedly as I agree to all what was said about Maven being
opinionated (in a good way) and that one is best advised to stick to the
conventions, there are cases where you just can't... and in my
experience maven is quit good at handling these edge cases.
For the problem at hand, have a look at the truezip-m-p over at the
codehaus mojo project, it should provide what you want:
<properties>
<mylib1.archive>${project.basedir}/libs/lib1.jar</mylib1.archive>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>truezip-maven-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>copy-lib1-classes</id>
<goals>
<goal>copy</goal>
</goals>
<phase>process-classes</phase>
<configuration>
<fileset>
<directory>${mylib1.archive}</directory>
<includes>
<include>**/*</include>
</includes>
<excludes>
<exclude>META-INF/MANIFEST.MF</exclude>
</excludes>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
</fileset>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
> Directory structure:
> - external (directory tree that holds the externally-provided files)
> - libs
> - cubes.jar (class files)
> - cubes-resources.jar (nonclass files)
> - license etc. (other data, irrelevant to task at hand)
> (yeah I know the structure sucks, can't do anything about it)
> - target (maven scratchpad)
> - classes (files for main artifact jar are collected here I think)
>
> I need the files inside libs/cubes.jar and libs/cubes-resource.jar
> unpacked and placed inside target/classes, preserving the in-jar
> directory structure.
>
> I want this to run in the process-classes, latest, because that's the
> last pertinent phase that m2e will run.
>
> What's the best (least-hassle) plugin that will do this?
>
> Regards,
> Jo
-Tim
>
> P.S.: Please resist the temptation to tell me that I want the wrong
> thing. I need help with solving a problem, I don't need a lecture.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Unpacking jars into target/classes
Posted by Baptiste MATHUS <ml...@batmat.net>.
Don't think there's a plugin that does just that.
Maybe using an ugly combination of dependency:unpack (
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html)
and using a fake dependency using systemPath.
Or maybe using the assembly plugin.
Le 2 mars 2013 21:32, "Joachim Durchholz" <jo...@durchholz.org> a écrit :
>
> Hi all,
>
> I have two jars from an external source and need to merge their contents
> into the target/classes tree until the process-classes phase.
> I'm not sure what plugin(s) can be used to achieve this effect.
>
> Directory structure:
> - external (directory tree that holds the externally-provided files)
> - libs
> - cubes.jar (class files)
> - cubes-resources.jar (nonclass files)
> - license etc. (other data, irrelevant to task at hand)
> (yeah I know the structure sucks, can't do anything about it)
> - target (maven scratchpad)
> - classes (files for main artifact jar are collected here I think)
>
> I need the files inside libs/cubes.jar and libs/cubes-resource.jar
> unpacked and placed inside target/classes, preserving the in-jar directory
> structure.
>
> I want this to run in the process-classes, latest, because that's the last
> pertinent phase that m2e will run.
>
> What's the best (least-hassle) plugin that will do this?
>
> Regards,
> Jo
>
> P.S.: Please resist the temptation to tell me that I want the wrong thing.
> I need help with solving a problem, I don't need a lecture.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>