You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Richard Downer <ri...@apache.org> on 2014/10/07 13:28:19 UTC
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 <gi...@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 <sv...@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 <sv...@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.
> ---
Re: Quick Start Archetype
Posted by Richard Downer <ri...@apache.org>.
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
<sv...@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 <gi...@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 <sv...@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 <sv...@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.
>> ---
>
RE: Quick Start Archetype
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
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 <gi...@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 <sv...@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 <sv...@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.
> ---