Re: http://repository.apache.org/ is down?

[Gary Gregory]

Up here is Sourthern Cal.

Gary

On Sun, Jun 7, 2015 at 5:41 PM, Dan Tran  wrote:

> Can someone confirm if http://repository.apache.org is down at your side?
>
> Thanks
>
> -Dan
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: http://repository.apache.org/ is down?

[Dan Tran]

It is back now in California

Thanks

-Dan

On Sun, Jun 7, 2015 at 5:47 PM, Igor Fedorenko  wrote:

> Nexus UI showed up from here (Toronto).
>
> --
> Regards,
> Igor
>
> On Sun, Jun 7, 2015, at 08:41 PM, Dan Tran wrote:
> > Can someone confirm if http://repository.apache.org is down at your
> side?
> >
> > Thanks
> >
> > -Dan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: http://repository.apache.org/ is down?

[Igor Fedorenko]

Nexus UI showed up from here (Toronto).

-- 
Regards,
Igor

On Sun, Jun 7, 2015, at 08:41 PM, Dan Tran wrote:
> Can someone confirm if http://repository.apache.org is down at your side?
> 
> Thanks
> 
> -Dan

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

http://repository.apache.org/ is down?

[Dan Tran]

Can someone confirm if http://repository.apache.org is down at your side?

Thanks

-Dan

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Robert Scholte]

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, version, etc. This was more about ordering / adding  
supllemental entries if i have provided an MANIFEST.MF file...reusing  
it...


Kind regards
Karl Heinz Marbaise
On 6/7/15 7:17 PM, Robert Scholte wrote:

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 want Build-OS as well (if that exists), but asking 'kama'
for additional info when required will do the trick as well.
These values shouldn't be copied from the specified MANIFEST.MF, since
*this* archive has probably been built with other values.

best,
Robert


Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise
:


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 entries:

My own file:

Manifest-Version: 1.0
Test: This is my MANUALLY CREATED MANIFEST FILE
Second: This is the second line.

After running through maven-jar-plugin you will get the following:

Manifest-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
and Build-Jdk entries. But nothing else if i use
my own MANIFEST.MF file.

Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
of the original entries which is based on the used implementation
(HashMap, Hashtable etc. which makes sense.

Wouldn't it be better to keep the original order of elements?

So based on what i can see we have handling of
manifest in maven-archiver component and in plexus-archiver ?



[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[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, version, etc. This was more about ordering / adding 
supllemental entries if i have provided an MANIFEST.MF file...reusing it...


Kind regards
Karl Heinz Marbaise
On 6/7/15 7:17 PM, Robert Scholte wrote:

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 want Build-OS as well (if that exists), but asking 'kama'
for additional info when required will do the trick as well.
These values shouldn't be copied from the specified MANIFEST.MF, since
*this* archive has probably been built with other values.

best,
Robert


Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise
:


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 entries:

My own file:

Manifest-Version: 1.0
Test: This is my MANUALLY CREATED MANIFEST FILE
Second: This is the second line.

After running through maven-jar-plugin you will get the following:

Manifest-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
and Build-Jdk entries. But nothing else if i use
my own MANIFEST.MF file.

Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
of the original entries which is based on the used implementation
(HashMap, Hashtable etc. which makes sense.

Wouldn't it be better to keep the original order of elements?

So based on what i can see we have handling of
manifest in maven-archiver component and in plexus-archiver ?



[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Kristian Rosenvold]

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-Version: Plexus Archiver
>
> I've hit several projects which I had to rebuild and this gave me enough
> info to do so.
> You actually want Build-OS as well (if that exists), but asking 'kama' for
> additional info when required will do the trick as well.
> These values shouldn't be copied from the specified MANIFEST.MF, since
> *this* archive has probably been built with other values.
>
> best,
> Robert
>
>
> Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise <
> khmarba...@gmx.de>:
>
>
>  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 entries:
>>
>> My own file:
>>
>> Manifest-Version: 1.0
>> Test: This is my MANUALLY CREATED MANIFEST FILE
>> Second: This is the second line.
>>
>> After running through maven-jar-plugin you will get the following:
>>
>> Manifest-Version: 1.0
>> Second: This is the second line.
>> Test: This is my MANUALLY CREATED MANIFEST FILE
>> Built-By: kama
>> Build-Jdk: 1.7.0_21
>> Created-By: Apache Maven 3.1.1
>> Archiver-Version: Plexus Archiver
>>
>>
>> There are comming up two questions:
>>
>> 1. Does it make sense to add only Manifest-Version
>> and Build-Jdk entries. But nothing else if i use
>> my own MANIFEST.MF file.
>>
>> Based on what i have read on [3] it would make sense.
>>
>>
>> 2. Currently the handling internally does not kepp the order
>> of the original entries which is based on the used implementation
>> (HashMap, Hashtable etc. which makes sense.
>>
>> Wouldn't it be better to keep the original order of elements?
>>
>> So based on what i can see we have handling of
>> manifest in maven-archiver component and in plexus-archiver ?
>>
>>
>>
>> [1] https://issues.apache.org/jira/browse/MJAR-195
>> [2] https://issues.apache.org/jira/browse/MJAR-193
>> [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[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-Version: Plexus Archiver

I've hit several projects which I had to rebuild and this gave me enough  
info to do so.
You actually want Build-OS as well (if that exists), but asking 'kama' for  
additional info when required will do the trick as well.
These values shouldn't be copied from the specified MANIFEST.MF, since  
*this* archive has probably been built with other values.


best,
Robert


Op Sun, 07 Jun 2015 18:49:02 +0200 schreef Karl Heinz Marbaise  
:



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 entries:


My own file:

Manifest-Version: 1.0
Test: This is my MANUALLY CREATED MANIFEST FILE
Second: This is the second line.

After running through maven-jar-plugin you will get the following:

Manifest-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
and Build-Jdk entries. But nothing else if i use
my own MANIFEST.MF file.

Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
of the original entries which is based on the used implementation
(HashMap, Hashtable etc. which makes sense.

Wouldn't it be better to keep the original order of elements?

So based on what i can see we have handling of
manifest in maven-archiver component and in plexus-archiver ?



[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Kristian Rosenvold]

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 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
>
> About adding entries. I could understand that two entries like
> Manifest-version and Build-Jdk would be added (but may be best not by
> default) controlled by options...
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[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 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


About adding entries. I could understand that two entries like 
Manifest-version and Build-Jdk would be added (but may be best not by 
default) controlled by options...


Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Kristian Rosenvold]

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
support for toolchain layering in the spec. Thats my 2 NOK.

Additionally it follows map semantics, last present value wins. When we
switched from the "old" plexus manifest to using the jdk manifest we "lost"
the ordering, since the jdk manifest class does not support ordering.

I have been trying to decide for myself if we're mostly talking about
people scratching their OCD and theoretical use cases here. To this date I
have yet to see anything that really convinces me otherwise.

Kristian




2015-06-07 18:57 GMT+02:00 Igor Fedorenko :

> 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 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 entries:
> > >
> > > My own file:
> > >
> > > Manifest-Version: 1.0
> > > Test: This is my MANUALLY CREATED MANIFEST FILE
> > > Second: This is the second line.
> > >
> > > After running through maven-jar-plugin you will get the following:
> > >
> > > Manifest-Version: 1.0
> > > Second: This is the second line.
> > > Test: This is my MANUALLY CREATED MANIFEST FILE
> > > Built-By: kama
> > > Build-Jdk: 1.7.0_21
> > > Created-By: Apache Maven 3.1.1
> > > Archiver-Version: Plexus Archiver
> > >
> > >
> > > There are comming up two questions:
> > >
> > > 1. Does it make sense to add only Manifest-Version
> > > and Build-Jdk entries. But nothing else if i use
> > > my own MANIFEST.MF file.
> > >
> > > Based on what i have read on [3] it would make sense.
> > >
> > >
> > > 2. Currently the handling internally does not kepp the order
> > > of the original entries which is based on the used implementation
> > > (HashMap, Hashtable etc. which makes sense.
> > >
> > > Wouldn't it be better to keep the original order of elements?
> > >
> > > So based on what i can see we have handling of
> > > manifest in maven-archiver component and in plexus-archiver ?
> >
> >
> > One more thing. If the MANIFEST contains sections these will be
> > broken...which is my opionion a real bug...
> >
> >
> > >
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/MJAR-195
> > > [2] https://issues.apache.org/jira/browse/MJAR-193
> > > [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> >
> > Mit freundlichem Gruß
> > Karl-Heinz Marbaise
> > --
> > SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> > Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> > Hauptstrasse 177
> > 52146 Würselen   http://www.soebes.de
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Eric Lilja]

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.




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Igor Fedorenko]

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 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 entries:
> >
> > My own file:
> >
> > Manifest-Version: 1.0
> > Test: This is my MANUALLY CREATED MANIFEST FILE
> > Second: This is the second line.
> >
> > After running through maven-jar-plugin you will get the following:
> >
> > Manifest-Version: 1.0
> > Second: This is the second line.
> > Test: This is my MANUALLY CREATED MANIFEST FILE
> > Built-By: kama
> > Build-Jdk: 1.7.0_21
> > Created-By: Apache Maven 3.1.1
> > Archiver-Version: Plexus Archiver
> >
> >
> > There are comming up two questions:
> >
> > 1. Does it make sense to add only Manifest-Version
> > and Build-Jdk entries. But nothing else if i use
> > my own MANIFEST.MF file.
> >
> > Based on what i have read on [3] it would make sense.
> >
> >
> > 2. Currently the handling internally does not kepp the order
> > of the original entries which is based on the used implementation
> > (HashMap, Hashtable etc. which makes sense.
> >
> > Wouldn't it be better to keep the original order of elements?
> >
> > So based on what i can see we have handling of
> > manifest in maven-archiver component and in plexus-archiver ?
> 
> 
> One more thing. If the MANIFEST contains sections these will be 
> broken...which is my opionion a real bug...
> 
> 
> >
> >
> >
> > [1] https://issues.apache.org/jira/browse/MJAR-195
> > [2] https://issues.apache.org/jira/browse/MJAR-193
> > [3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 
> 
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> -- 
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen   http://www.soebes.de
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Karl Heinz Marbaise]

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/MANIFEST.MF) it will be
extended by several entries:

My own file:

Manifest-Version: 1.0
Test: This is my MANUALLY CREATED MANIFEST FILE
Second: This is the second line.

After running through maven-jar-plugin you will get the following:

Manifest-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
and Build-Jdk entries. But nothing else if i use
my own MANIFEST.MF file.

Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
of the original entries which is based on the used implementation
(HashMap, Hashtable etc. which makes sense.

Wouldn't it be better to keep the original order of elements?

So based on what i can see we have handling of
manifest in maven-archiver component and in plexus-archiver ?



One more thing. If the MANIFEST contains sections these will be 
broken...which is my opionion a real bug...







[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Karl Heinz Marbaise]

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 entries:


My own file:

Manifest-Version: 1.0
Test: This is my MANUALLY CREATED MANIFEST FILE
Second: This is the second line.

After running through maven-jar-plugin you will get the following:

Manifest-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
   and Build-Jdk entries. But nothing else if i use
   my own MANIFEST.MF file.

   Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
   of the original entries which is based on the used implementation
   (HashMap, Hashtable etc. which makes sense.

   Wouldn't it be better to keep the original order of elements?

   So based on what i can see we have handling of
   manifest in maven-archiver component and in plexus-archiver ?



[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MANIFEST Handling in maven-jar-plugin / maven-archiver / plexus-archiver

[Karl Heinz Marbaise]

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-Version: 1.0
Second: This is the second line.
Test: This is my MANUALLY CREATED MANIFEST FILE
Built-By: kama
Build-Jdk: 1.7.0_21
Created-By: Apache Maven 3.1.1
Archiver-Version: Plexus Archiver


There are comming up two questions:

1. Does it make sense to add only Manifest-Version
   and Build-Jdk entries. But nothing else if i use
   my own MANIFEST.MF file.

   Based on what i have read on [3] it would make sense.


2. Currently the handling internally does not kepp the order
   of the original entries which is based on the used implementation
   (HashMap, Hashtable etc. which makes sense.

   Wouldn't it be better to keep the original order of elements?





[1] https://issues.apache.org/jira/browse/MJAR-195
[2] https://issues.apache.org/jira/browse/MJAR-193
[3] https://docs.oracle.com/javase/tutorial/deployment/jar/defman.html

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4

[Karl Heinz Marbaise]

Hi,

On 6/7/15 12:15 PM, Karl Heinz Marbaise wrote:

Hi,

We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921&version=12331393


There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC


Staging repo:
https://repository.apache.org/content/repositories/maven-1189
https://repository.apache.org/content/repositories/maven-1189/org/apache/maven/plugins/maven-shade-plugin/2.4/maven-shade-plugin-2.4-source-release.zip


Source release checksum(s):
maven-shade-plugin-2.4-source-release.zip sha1:
2ffe5cb14f62410523a59f9eb1e181d78ad47659


Staging site:
http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/


Please use the us mirror cause there seemed to be a sync issue with eu 
mirror. So please use the following URL to access the new site:


http://maven.us.apache.org/plugins-archives/maven-shade-plugin-LATEST/

Already opened an issue at INFRA...

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: 3.0 versions in branches ?

[Robert Scholte]

I don't expect M2 specific changes on the shared component anymore, so I  
think we those projects are ready to be merged back to the trunk.

That is:
- maven-artifact-transfer
- maven-common-artifact-filters
- maven-dependency-tree

Let me do that the following period, including the creation of matching  
JIRA issues to trace back all changes


Robert

Op Sun, 07 Jun 2015 17:52:24 +0200 schreef Kristian Rosenvold  
:


And I appreciate your work a lot. I've got the assembly-plugin migration  
in

github and I'll just land that right on trunk once I'm happy with it.

Kristian


2015-06-07 17:35 GMT+02:00 Robert Scholte :


Hi,

I've made those branches to see how much work it is to drop M2 support  
and

to not lose my work.
And it is quite a lot. I still haven't covered everything.
I'm actually happy I didn't use the trunk for it, since now it was
possible to do a 2.x release of the maven-shade-plugin.

Now we're on it, for surefire the ArtifactResolver[1] needs to be  
replaced

for 3.0.
I still see activity for surefire-2.x, so I'll wait to work on those
changes until one has decided to go for 3.0

thanks,
Robert


http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49


Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold <
kristian.rosenv...@gmail.com>:

 Do we really need to keep the 3.0 versions in branches ? Can't we just

make
a branch if we need to fix something in the 2.x range ?

Kristian



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: 3.0 versions in branches ?

[Kristian Rosenvold]

And I appreciate your work a lot. I've got the assembly-plugin migration in
github and I'll just land that right on trunk once I'm happy with it.

Kristian


2015-06-07 17:35 GMT+02:00 Robert Scholte :

> Hi,
>
> I've made those branches to see how much work it is to drop M2 support and
> to not lose my work.
> And it is quite a lot. I still haven't covered everything.
> I'm actually happy I didn't use the trunk for it, since now it was
> possible to do a 2.x release of the maven-shade-plugin.
>
> Now we're on it, for surefire the ArtifactResolver[1] needs to be replaced
> for 3.0.
> I still see activity for surefire-2.x, so I'll wait to work on those
> changes until one has decided to go for 3.0
>
> thanks,
> Robert
>
>
> http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49
>
>
> Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold <
> kristian.rosenv...@gmail.com>:
>
>  Do we really need to keep the 3.0 versions in branches ? Can't we just
>> make
>> a branch if we need to fix something in the 2.x range ?
>>
>> Kristian
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: 3.0 versions in branches ?

[Robert Scholte]

Hi,

I've made those branches to see how much work it is to drop M2 support and  
to not lose my work.

And it is quite a lot. I still haven't covered everything.
I'm actually happy I didn't use the trunk for it, since now it was  
possible to do a 2.x release of the maven-shade-plugin.


Now we're on it, for surefire the ArtifactResolver[1] needs to be replaced  
for 3.0.
I still see activity for surefire-2.x, so I'll wait to work on those  
changes until one has decided to go for 3.0


thanks,
Robert

http://maven.apache.org/components/ref/3.0/maven-compat/xref/org/apache/maven/artifact/resolver/ArtifactResolver.html#49


Op Sun, 07 Jun 2015 14:45:24 +0200 schreef Kristian Rosenvold  
:


Do we really need to keep the 3.0 versions in branches ? Can't we just  
make

a branch if we need to fix something in the 2.x range ?

Kristian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: 3.0 versions in branches ?

[Stephen Connolly]

+1

On Sunday, June 7, 2015, Kristian Rosenvold 
wrote:

> Do we really need to keep the 3.0 versions in branches ? Can't we just make
> a branch if we need to fix something in the 2.x range ?
>
> Kristian
>


-- 
Sent from my phone

[GitHub] maven pull request: MNG-5837: Use a subshell, rather than the 'loc...

[josephw]

GitHub user josephw opened a pull request:

https://github.com/apache/maven/pull/50

MNG-5837: Use a subshell, rather than the 'local' keyword, for POSIX 
compliance

'local' is not POSIX, but supported by most shells. However, it's not
supported by Solaris's /bin/sh, so use a subshell instead.

Tested on OS X by invoking with `/bin/ksh`.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/josephw/maven 
MNG-5837-avoid-non-posix-local-keyword

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/50.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #50


commit 1efce60e0594f7445f946aeb34f89e36907fdaf1
Author: Joseph Walton 
Date:   2015-06-07T13:29:39Z

MNG-5837: Use a subshell, rather than the 'local' keyword, for POSIX 
compliance.

'local' is not POSIX, but supported by most shells. However, it's not
supported by Solaris's /bin/sh, so use a subshell instead.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

3.0 versions in branches ?

[Kristian Rosenvold]

Do we really need to keep the 3.0 versions in branches ? Can't we just make
a branch if we need to fix something in the 2.x range ?

Kristian

[VOTE] Release Apache Maven Shade Plugin version 2.4

[Karl Heinz Marbaise]

Hi,

We solved 14 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921&version=12331393

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1189
https://repository.apache.org/content/repositories/maven-1189/org/apache/maven/plugins/maven-shade-plugin/2.4/maven-shade-plugin-2.4-source-release.zip

Source release checksum(s):
maven-shade-plugin-2.4-source-release.zip sha1: 
2ffe5cb14f62410523a59f9eb1e181d78ad47659



Staging site:
http://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org