Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
Received-SPF: pass (athena.apache.org: domain of webdoublefx@hotmail.com
 designates 157.55.2.76 as permitted sender)
Message-ID: <DUB118-W16A1A73E68557678F9833CB4740@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_1956e19b-43a2-4a8a-864b-534dacd89781_"
From: =?Windows-1252?B?RnLpZOlyaWMgVEhPTUFT?= <webdoublefx@hotmail.com>
To: "dev@flex.apache.org" <dev@flex.apache.org>
Subject: RE: AW: [Maven - Squiggly] release (was: RE: [jira] [Created]
 (FLEX-34640) Squiggly: Generate / Package RSLs and deploy with Maven)
Date: Sat, 22 Nov 2014 15:22:20 +0000
Importance: Normal
In-Reply-To: <1416656465705.57306@c-ware.de>
References: 
 <D0934F01.1EB67%aharui@adobe.com>,<B12F4DFC-F13D-4A45-893E-F65EBFA2893B@classsoftware.com>,<CAJs+wW38gGUDFYdVB4uREpNGFN-WdBO5QF34P4v8aMASOzYbKA@mail.gmail.com>,<DA7514CF-F9BF-483E-99FF-D116843ADA76@me.com>,<D094B4CB.1EE78%aharui@adobe.com>,<1416656465705.57306@c-ware.de>
MIME-Version: 1.0

--_1956e19b-43a2-4a8a-864b-534dacd89781_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi=2C

To continue on the idea of generating from our own VMs the needed artifacts=
 / poms and having a job running on build.a.o taking it and deploy it=2C I =
found this Maven plugin [1] which I guess could help for a bulk deploy=2C n=
ow=2C the only remaining problem is in how to pass the built artifacts from=
 the VM to build.a.o.

A possibility could maybe having a Private Maven Repo on the VM=2C only acc=
essible from the job on build.a.o with credentials=2C still from the VM=2C =
having a job that create an assembly from the artifacts we want to deploy=
=2C basically all snapshots=2C then from build.a.o extract the assembly an =
use the maven-bulk-deploy.

Thoughts ?

Fr=E9d=E9ric THOMAS

[1] http://bsorrentino.github.io/maven-bulk-deploy/deploy-folder-mojo.html

> From: christofer.dutz@c-ware.de
> To: dev@flex.apache.org
> Subject: AW: [Maven - Squiggly] release (was: RE: [jira] [Created] (FLEX-=
34640) Squiggly: Generate / Package RSLs and deploy with Maven)
> Date: Sat=2C 22 Nov 2014 11:41:06 +0000
>=20
> Well the projects currently built with Maven are=2C as you stated=2C almo=
st all Java. I encountered one project actually built with flexmojos but we=
 can't have this built on b.a.o as this would require a mavenized release v=
ersion of Flex and this is missing. As soon as we have all our stuff out of=
ficially with maven I think a lot of things will be becoming more and more =
easy.
>=20
> I could try to work with infra and check out the options for having our s=
tuff working on their systems. Mabe they would be willing to copy a maveniz=
ed version of flex to the build agent's local maven repo=2C but I doubt thi=
s would work.
>=20
> And ... just to add another thing to my "I love maven" list ... these pat=
h settings=2C environment variables=2C binary requirements and so on are on=
ly needed because there is no structure. Not a single Maven built module ha=
s need for any of these settings (Ok ... flexmojos built ones do have the r=
equirement to have the flashplayer and adl on the path=2C but that's all). =
But I know ... a maven built SDK won't be coming ... but if you stop dreami=
ng=2C you've already lost =3B-)
>=20
> Chris
>=20
> ________________________________________
> Von: Alex Harui <aharui@adobe.com>
> Gesendet: Freitag=2C 21. November 2014 18:51
> An: dev@flex.apache.org
> Betreff: Re: [Maven - Squiggly] release (was: RE: [jira] [Created] (FLEX-=
34640) Squiggly: Generate / Package RSLs and deploy with Maven)
>=20
> On 11/21/14=2C 3:22 AM=2C "Justin Mclean" <justinmclean@me.com> wrote:
>=20
> >Hi=2C
> >
> >> If you're feeling brave=2C go ahead. Past experience with INFRA makes =
me
> >>wary
> >> to go down that rabbit hole again.
> >
> >They gave a few talks at ApacheCon=2C they now see themselves as a servi=
ce
> >provider and are here to help and are in the process of
> >consolidating/fixing their offerings. We should take advantage of Infra
> >were we can as it should mean less work for us=2C better security=2C fas=
ter
> >boxes etc=2C etc
>=20
> That=92s great=2C it is fine for folks to try again=2C but fundamentally=
=2C if the
> strategy is still several projects sharing a Jenkins instance=2C then I
> disagree with Infra's approach.
>=20
> The code you build on build.a.o currently has to be independent of Java
> version=2C Jenkins version and probably other dependency versions as well
> (Ant=2C Maven=2C etc).  Somebody else decides which versions are availabl=
e and
> when to install/uninstall them.  Your build is sharing compute cycles and
> disk space with other project=92s builds=2C and you have limited access t=
o the
> low-level.  I could never run a debug session on the Flash Player on
> builds.a.o.
>=20
> If they want to give us our own VM then we=92re not sharing and that woul=
d
> be more interesting=2C but then I think we can=92t deploy to Maven.
>=20
> That=92s why this thread is exploring the logistics of building Maven
> artifacts if you can or can=92t do GUI testing of the build.  That seems =
to
> be the key issue to me.  Assuming Apache Flex becomes more and more
> popular=2C we will want to eventually have automated tests for all of our
> releases except for shared libraries like Flex-Tool-API.  BlazeDS
> automated testing might require knowing a port to install Tomcat on and
> launching some browser to run FlexUnit or Mustella tests.  Dealing with
> collisions with other projects over whether they also have a Tomcat
> instance running or something else that uses a port we want to use or
> wanting to use a different browser version sounds like an awful future.
>=20
> If our Maven builds can somehow trust what they=92ve built is good withou=
t
> GUI testing then they are more likely to work on builds.a.o with less
> hassle since the actual Maven build seems to be more version tolerant: it
> appears to just compile and run java code (which in turn compiles but
> doesn=92t run ActionScript).
>=20
> -Alex
>=20
 		 	   		  =

--_1956e19b-43a2-4a8a-864b-534dacd89781_--