You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Alejandro Abdelnur <tu...@cloudera.com> on 2014/01/31 01:43:29 UTC
Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
[Cross-posting with https://issues.apache.org/jira/browse/HADOOP-10313]
OK, we have:
* A script, create-release.sh, that creates release artifacts
* An Apache Jenkins job that runs the script and produces the artifacts in
Apache CI machines, thanks Yahoo! (or shouldn't I say that?)
The Apache Jenkins job is:
https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder/
There you'll see the output of an release build. When triggering the build,
you can specify an RC_LABEL (RC0 in this case). If you do so all the
artifact files will be postfixed with it.
The job is currently producing:
* RAT report
* SOURCE tarball and its MD5
* BINARY tarball and its MD5
* SITE tarball (ready to plaster in Apache Hadoop site)
* CHANGES files
I've verified the produced SOURCE is correct and I can build a BINARY out
of it.
I've verified the produced BINARY tarball works (in pseudo-cluster mode).
Running 'hadoop-version' from the BINARY a tarball reports:
----
$ bin/hadoop version
Hadoop 2.4.0-SNAPSHOT
Subversion http://svn.apache.org/repos/asf/hadoop/common -r 1563020
Compiled by jenkins on 2014-01-31T00:03Z
Compiled with protoc 2.5.0
>From source with checksum 37ccb6f84b23196f521243fd192070
----
Once the JIRA is committed we have to modify the Jenkins job to use the
script from 'dev-support/' directory.
We could improve this script further to deploy the built JARs to the Maven
repo. I don't know how to do this, so it would be great if somebody that
know how jumps on that. Maybe a s a follow up JIRA, so we have something
going.
Thanks.
On Thu, Jan 30, 2014 at 8:43 AM, Andrew Purtell <ap...@apache.org> wrote:
> The Apache Software Foundation takes branding seriously, we all know this.
> Making an inquiry about a possible, and I believe unintended, mis-branding
> issue involving Apache Hadoop artifacts is not a personal assault. The
> hysterical responses here have been unprofessional and disgraceful, and
> only serve to reinforce the notion people have outside your walls that you
> can't be bothered to treat the larger community with respect. That is not a
> petty issue I assure you.
>
>
> On Wed, Jan 29, 2014 at 7:31 PM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
>
> >
> > Stack,
> >
> > Apologies for the late response, I just saw this.
> >
> > On Jan 29, 2014, at 3:33 PM, Stack <st...@duboce.net> wrote:
> >
> > > Slightly related, I just ran into this looking back at my 2.2.0
> download:
> > >
> > > [stack@c2020 hadoop-2.2.0]$ ./bin/hadoop version
> > > Hadoop 2.2.0
> > > Subversion https://svn.apache.org/repos/asf/hadoop/common -r 1529768
> > > Compiled by hortonmu on 2013-10-07T06:28Z
> > > ...
> > >
> > > Does the apache binary have to be compiled by 'hortonmu'? Could it be
> > > compiled by 'arun', or 'apachemu'?
> > >
> > > Thanks,
> > > St.Ack
> >
> > Thank you for tarring all my work here with a brush by insinuating not
> > sure what for using my company provided dev machine to work on Hadoop.
> >
> > I'll try find a non-company provided dev machine to create future
> builds,
> > it might take some time because I'll have to go purchase another one. Or,
> > maybe, another option is to legally change my name.
> >
> > Meanwhile, while we are on this topic, I just did:
> >
> > $ git clone git://git.apache.org/hbase.git
> > $ grep -ri cloudera *
> >
> > Should I file a jira to fix all refs including the following imports of
> > org.cloudera.* (pasted below) ... can you please help fix that? There are
> > more, but I'll leave it to your discretion. Compared to my username on my
> > company provided dev. box, this seems far more egregious. Do you agree?
> >
> > In future, it might be useful to focus our efforts on moving the project
> > forward by contributing/reviewing code/docs etc., rather than on petty
> > things like usernames.
> >
> > thanks,
> > Arun
> >
> >
> >
> hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/RecoverableZooKeeper.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/RecoverableZooKeeper.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/mapreduce/IntegrationTestImportTsv.java:
> > org.cloudera.htrace.Trace.class); // HTrace
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/mttr/IntegrationTestMTTR.java:import
> > org.cloudera.htrace.impl.AlwaysSampler;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/trace/IntegrationTestSendTraceRequests.java:import
> > org.cloudera.htrace.Sampler;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/trace/IntegrationTestSendTraceRequests.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/trace/IntegrationTestSendTraceRequests.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-it/src/test/java/org/apache/hadoop/hbase/trace/IntegrationTestSendTraceRequests.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderV2.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/CallRunner.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/CallRunner.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RequestContext.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java:import
> > org.cloudera.htrace.TraceInfo;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableMapReduceUtil.java:
> > org.cloudera.htrace.Trace.class);
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/DisableTableHandler.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/EnableTableHandler.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreFlusher.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ShutdownHook.java:
> > // cloudera 0.20. 0.21 and cloudera 0.20 both have hadoop-4829.
> With
> > the
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ShutdownHook.java:
> > // on 0.21 or cloudera patched 0.20.
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ShutdownHook.java:
> > * 0.21 and cloudera patched hadoop to make sure our shutdown hook
> handling
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/RingBufferTruck.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/trace/HBaseHTraceConfiguration.java:import
> > org.cloudera.htrace.HTraceConfiguration;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/trace/SpanReceiverHost.java:import
> > org.cloudera.htrace.SpanReceiver;
> >
> hbase-server/src/main/java/org/apache/hadoop/hbase/trace/SpanReceiverHost.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.Sampler;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.Span;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.Trace;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.TraceScope;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.TraceTree;
> >
> hbase-server/src/test/java/org/apache/hadoop/hbase/trace/TestHTraceHooks.java:import
> > org.cloudera.htrace.impl.POJOSpanReceiver;
> > hbase-shell/src/main/ruby/shell/commands/trace.rb:java_import
> > org.cloudera.htrace.Sampler
> >
> >
> > --
> > Arun C. Murthy
> > Hortonworks Inc.
> > http://hortonworks.com/
> >
> >
> >
> > --
> > CONFIDENTIALITY NOTICE
> > NOTICE: This message is intended for the use of the individual or entity
> to
> > which it is addressed and may contain information that is confidential,
> > privileged and exempt from disclosure under applicable law. If the reader
> > of this message is not the intended recipient, you are hereby notified
> that
> > any printing, copying, dissemination, distribution, disclosure or
> > forwarding of this communication is strictly prohibited. If you have
> > received this communication in error, please contact the sender
> immediately
> > and delete it from your system. Thank You.
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Alejandro
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 30, 2014 at 5:05 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> I agree on not auto-signing (the script does not do it, on purpose).
>
> I was referring to deploying release artifact JARs.
Right. And my answer then would be -- please don't do that.
> OK, then we are done then.
Sounds like it.
Thanks,
Roman.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 30, 2014 at 5:05 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> I agree on not auto-signing (the script does not do it, on purpose).
>
> I was referring to deploying release artifact JARs.
Right. And my answer then would be -- please don't do that.
> OK, then we are done then.
Sounds like it.
Thanks,
Roman.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
I agree on not auto-signing (the script does not do it, on purpose).
I was referring to deploying release artifact JARs.
OK, then we are done then.
Thanks.
On Thu, Jan 30, 2014 at 5:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
> > We could improve this script further to deploy the built JARs to the
> Maven
> > repo. I don't know how to do this, so it would be great if somebody that
> > know how jumps on that. Maybe a s a follow up JIRA, so we have something
> > going.
>
> If you're talking about -SNAPSHOT bits -- there's nothing to do. All
> official
> build slaves on builds.apache.org are supposed to be setup with the
> right configs so that mvn deploy will do the trick. If you're talking about
> release artifacts -- it is absolutely NOT a good idea to automate that.
> Just like its not a good idea to automate signing the release bits with
> your personal key.
>
> Thanks,
> Roman.
>
--
Alejandro
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
I agree on not auto-signing (the script does not do it, on purpose).
I was referring to deploying release artifact JARs.
OK, then we are done then.
Thanks.
On Thu, Jan 30, 2014 at 5:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
> > We could improve this script further to deploy the built JARs to the
> Maven
> > repo. I don't know how to do this, so it would be great if somebody that
> > know how jumps on that. Maybe a s a follow up JIRA, so we have something
> > going.
>
> If you're talking about -SNAPSHOT bits -- there's nothing to do. All
> official
> build slaves on builds.apache.org are supposed to be setup with the
> right configs so that mvn deploy will do the trick. If you're talking about
> release artifacts -- it is absolutely NOT a good idea to automate that.
> Just like its not a good idea to automate signing the release bits with
> your personal key.
>
> Thanks,
> Roman.
>
--
Alejandro
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Steve Loughran <st...@hortonworks.com>.
FWIW I've used a (local) VM for releases in the past, a VM with read-only
access to the repository, that was never used for development
-lets you lock down the box more
-guarantees src is untainted by edits
-lets you run a release build/test run within the VM while you are still
coding, without any interference
-lets you do an rm -rf ~/.m2 ~/.ivy before the build
-lets people with windows desktops cut a release
weaknesses?
-Slower IO
-All changes to things like release notes need to be done local &
propagated via SVN
-if you do want auto-publish via scp, VM needs your private key without a
password. We created a special user @sourceforge for this
-usual brittleness of a VM that is only used once every month to changes
-after the yum update things may break, the wrong version of java creep in,
etc. That has to be included in the schedule.
-once you share the VMs by copying disk images the maintenance cost is
O(VM-instances)
-automated releases can get you complacent about shipping things without
doing the full install tests (on other (clean) VMs)
-when you did run the fully distributed test harness, it would certainly
pick up on things like concurrency and network problems, but it did nothing
to help you actually track down the issue (
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/components/arithmetic-testharness/src/org/smartfrog/services/slp/
)
that release process in full:
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/release/doc/creating_release_artifacts.pdf?format=raw
-Steve
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
I agree on not auto-signing (the script does not do it, on purpose).
I was referring to deploying release artifact JARs.
OK, then we are done then.
Thanks.
On Thu, Jan 30, 2014 at 5:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
> > We could improve this script further to deploy the built JARs to the
> Maven
> > repo. I don't know how to do this, so it would be great if somebody that
> > know how jumps on that. Maybe a s a follow up JIRA, so we have something
> > going.
>
> If you're talking about -SNAPSHOT bits -- there's nothing to do. All
> official
> build slaves on builds.apache.org are supposed to be setup with the
> right configs so that mvn deploy will do the trick. If you're talking about
> release artifacts -- it is absolutely NOT a good idea to automate that.
> Just like its not a good idea to automate signing the release bits with
> your personal key.
>
> Thanks,
> Roman.
>
--
Alejandro
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Steve Loughran <st...@hortonworks.com>.
FWIW I've used a (local) VM for releases in the past, a VM with read-only
access to the repository, that was never used for development
-lets you lock down the box more
-guarantees src is untainted by edits
-lets you run a release build/test run within the VM while you are still
coding, without any interference
-lets you do an rm -rf ~/.m2 ~/.ivy before the build
-lets people with windows desktops cut a release
weaknesses?
-Slower IO
-All changes to things like release notes need to be done local &
propagated via SVN
-if you do want auto-publish via scp, VM needs your private key without a
password. We created a special user @sourceforge for this
-usual brittleness of a VM that is only used once every month to changes
-after the yum update things may break, the wrong version of java creep in,
etc. That has to be included in the schedule.
-once you share the VMs by copying disk images the maintenance cost is
O(VM-instances)
-automated releases can get you complacent about shipping things without
doing the full install tests (on other (clean) VMs)
-when you did run the fully distributed test harness, it would certainly
pick up on things like concurrency and network problems, but it did nothing
to help you actually track down the issue (
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/components/arithmetic-testharness/src/org/smartfrog/services/slp/
)
that release process in full:
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/release/doc/creating_release_artifacts.pdf?format=raw
-Steve
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Alejandro Abdelnur <tu...@cloudera.com>.
I agree on not auto-signing (the script does not do it, on purpose).
I was referring to deploying release artifact JARs.
OK, then we are done then.
Thanks.
On Thu, Jan 30, 2014 at 5:02 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com>
> wrote:
> > We could improve this script further to deploy the built JARs to the
> Maven
> > repo. I don't know how to do this, so it would be great if somebody that
> > know how jumps on that. Maybe a s a follow up JIRA, so we have something
> > going.
>
> If you're talking about -SNAPSHOT bits -- there's nothing to do. All
> official
> build slaves on builds.apache.org are supposed to be setup with the
> right configs so that mvn deploy will do the trick. If you're talking about
> release artifacts -- it is absolutely NOT a good idea to automate that.
> Just like its not a good idea to automate signing the release bits with
> your personal key.
>
> Thanks,
> Roman.
>
--
Alejandro
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Steve Loughran <st...@hortonworks.com>.
FWIW I've used a (local) VM for releases in the past, a VM with read-only
access to the repository, that was never used for development
-lets you lock down the box more
-guarantees src is untainted by edits
-lets you run a release build/test run within the VM while you are still
coding, without any interference
-lets you do an rm -rf ~/.m2 ~/.ivy before the build
-lets people with windows desktops cut a release
weaknesses?
-Slower IO
-All changes to things like release notes need to be done local &
propagated via SVN
-if you do want auto-publish via scp, VM needs your private key without a
password. We created a special user @sourceforge for this
-usual brittleness of a VM that is only used once every month to changes
-after the yum update things may break, the wrong version of java creep in,
etc. That has to be included in the schedule.
-once you share the VMs by copying disk images the maintenance cost is
O(VM-instances)
-automated releases can get you complacent about shipping things without
doing the full install tests (on other (clean) VMs)
-when you did run the fully distributed test harness, it would certainly
pick up on things like concurrency and network problems, but it did nothing
to help you actually track down the issue (
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/components/arithmetic-testharness/src/org/smartfrog/services/slp/
)
that release process in full:
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/release/doc/creating_release_artifacts.pdf?format=raw
-Steve
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Steve Loughran <st...@hortonworks.com>.
FWIW I've used a (local) VM for releases in the past, a VM with read-only
access to the repository, that was never used for development
-lets you lock down the box more
-guarantees src is untainted by edits
-lets you run a release build/test run within the VM while you are still
coding, without any interference
-lets you do an rm -rf ~/.m2 ~/.ivy before the build
-lets people with windows desktops cut a release
weaknesses?
-Slower IO
-All changes to things like release notes need to be done local &
propagated via SVN
-if you do want auto-publish via scp, VM needs your private key without a
password. We created a special user @sourceforge for this
-usual brittleness of a VM that is only used once every month to changes
-after the yum update things may break, the wrong version of java creep in,
etc. That has to be included in the schedule.
-once you share the VMs by copying disk images the maintenance cost is
O(VM-instances)
-automated releases can get you complacent about shipping things without
doing the full install tests (on other (clean) VMs)
-when you did run the fully distributed test harness, it would certainly
pick up on things like concurrency and network problems, but it did nothing
to help you actually track down the issue (
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/components/arithmetic-testharness/src/org/smartfrog/services/slp/
)
that release process in full:
http://sourceforge.net/p/smartfrog/svn/HEAD/tree/trunk/core/release/doc/creating_release_artifacts.pdf?format=raw
-Steve
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Roman Shaposhnik <rv...@apache.org>.
On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> We could improve this script further to deploy the built JARs to the Maven
> repo. I don't know how to do this, so it would be great if somebody that
> know how jumps on that. Maybe a s a follow up JIRA, so we have something
> going.
If you're talking about -SNAPSHOT bits -- there's nothing to do. All official
build slaves on builds.apache.org are supposed to be setup with the
right configs so that mvn deploy will do the trick. If you're talking about
release artifacts -- it is absolutely NOT a good idea to automate that.
Just like its not a good idea to automate signing the release bits with
your personal key.
Thanks,
Roman.
Re: Apache jenkins job to build release artifacts (WAS: Issue with my
username on my company provided dev box?)
Posted by Roman Shaposhnik <rv...@apache.org>.
On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur <tu...@cloudera.com> wrote:
> We could improve this script further to deploy the built JARs to the Maven
> repo. I don't know how to do this, so it would be great if somebody that
> know how jumps on that. Maybe a s a follow up JIRA, so we have something
> going.
If you're talking about -SNAPSHOT bits -- there's nothing to do. All official
build slaves on builds.apache.org are supposed to be setup with the
right configs so that mvn deploy will do the trick. If you're talking about
release artifacts -- it is absolutely NOT a good idea to automate that.
Just like its not a good idea to automate signing the release bits with
your personal key.
Thanks,
Roman.