[all] Preventing assembly archives from being deployed to nexus.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[all] Preventing assembly archives from being deployed to nexus.

Rob Tompkins
Hello all,

In my work on the [build-plugin], I’ve come across the following mechanism to prevent the [maven-assembly-plugin] from deploying the artifacts to nexus. If in the configuration section of the plugin, you put “<attach>false</attach>” the archives that the [maven-assembly-plugin] creates will not get pushed up to nexus. For example I have locally in [text] the following:

 <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <configuration>
  <descriptors>
    <descriptor>src/assembly/bin.xml</descriptor>
                        <descriptor>src/assembly/src.xml</descriptor>
  </descriptors>
                <tarLongFileMode>gnu</tarLongFileMode>
  <attach>false</attach>
        </configuration>
</plugin>

and with that, using "-Ptest-deploy" profile, the archives aren’t pushed to "./target/deploy”.

As previously stated, my plan is to streamline the release process considerably with java updates to the build plugin, but for the time being, this should be helpful.

Cheers,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

garydgregory
Hi Rob,

Note that for Commons Daemon we do want to deploy the bin zip that contains
the Windows DLL/EXEs.

Some folks, like me, depend on it in order to include the Windows EXE/DLLs
in builds.

Gary

On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]> wrote:

> Hello all,
>
> In my work on the [build-plugin], I’ve come across the following mechanism
> to prevent the [maven-assembly-plugin] from deploying the artifacts to
> nexus. If in the configuration section of the plugin, you put
> “<attach>false</attach>” the archives that the [maven-assembly-plugin]
> creates will not get pushed up to nexus. For example I have locally in
> [text] the following:
>
>  <plugin>
>         <artifactId>maven-assembly-plugin</artifactId>
>         <configuration>
>                 <descriptors>
>                 <descriptor>src/assembly/bin.xml</descriptor>
>                         <descriptor>src/assembly/src.xml</descriptor>
>                 </descriptors>
>                 <tarLongFileMode>gnu</tarLongFileMode>
>                 <attach>false</attach>
>         </configuration>
> </plugin>
>
> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed
> to "./target/deploy”.
>
> As previously stated, my plan is to streamline the release process
> considerably with java updates to the build plugin, but for the time being,
> this should be helpful.
>
> Cheers,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

Charles Honton
In reply to this post by Rob Tompkins
I’ve been down this path about a year ago.  We’re relying on the side effect of these assemblies being artifacts for the GPG plugin to sign them.  There is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 <https://issues.apache.org/jira/browse/MGPG-43>) to support signing un-attached files.  Unfortunately, this was not sufficient.  The maven deploy plugin generates the md5/sha1/asc files.  I suggested adding this functionality to the GPG plugin.  The response (http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results <http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results>) was not positive.

The step to take now is to create a new plugin and work with the maven core team to accept a new plugin to support our use case.  Alternatively, we can change our release process to something similar to what the Maven team does.  There is native support for their process.

chas

> On Dec 2, 2017, at 1:06 PM, Rob Tompkins <[hidden email]> wrote:
>
> Hello all,
>
> In my work on the [build-plugin], I’ve come across the following mechanism to prevent the [maven-assembly-plugin] from deploying the artifacts to nexus. If in the configuration section of the plugin, you put “<attach>false</attach>” the archives that the [maven-assembly-plugin] creates will not get pushed up to nexus. For example I have locally in [text] the following:
>
> <plugin>
> <artifactId>maven-assembly-plugin</artifactId>
> <configuration>
>   <descriptors>
>     <descriptor>src/assembly/bin.xml</descriptor>
> <descriptor>src/assembly/src.xml</descriptor>
>   </descriptors>
> <tarLongFileMode>gnu</tarLongFileMode>
>   <attach>false</attach>
> </configuration>
> </plugin>
>
> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed to "./target/deploy”.
>
> As previously stated, my plan is to streamline the release process considerably with java updates to the build plugin, but for the time being, this should be helpful.
>
> Cheers,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

Rob Tompkins
In reply to this post by garydgregory


> On Dec 2, 2017, at 4:22 PM, Gary Gregory <[hidden email]> wrote:
>
> Hi Rob,
>
> Note that for Commons Daemon we do want to deploy the bin zip that contains
> the Windows DLL/EXEs.

Indeed, this would need to be done at a component level to accommodate just that. But, with Chas’ last email about signatures the point may be moot for the time being. I plan to start investigating that path.

Cheers,
-Rob

>
> Some folks, like me, depend on it in order to include the Windows EXE/DLLs
> in builds.
>
> Gary
>
> On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]> wrote:
>
>> Hello all,
>>
>> In my work on the [build-plugin], I’ve come across the following mechanism
>> to prevent the [maven-assembly-plugin] from deploying the artifacts to
>> nexus. If in the configuration section of the plugin, you put
>> “<attach>false</attach>” the archives that the [maven-assembly-plugin]
>> creates will not get pushed up to nexus. For example I have locally in
>> [text] the following:
>>
>> <plugin>
>>        <artifactId>maven-assembly-plugin</artifactId>
>>        <configuration>
>>                <descriptors>
>>                <descriptor>src/assembly/bin.xml</descriptor>
>>                        <descriptor>src/assembly/src.xml</descriptor>
>>                </descriptors>
>>                <tarLongFileMode>gnu</tarLongFileMode>
>>                <attach>false</attach>
>>        </configuration>
>> </plugin>
>>
>> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed
>> to "./target/deploy”.
>>
>> As previously stated, my plan is to streamline the release process
>> considerably with java updates to the build plugin, but for the time being,
>> this should be helpful.
>>
>> Cheers,
>> -Rob
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

garydgregory
On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins <[hidden email]> wrote:

>
>
> > On Dec 2, 2017, at 4:22 PM, Gary Gregory <[hidden email]> wrote:
> >
> > Hi Rob,
> >
> > Note that for Commons Daemon we do want to deploy the bin zip that
> contains
> > the Windows DLL/EXEs.
>
> Indeed, this would need to be done at a component level to accommodate
> just that. But, with Chas’ last email about signatures the point may be
> moot for the time being. I plan to start investigating that path.
>

If we do a new plugin, we should only generate SHA-512 hashes and do away
with MD5 and SHA-1.

Gary



>
> Cheers,
> -Rob
>
> >
> > Some folks, like me, depend on it in order to include the Windows
> EXE/DLLs
> > in builds.
> >
> > Gary
> >
> > On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]> wrote:
> >
> >> Hello all,
> >>
> >> In my work on the [build-plugin], I’ve come across the following
> mechanism
> >> to prevent the [maven-assembly-plugin] from deploying the artifacts to
> >> nexus. If in the configuration section of the plugin, you put
> >> “<attach>false</attach>” the archives that the [maven-assembly-plugin]
> >> creates will not get pushed up to nexus. For example I have locally in
> >> [text] the following:
> >>
> >> <plugin>
> >>        <artifactId>maven-assembly-plugin</artifactId>
> >>        <configuration>
> >>                <descriptors>
> >>                <descriptor>src/assembly/bin.xml</descriptor>
> >>                        <descriptor>src/assembly/src.xml</descriptor>
> >>                </descriptors>
> >>                <tarLongFileMode>gnu</tarLongFileMode>
> >>                <attach>false</attach>
> >>        </configuration>
> >> </plugin>
> >>
> >> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed
> >> to "./target/deploy”.
> >>
> >> As previously stated, my plan is to streamline the release process
> >> considerably with java updates to the build plugin, but for the time
> being,
> >> this should be helpful.
> >>
> >> Cheers,
> >> -Rob
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

Matt Sicker
I thought md5 files were required? Unless that's project-specific (or Maven
Central required?).

On 2 December 2017 at 17:07, Gary Gregory <[hidden email]> wrote:

> On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins <[hidden email]> wrote:
>
> >
> >
> > > On Dec 2, 2017, at 4:22 PM, Gary Gregory <[hidden email]>
> wrote:
> > >
> > > Hi Rob,
> > >
> > > Note that for Commons Daemon we do want to deploy the bin zip that
> > contains
> > > the Windows DLL/EXEs.
> >
> > Indeed, this would need to be done at a component level to accommodate
> > just that. But, with Chas’ last email about signatures the point may be
> > moot for the time being. I plan to start investigating that path.
> >
>
> If we do a new plugin, we should only generate SHA-512 hashes and do away
> with MD5 and SHA-1.
>
> Gary
>
>
>
> >
> > Cheers,
> > -Rob
> >
> > >
> > > Some folks, like me, depend on it in order to include the Windows
> > EXE/DLLs
> > > in builds.
> > >
> > > Gary
> > >
> > > On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]>
> wrote:
> > >
> > >> Hello all,
> > >>
> > >> In my work on the [build-plugin], I’ve come across the following
> > mechanism
> > >> to prevent the [maven-assembly-plugin] from deploying the artifacts to
> > >> nexus. If in the configuration section of the plugin, you put
> > >> “<attach>false</attach>” the archives that the [maven-assembly-plugin]
> > >> creates will not get pushed up to nexus. For example I have locally in
> > >> [text] the following:
> > >>
> > >> <plugin>
> > >>        <artifactId>maven-assembly-plugin</artifactId>
> > >>        <configuration>
> > >>                <descriptors>
> > >>                <descriptor>src/assembly/bin.xml</descriptor>
> > >>                        <descriptor>src/assembly/src.xml</descriptor>
> > >>                </descriptors>
> > >>                <tarLongFileMode>gnu</tarLongFileMode>
> > >>                <attach>false</attach>
> > >>        </configuration>
> > >> </plugin>
> > >>
> > >> and with that, using "-Ptest-deploy" profile, the archives aren’t
> pushed
> > >> to "./target/deploy”.
> > >>
> > >> As previously stated, my plan is to streamline the release process
> > >> considerably with java updates to the build plugin, but for the time
> > being,
> > >> this should be helpful.
> > >>
> > >> Cheers,
> > >> -Rob
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

garydgregory
MD5 is just a kind of hash, as is SHA-1. SHA-512 should reduces the odds of
collisions. IMO what matters is that we provide a hash for each file.

Gary

On Sat, Dec 2, 2017 at 4:26 PM, Matt Sicker <[hidden email]> wrote:

> I thought md5 files were required? Unless that's project-specific (or Maven
> Central required?).
>
> On 2 December 2017 at 17:07, Gary Gregory <[hidden email]> wrote:
>
> > On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins <[hidden email]> wrote:
> >
> > >
> > >
> > > > On Dec 2, 2017, at 4:22 PM, Gary Gregory <[hidden email]>
> > wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > Note that for Commons Daemon we do want to deploy the bin zip that
> > > contains
> > > > the Windows DLL/EXEs.
> > >
> > > Indeed, this would need to be done at a component level to accommodate
> > > just that. But, with Chas’ last email about signatures the point may be
> > > moot for the time being. I plan to start investigating that path.
> > >
> >
> > If we do a new plugin, we should only generate SHA-512 hashes and do away
> > with MD5 and SHA-1.
> >
> > Gary
> >
> >
> >
> > >
> > > Cheers,
> > > -Rob
> > >
> > > >
> > > > Some folks, like me, depend on it in order to include the Windows
> > > EXE/DLLs
> > > > in builds.
> > > >
> > > > Gary
> > > >
> > > > On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]>
> > wrote:
> > > >
> > > >> Hello all,
> > > >>
> > > >> In my work on the [build-plugin], I’ve come across the following
> > > mechanism
> > > >> to prevent the [maven-assembly-plugin] from deploying the artifacts
> to
> > > >> nexus. If in the configuration section of the plugin, you put
> > > >> “<attach>false</attach>” the archives that the
> [maven-assembly-plugin]
> > > >> creates will not get pushed up to nexus. For example I have locally
> in
> > > >> [text] the following:
> > > >>
> > > >> <plugin>
> > > >>        <artifactId>maven-assembly-plugin</artifactId>
> > > >>        <configuration>
> > > >>                <descriptors>
> > > >>                <descriptor>src/assembly/bin.xml</descriptor>
> > > >>                        <descriptor>src/assembly/src.
> xml</descriptor>
> > > >>                </descriptors>
> > > >>                <tarLongFileMode>gnu</tarLongFileMode>
> > > >>                <attach>false</attach>
> > > >>        </configuration>
> > > >> </plugin>
> > > >>
> > > >> and with that, using "-Ptest-deploy" profile, the archives aren’t
> > pushed
> > > >> to "./target/deploy”.
> > > >>
> > > >> As previously stated, my plan is to streamline the release process
> > > >> considerably with java updates to the build plugin, but for the time
> > > being,
> > > >> this should be helpful.
> > > >>
> > > >> Cheers,
> > > >> -Rob
> > > >> ------------------------------------------------------------
> ---------
> > > >> To unsubscribe, e-mail: [hidden email]
> > > >> For additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
>
> --
> Matt Sicker <[hidden email]>
>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

Matt Sicker
I mean from here: <https://www.apache.org/dev/release-distribution.html>

MD5 is a base requirement like the GPG signature is. Additional sha hashes
are useful, though. I usually generate SHA-256 or SHA-512 with a release if
I'm handling it manually.

On 2 December 2017 at 17:50, Gary Gregory <[hidden email]> wrote:

> MD5 is just a kind of hash, as is SHA-1. SHA-512 should reduces the odds of
> collisions. IMO what matters is that we provide a hash for each file.
>
> Gary
>
> On Sat, Dec 2, 2017 at 4:26 PM, Matt Sicker <[hidden email]> wrote:
>
> > I thought md5 files were required? Unless that's project-specific (or
> Maven
> > Central required?).
> >
> > On 2 December 2017 at 17:07, Gary Gregory <[hidden email]>
> wrote:
> >
> > > On Sat, Dec 2, 2017 at 3:51 PM, Rob Tompkins <[hidden email]>
> wrote:
> > >
> > > >
> > > >
> > > > > On Dec 2, 2017, at 4:22 PM, Gary Gregory <[hidden email]>
> > > wrote:
> > > > >
> > > > > Hi Rob,
> > > > >
> > > > > Note that for Commons Daemon we do want to deploy the bin zip that
> > > > contains
> > > > > the Windows DLL/EXEs.
> > > >
> > > > Indeed, this would need to be done at a component level to
> accommodate
> > > > just that. But, with Chas’ last email about signatures the point may
> be
> > > > moot for the time being. I plan to start investigating that path.
> > > >
> > >
> > > If we do a new plugin, we should only generate SHA-512 hashes and do
> away
> > > with MD5 and SHA-1.
> > >
> > > Gary
> > >
> > >
> > >
> > > >
> > > > Cheers,
> > > > -Rob
> > > >
> > > > >
> > > > > Some folks, like me, depend on it in order to include the Windows
> > > > EXE/DLLs
> > > > > in builds.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Dec 2, 2017 at 2:06 PM, Rob Tompkins <[hidden email]>
> > > wrote:
> > > > >
> > > > >> Hello all,
> > > > >>
> > > > >> In my work on the [build-plugin], I’ve come across the following
> > > > mechanism
> > > > >> to prevent the [maven-assembly-plugin] from deploying the
> artifacts
> > to
> > > > >> nexus. If in the configuration section of the plugin, you put
> > > > >> “<attach>false</attach>” the archives that the
> > [maven-assembly-plugin]
> > > > >> creates will not get pushed up to nexus. For example I have
> locally
> > in
> > > > >> [text] the following:
> > > > >>
> > > > >> <plugin>
> > > > >>        <artifactId>maven-assembly-plugin</artifactId>
> > > > >>        <configuration>
> > > > >>                <descriptors>
> > > > >>                <descriptor>src/assembly/bin.xml</descriptor>
> > > > >>                        <descriptor>src/assembly/src.
> > xml</descriptor>
> > > > >>                </descriptors>
> > > > >>                <tarLongFileMode>gnu</tarLongFileMode>
> > > > >>                <attach>false</attach>
> > > > >>        </configuration>
> > > > >> </plugin>
> > > > >>
> > > > >> and with that, using "-Ptest-deploy" profile, the archives aren’t
> > > pushed
> > > > >> to "./target/deploy”.
> > > > >>
> > > > >> As previously stated, my plan is to streamline the release process
> > > > >> considerably with java updates to the build plugin, but for the
> time
> > > > being,
> > > > >> this should be helpful.
> > > > >>
> > > > >> Cheers,
> > > > >> -Rob
> > > > >> ------------------------------------------------------------
> > ---------
> > > > >> To unsubscribe, e-mail: [hidden email]
> > > > >> For additional commands, e-mail: [hidden email]
> > > > >>
> > > > >>
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Matt Sicker <[hidden email]>
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

Rob Tompkins
In reply to this post by Charles Honton


> On Dec 2, 2017, at 4:42 PM, Charles Honton <[hidden email]> wrote:
>
> I’ve been down this path about a year ago.  We’re relying on the side effect of these assemblies being artifacts for the GPG plugin to sign them.  There is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 <https://issues.apache.org/jira/browse/MGPG-43>) to support signing un-attached files.  Unfortunately, this was not sufficient.  The maven deploy plugin generates the md5/sha1/asc files.  I suggested adding this functionality to the GPG plugin.  The response (http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results <http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results>) was not positive.

Ugh. This sounds like an unfortunate situation. Many thanks for those insights. You’ve definitely saved me a week of figuring that out.

>
> The step to take now is to create a new plugin and work with the maven core team to accept a new plugin to support our use case.  Alternatively, we can change our release process to something similar to what the Maven team does.  There is native support for their process.

I’ll try to read their documentation on their release process.

-Rob

>
> chas
>
>> On Dec 2, 2017, at 1:06 PM, Rob Tompkins <[hidden email]> wrote:
>>
>> Hello all,
>>
>> In my work on the [build-plugin], I’ve come across the following mechanism to prevent the [maven-assembly-plugin] from deploying the artifacts to nexus. If in the configuration section of the plugin, you put “<attach>false</attach>” the archives that the [maven-assembly-plugin] creates will not get pushed up to nexus. For example I have locally in [text] the following:
>>
>> <plugin>
>> <artifactId>maven-assembly-plugin</artifactId>
>> <configuration>
>> <descriptors>
>>   <descriptor>src/assembly/bin.xml</descriptor>
>> <descriptor>src/assembly/src.xml</descriptor>
>> </descriptors>
>> <tarLongFileMode>gnu</tarLongFileMode>
>> <attach>false</attach>
>> </configuration>
>> </plugin>
>>
>> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed to "./target/deploy”.
>>
>> As previously stated, my plan is to streamline the release process considerably with java updates to the build plugin, but for the time being, this should be helpful.
>>
>> Cheers,
>> -Rob
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all] Preventing assembly archives from being deployed to nexus.

sebb-2-2
On 3 December 2017 at 01:32, Rob Tompkins <[hidden email]> wrote:

>
>
>> On Dec 2, 2017, at 4:42 PM, Charles Honton <[hidden email]> wrote:
>>
>> I’ve been down this path about a year ago.  We’re relying on the side effect of these assemblies being artifacts for the GPG plugin to sign them.  There is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 <https://issues.apache.org/jira/browse/MGPG-43>) to support signing un-attached files.  Unfortunately, this was not sufficient.  The maven deploy plugin generates the md5/sha1/asc files.  I suggested adding this functionality to the GPG plugin.  The response (http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results <http://maven-dev.markmail.org/search/?q=MGPG-43#query:MGPG-43+page:1+mid:6huxvhef5rzmzmsh+state:results>) was not positive.
>
> Ugh. This sounds like an unfortunate situation. Many thanks for those insights. You’ve definitely saved me a week of figuring that out.
>
>>
>> The step to take now is to create a new plugin and work with the maven core team to accept a new plugin to support our use case.  Alternatively, we can change our release process to something similar to what the Maven team does.  There is native support for their process.
>
> I’ll try to read their documentation on their release process.

Another approach I tried a while back (*) is to keep the current deploy process.
I.e. deploy the ASF mirror artefacts to Nexus along with the rest.
This ensures that the non-Maven zips are created and signed under target

An additional stage then copies the ASF archives/sigs/hashes from
target/ to dist/dev/commons using svnmucc.

Optionally the Nexus directory can be tidied up to remove the
unnecessary archives/sigs/hashes
Ideally they would be excluded from the upload so this was not
necessary, but that could be part of a separate effort.

(*) http://svn.apache.org/repos/asf/commons/sandbox/commons-staging-plugin/trunk/

> -Rob
>
>>
>> chas
>>
>>> On Dec 2, 2017, at 1:06 PM, Rob Tompkins <[hidden email]> wrote:
>>>
>>> Hello all,
>>>
>>> In my work on the [build-plugin], I’ve come across the following mechanism to prevent the [maven-assembly-plugin] from deploying the artifacts to nexus. If in the configuration section of the plugin, you put “<attach>false</attach>” the archives that the [maven-assembly-plugin] creates will not get pushed up to nexus. For example I have locally in [text] the following:
>>>
>>> <plugin>
>>>      <artifactId>maven-assembly-plugin</artifactId>
>>>      <configuration>
>>>              <descriptors>
>>>              <descriptor>src/assembly/bin.xml</descriptor>
>>>                      <descriptor>src/assembly/src.xml</descriptor>
>>>              </descriptors>
>>>              <tarLongFileMode>gnu</tarLongFileMode>
>>>              <attach>false</attach>
>>>      </configuration>
>>> </plugin>
>>>
>>> and with that, using "-Ptest-deploy" profile, the archives aren’t pushed to "./target/deploy”.
>>>
>>> As previously stated, my plan is to streamline the release process considerably with java updates to the build plugin, but for the time being, this should be helpful.
>>>
>>> Cheers,
>>> -Rob
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]