On Feb 27, 2010, at 1:38 PM, Graham Charters wrote:
Thanks, David, looks great! My only minor comment would be the
default for including the maven goo is true, but if that's the same
default as for similar plug-ins, then perhaps we should leave it
as-is.
Including it is definitely the default for other packaging plugins.
Are you thinking of doing the manifest generation? If not, I might
have a crack at it this week.
I wouldn't mind working on it but should probably get back to making
geronimo work :-) So, go ahead, let me know if you'd like any help.
Where it is now in svn is going to cause problems with any attempt to
use the eba-maven-plugin inside application such as for itests so I am
planning to move it to a top-level subproject today or tommorrow.
thanks
david jencks
Regards, Graham.
On 27 February 2010 09:26, Alasdair Nottingham <[email protected]> wrote:
The application.mf does follow the manifest format with line
wrapping and so
on, but we have our own parsing code to remove the stupid 76 byte
line
length restriction.
Alasdair
On 27 Feb 2010, at 00:35, David Jencks <[email protected]>
wrote:
On Feb 26, 2010, at 2:49 PM, Graham Charters wrote:
Hi David,
The zip plugin I've been working from had a flag to exclude the
maven
goo. I've changed the default so it's not added automatically,
but it
should be simple enough to switch it back on through configuration.
The main reason I think we won't want transitive dependencies by
default is because we're expecting to provision these through a
bundle
repository. I do think we'll want the option to include them in
the
eba, I just don't think it should be the default. I think it does
make sense for them to be included by default for war and ear.
OK, after thinking about this some more I'm about 75% convinced
you are
right.
I added a flag for this, set to false by default.
I think it does all the things you asked for now. I guess the
next step
would be generating the application.mf automatically. The samples
on the
aries website and in svn don't look like the manifests I'm used to
seeing
with fixed line lengths and wrapping in the middle of words, are
they
supposed to?
thanks
david jencks
Regards, Graham.
On 26 February 2010 22:41, David Jencks <[email protected]>
wrote:
On Feb 26, 2010, at 1:56 PM, Graham Charters wrote:
Hi David, I didn't intend to take it over - sorry. What I
have so
far is pretty basic, so there's plenty more to do. I've been
trying
to create one for a little while and had a number of false
starts.
Your approach and Jeremy's discovery of the maven-zip-plugin
helped me
see how it might be done. Thanks
I was definitely not intending to create anything new/different
unless
it needs to be because the .eba format/usage justifies it. I
think
the transitive dependencies fall into this category, as does the
MANIFEST.MF.
I looked at the war and ear plugins and it looks to me as if
they are
using
the same transitive dependency strategy as the rar plugin, i.e.
including
non-optional transitive dependencies. That's certainly what I'd
expect
and
what I think is most convenient.
I didn't realize the MANIFEST.MF was unnecessary. I think using a
ZipArchiver instead of a JarArchiver will be necessary, as the zip
plugin
does. We'll have to configure the zip archiver a bit more....
I'll look into if/how to exclude the maven goo. Personally I like
having it
as it tells a lot about where the artifact came from and what it
is.
thanks
david jencks
Regards, Graham.
On 26 February 2010 18:34, David Jencks
<[email protected]> wrote:
OK, plugin is all yours. I really hope you don't invent some
new
conventions for dependency handling that are different from
what all
the
other maven packaging plugins do. I just copied what the rar
plugin
does,
I
haven't checked whether it is consistent with the war and ear
plugins.
good luck
david jencks
On Feb 26, 2010, at 10:11 AM, Graham Charters wrote:
Thanks Joe/Jeremy. Irrespective of this, I think the default
behaviour should be to not include transitive dependencies.
Unfortunately, I've failed in tidying up what i've done and
getting
the plugin tests clean. They make assumptions about things
like
source directory and manifest.mf being part of the plugin and
in the
zip based version, they're not. I'll hopefully get this
sorted over
the weekend.
Regards, Graham.
On 26 February 2010 17:10, Jeremy Hughes <[email protected]>
wrote:
On 26 February 2010 16:20, Joe Bohn <[email protected]> wrote:
It looks like there are changes afoot to this plugin but just
thought
I'd
confirm that it produces something equivalent to what I was
producing
for
AriesTrader and the result works equally as well.
I think the transitive dependencies referenced by Graham
can be
fixed
if
the
blog sample is updated to specify a scope of provided on the
dependencies.
For AriesTrader I use that scope for all external
dependencies and
I
didn't
have any unexpected dependencies included in the EBA
generated for
AriesTrader.
One of those dependencies was derby which wasn't marked with
a scope
so has picked up the default 'compile' scope. Scope of
provided will
make the classes available on the compile classpath which
isn't even
needed. The scope would need to be 'test' if there was
actually a
test
case! So I think we can just remove the dependency of derby
(in this
case).
Joe
David Jencks wrote:
I think it works.... contents look similar to what was
generated
previously. I attached a patch to ARIES-120 for
ariestrader-all-eba
in
case
anyone wants to take a closer look or try deploying it.
thanks
david jencks
On Feb 25, 2010, at 6:25 PM, David Jencks wrote:
I adapted the maven-rar-plugin to do what I think an
eba-maven-plugin
ought to do and put it under application. Right now it's
not
tied
into the
build. It may need to move elsewhere in the tree to make
it
easier
to
use
in aries itself, building and using plugins in the same
build can
be
tricky.
So far you need to write the application.mf yourself and
put it
in
the
source project under src/main/eba/META-INF/application.mf
To use it your project needs to have
<packaging>eba</packaging>
and configure the plugin with
<build>
<plugins>
<plugin>
<groupId>org.apache.aries.application</groupId>
<artifactId>eba-maven-plugin</artifactId>
<version>1.0.0-incubating-SNAPSHOT</version>
<extensions>true</extensions>
<configuration>
<includeJar>false</includeJar>
</configuration>
</plugin>
</plugins>
</build>
Note the very required extensions element.
By default it builds a jar from the java files in the
project and
installs it in the eba. The above configures it not to
do that.
I haven't tried this on a real eba yet... if anyone can
try that
and
see
if the results work that would be great. I'll probably try
tomorrow
if no
one gets there first.
thanks
david jencks
--
Joe
