I see. In that case Kristian is right: it's a bug.
Op Sun, 07 Jun 2015 19:33:03 +0200 schreef Karl Heinz Marbaise
:
Hi,
i wasn't discussing what kind of entries / attributes whould be
helpfull...
In my current builds i have much more information in there like groupId,
artifactId, versio
Hi,
i wasn't discussing what kind of entries / attributes whould be helpfull...
In my current builds i have much more information in there like groupId,
artifactId, version, etc. This was more about ordering / adding
supllemental entries if i have provided an MANIFEST.MF file...reusing it...
The sections should be preserved though, so that's definitely a bug.
K
2015-06-07 19:17 GMT+02:00 Robert Scholte :
> The following attributes are very handsome to be able to reproduce a build
> based on sources
>
> Built-By: kama
> Build-Jdk: 1.7.0_21
> Created-By: Apache Maven 3.1.1
> Archiver
The following attributes are very handsome to be able to reproduce a build
based on sources
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver
I've hit several projects which I had to rebuild and this gave me enough
info to do so.
You actually
S; if you cannot add a class-path element to the manifest then ? You're
wrong.
Kristian
2015-06-07 19:09 GMT+02:00 Karl Heinz Marbaise :
> Hi Igor,
>
>
> On 6/7/15 6:57 PM, Igor Fedorenko wrote:
>
>> If I provide custom jar manifest, I expect the manifest to be used
>> as-is, without anythi
Hi Igor,
On 6/7/15 6:57 PM, Igor Fedorenko wrote:
If I provide custom jar manifest, I expect the manifest to be used
as-is, without anything added, removed or reordered. Just my 2 kopecks.
That's exactly what i would expect...but in all our components / plugins
it works different
Abou
The jar specification says explicitly that "Attributes which are not
understood are ignored."; I interpret this to mean it's ok for every man
and his dog to add values. Which I think means that you should expect your
*values* to win, not necessarily your particular file - there's an implicit
suppor
Indeed, I would not expect to having my provided manifest modified at all.
On 2015-06-07 18:57, Igor Fedorenko wrote:
If I provide custom jar manifest, I expect the manifest to be used
as-is, without anything added, removed or reordered. Just my 2 kopecks.
---
If I provide custom jar manifest, I expect the manifest to be used
as-is, without anything added, removed or reordered. Just my 2 kopecks.
--
Regards,
Igor
On Sun, Jun 7, 2015, at 12:50 PM, Karl Heinz Marbaise wrote:
> On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote:
> > Sorry was too fast with my
On 6/7/15 6:49 PM, Karl Heinz Marbaise wrote:
Sorry was too fast with my send button...
Hi,
at the moment i trying to dive into handling of MANIFEST.MF file [1],
[2]...
If i create a MANIFEST.MF my own and let maven-jar-plugin take that file
via useDefaultManifest (target/classes/META-INF/MAN
Sorry was too fast with my send button...
Hi,
at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]...
If i create a MANIFEST.MF my own and let maven-jar-plugin take that file
via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be
extended by several entr
Hi,
at the moment i trying to dive into handling of MANIFEST.MF file [1], [2]...
If i create a MANIFEST.MF my own and let maven-jar-plugin take that file
via useDefaultManifest (target/classes/META-INF/MANIFEST.MF) it will be
extended by several entries:
My own file:
For example:
Manifest
12 matches
Mail list logo
