David Jencks wrote:
On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote:
I'm am new to maven, so sorry if I show my ignorance.
While I think I can see the value to what you suggest moving forward
if we choose to release sub-projects independantly (I say if because
we haven't discussed or agreed what tbd long term answer is yet) I do
not understand the benefit to a user of Aries of this change.
As a result it does not appear to me to be key to resolve prior to
release.
I would like to understand the problems you see better, but I do not
have the maven background you guys have, any chance you could explain
what the problems are, why they are problems and the solution at some
point?
The biggest immediate problem is that without correct svn info you can't
do a release with the release plugin. I'm pretty sure the way its set
up now, when you try, the tag will be under maven's apache pom, not
aries. (you'll fail unless you happen to be a maven committer too). You
definitely don't want to try to do a release without the release plugin.
Organizationally there's no way that for instance blueprint,
application, and samples should always be released in synchrony. Any
time two of them happen to be ready for release at the same time it will
be purely accidental. Right now everyone wants to get a milestone out
the door, but looking at the different projects their state of
completion is pretty much wildly different. A decision to release all
of them at once is not based in any way on them being equally complete.
I'm suggesting that since build fixes are needed anyway, why not set up
a maintainable structure that will continue to work beyond this
publicity release. The benefit to users is that aries will be able to
release bits in a timely fashion; otherwise the entire project will
never be in a releasable state at once. (I'm only exaggerating a little
bit :-)
What got me looking at this at all is what look like wild gyrations that
don't really use maven properly to get an .eba (or some artifact) out
the door. This might be ok for one release but (a) I think this can be
done directly with the assembly plugin short term and (b) an
eba-maven-plugin seems like the obvious more long term solution.
I'm willing to fix the build and probably work on an eba plugin, but
want to be sure this is ok with everyone first.
The svn info can be added to support the maven-release-plugin without
reorganizing to support independent component releases. But I agree
that it would be nice to have the option of independent releases even if
we intend to release all components in this first release. So in
general, I'm in favor of the reorganization.
As I mentioned earlier, I am concerned about the eba generation as well.
I think a maven-eba-plugin would be preferred versus the alternative I
mentioned of releasing the ebas simply as jars (again, assuming that the
application code can deal with an archive of type jar instead of eba).
I am using the maven-assembly-plugin to generate the jar for the eba in
the AriesTrader sample but I didn't find the magic formula necessary to
create the archive with a type of eba rather than jar and so I resorted
to using ant (which I know is bad). A maven-eba-plugin or the
necessary configuration to get the maven-release-plugin to generate
something of type eba would sure be nice.
I guess the key question might be how long it would take to make these
changes and is it worth the wait.
Joe
thanks
david jencks
Thanks
Alasdair
On 23 Feb 2010, at 18:18, David Jencks <[email protected]> wrote:
This discussion got me worried enough to take a look at the aries
build. Now I'm even more worried.
While it might feel good to try to push out a release as fast as
possible I'd prefer to see a sustainable build system in place
first. So far it looks to me as if aries is going to be a bunch of
loosely coupled subprojects. Building them all at once is not going
to work for long. I think we should recognize that and put that in
the build system now. To me this means:
1. a parent pom that isn't at the root of the svn trunk.
2. each subproject has pom info sufficient so it can be released
(mostly svn info) (right now this is completely missing everywhere
as far as I can see, which will result in ares getting tagged into
svn as part of the apache pom)
We can still have a "fake" pom that builds everything, but it won't
be part of any release procedure.
Having separately released subprojects does not prevent having a
single vote on all the releases.
I'd suggest a few other pom tweaks such as using resources and
filtered-resources to distinguish when filtering is called for.
In addition relevant to this particular bit of the thread, we need an
eba-maven-plugin to assemble ebas. Getting this into a first release
would be a great idea IMO.
If there's general agreement I can spend some time playing with the
build and possibly working on the eba plugin.
thoughts?
thanks
david jencks
On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
Jeremy Hughes wrote:
On 19 February 2010 13:09, Joe Bohn <[email protected]> wrote:
I'd also like to see us release the sample applications but I
think there is
at least one complication. Both Blog Sample and AriesTrader
generate EBAs
using different techniques - but both leverage the
maven-antrun-plugin to
finally produce a file of type "eba".
I realised the .eba file generated in the blog-assembly module wasn't
being pushed into my local repo. I've made some changes to the pom.xml
in ARIES-198 to fix this. So now it uses antrun to create the .eba
artifact and the build-helper-maven-plugin to push the artifact to the
local repo. I needed to add NOTICE and LICENSE files to the .eba for
the ianal plugin in the verify phase to succeed.
I've not used the build-helper-maven-plugin before. Do you know if
it will work with the maven-release-plugin to push the eba artifacts
when we do a release? If so, then I should look at using the same
mechanism for AriesTrader.
I think the result is that the eba will not be available in a maven
repository.
One of the differences is that AriesTrader first generates a jar
using the
maven-assembly-plugin and then copies this to an eba. The jar
will be
managed by maven and IIUC it should be deployable as an
"application" even
with an extension of "jar" rather than "eba". If that is correct
then
perhaps delivery of an application jar is an acceptable approach
for the 1st
release. Unfortunately I haven't actually setup my equinox
assembly to
deploy the eba yet - it still deploys all of the individual bundles.
Using the maven-assembly-plugin likely the preferred approach long
term. Perhaps we could copy the artifact to .eba and use the
build-helper-maven-plugin to remove the .jar artifact from maven
control and add the .eba one?
I can give this a try for AriesTrader. If it doesn't work out - is
there anything wrong with the approach I mentioned earlier of just
using the jar artifacts rather than the eba artifacts? Will the
current application support only look at *.eba archives?
Joe
Guillaume Nodet wrote:
I'd like to see at least those included:
* blueprint
* jmx
* jndi
* transaction
I don't think applications are really usable yet and I haven't
really
looked at JPA yet, so can't tell about it.
The transaction component is functional and we've been using it
mostly
unchanged since a long time in ServiceMix.
Do you have any particular concerns with it ? (I'm not talking about
declarative transactions for blueprint, note).
On Fri, Feb 19, 2010 at 04:19, Joe Bohn <[email protected]> wrote:
Thanks for the response (even while on vacation!) ... and for
volunteering
to be the release manager. Your response helps me get a better
picture
of
the plans.
I was really just interested in the general objectives and
timing since
it
hadn't been discussed yet. To get the release out in Feb means
it will
be
delivered next week. I'm afraid the hill might be a little too
steep to
climb that quickly but I'm happy to be proven wrong.
The more communication the better. It's important to get everybody
thinking
and planning along the same lines (or understand quickly if
there are any
differences of opinion). Knowing that you are thinking of
creating a
release candidate next week means that we should be getting more
restrictive
on new content to avoid any unpleasant surprises.
I don't have any strong opinions on what should be in or out -
but in
general it doesn't make sense to release things that aren't
functional.
At
the moment I'm not sure what those are - but I suspect not all
of the
components are fully functional yet (for example transaction).
Best Regards,
Joe
Jeremy Hughes wrote:
Hi Joe, sorry I started setting myself up tuesday but am now
out on
vacation until monday.
Personally, I think the 0.1 release should serve to get what we
have
right now in the respectable form the ASF requires. So 'must
haves'
are to get the build in the right shape to create the distribution
files that are acceptable to the IPMC. I think each main area
of the
code deserves at least a README to describe what's possible. Since
this is the first release there are likely a few unknowns - w.r.t
timing I hope/expect to get the release out this in feb. If
there are
particular JIRAs or other issues you feel should be included
please
say. I'd like to rename the current JIRA version 1.0 to 0.1 and
target
issues for 0.1 appropriately and issues not for 0.1 to target a
new
0.2 version. WDYT?
Cheers,
Jeremy
On 18 February 2010 15:39, Joe Bohn <[email protected]> wrote:
Jeremy,
What are your current thoughts and goals regarding the release
and
potential
target dates?
I think it would be good if you could summarize your thoughts
in an
email
or
perhaps on a page in the wiki that we can keep updated as we make
progress.
Of particular interest would be the content that we would like
to see
in
the first release (clarifying what we consider "must have"
from "nice
to
have"), the current status of that content, target dates for the
release,
and the process that we plan to use to generate the release.
Thanks,
Joe
Jeremy Hughes wrote:
On 12 February 2010 09:39, Guillaume Nodet <[email protected]>
wrote:
Great, thanks a lot. Let us know if you need any help.
I guess if you take some notes, it would be interesting to
put those
on the wiki.
Certainly will. It's been a while since I did one and the
process has
changed quite a bit :-)
On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
<[email protected]>
wrote:
Hi Kevan, thanks. I volunteer to be release manager.
Jeremy
On 11 February 2010 16:38, Kevan Miller
<[email protected]>
wrote:
Sounds like the consensus is for a release with all
components at a
0.1
version number. Best to start with a simple versioning
scheme, IMO.
Personally, I don't view a 0.1 blueprint release as an issue.
Showing the ability to generate an Apache release is an
important
step
for the community. Would definitely like to see this
happen...
We'll need a release manager. Any volunteers?
--kevan
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Joe
--
Joe
--
Joe
--
Joe
--
Joe
