brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: Quick Start Archetype
Date Tue, 07 Oct 2014 15:48:30 GMT
Well, there are two possibilities...

Firstly, in my experience, a Java entity is created hand-in-hand with
a YAML blueprint, so I would usually expect that the developer using
the archetype is also developing a YAML blueprint that would exercise
it. (I don't have much data to support this assumption however; if
anyone has more information on the use case, please shout up.)

Secondly, following the "quick start" ideal, it should still be
possible for a developer to take the OSGi bundle produced here, chuck
it in lib/dropins (treating it as an ordinary .jar file that is added
to the classpath) and rely on annotations and the classpath scanning
to add it to the catalog.

An archetype which just produces a bare .jar, probably OSGi compliant
for future-proofing, would fit both of the above cases with little
fuss, I think...

Richard.

On 7 October 2014 15:03, Svetoslav Neykov
<svetoslav.neykov@cloudsoftcorp.com> wrote:
> I agree that we should be promoting the OSGi approach to bundling entities so what you
propose is quite appealing. It is also more in the spirit of a quick start, creating a custom
launcher is a target for more complex use-cases.
>
> There is another side to it though - if we create just an OSGi bundle then it needs to
be included in the catalog of an existing Brooklyn distribution which shouldn't be left to
the user to do manually. This brings us to where we started in that we need some kind of automation
for starting the entities :).
>
> Svet.
>
> -----Original Message-----
> From: Richard Downer [mailto:richard@apache.org]
> Sent: Tuesday, October 7, 2014 2:28 PM
> To: Brooklyn dev
> Subject: Quick Start Archetype
>
> Thanks Svet for your solution to this Windows build problem.
>
> However I wonder if the correct solution is to perhaps change the intent of the archetype
(and remove the problematic start.sh as a side effect)?
>
> This archetype produces a project whose output is a runnable application which embeds
the entities that the developer has written.
> While this is good for a fast start, it's not the way that Brooklyn apps will be deployed.
The preferred form for Brooklyn apps now is a jar or OSGi bundle that is inserted into an
off-the-shelf Brooklyn distribution.
>
> Should we be modifying the archetype to generate that type of project?.
>
> Thoughts?
>
> Richard.
>
>
> On 7 October 2014 11:35, neykov <git@git.apache.org> wrote:
>> GitHub user neykov opened a pull request:
>>
>>     https://github.com/apache/incubator-brooklyn/pull/222
>>
>>     Fix Windows EOL issues
>>
>>      * Instruct git to do EOL normalization on commit/checkout
>>      * Work around archetype:generate forcing OS line endings - treat shell scripts
as binary and resolve variables at runtime.
>>
>> You can merge this pull request into a Git repository by running:
>>
>>     $ git pull https://github.com/neykov/incubator-brooklyn
>> fix/windows-eol
>>
>> Alternatively you can review and apply these changes as the patch at:
>>
>>     https://github.com/apache/incubator-brooklyn/pull/222.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 #222
>>
>> ----
>> commit 0d775db8495f0485963a625316c894d17b4576fa
>> Author: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
>> Date:   2014-10-06T18:46:39Z
>>
>>     Instruct git to do eol normalization on text files (in case
>> core.autocrlf is not set in git config)
>>
>> commit 1e02b3683d788f5b171d1ce2d6a88709460211a1
>> Author: Svetoslav Neykov <svetoslav.neykov@cloudsoftcorp.com>
>> Date:   2014-10-07T08:59:28Z
>>
>>     Work around for archetype:generate forcing OS line endings.
>>
>>     When processing template resources (filtered="true") the archetype plugin forces
all content to use the current OS specific line endings. Treat shell scripts as binary files
so their line endings are preserved, saving any variables in a helper text file.
>>
>>     Shell scripts don't work when they contain Windows style line breaks, so it is
important to preserve the original line breaks even when building on Windows.
>>
>> ----
>>
>>
>> ---
>> 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
>> infrastructure@apache.org or file a JIRA ticket with INFRA.
>> ---
>

Mime
View raw message